> ## Documentation Index
> Fetch the complete documentation index at: https://docs.ankra.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Stack Profile Suggestions

> Propose changes to a stack profile you can see but do not own, and review, approve, or reject the suggestions other organisations send to profiles you publish

<Note>
  When a [stack profile](/concepts/stack-profiles) is public or shared with your organisation, you can do more than deploy it: open it in the builder, edit it, and send the result to the owning organisation as a **suggestion**. The owner reviews the diff and either approves it - publishing it as the profile's next version - or rejects it with a note. The profile itself stays owner-only throughout: a suggestion never changes anything until an owner approves it.
</Note>

This is how a fix you have proven in production travels back to a shared or public profile without the owner handing out write access - and without exporting YAML and mailing it around. It is also the right lane for the owner's own updates: a builder draft keeps the version's input annotations (titles, descriptions, enum choices, and choices that set other inputs), while editing an IaC export and re-importing it re-detects the inputs from the spec, drops those annotations, and creates a separate new profile instead of a new version.

***

## Propose a change to a profile you do not own

### Prerequisites

<Steps>
  <Step title="Be able to see the profile">
    Public profiles and profiles [shared with your organisation](/concepts/stack-profiles#share-with-specific-organisations) both qualify. Shared profiles carry a "Shared with you" label in your profile list.
  </Step>

  <Step title="Not own it">
    On profiles your organisation owns you have **Edit Builder** and publish directly; the suggestion lane exists for everyone else's profiles.
  </Step>
</Steps>

### Edit and submit

<Steps>
  <Step title="Open the profile and choose Suggest changes">
    On a profile you do not own, the builder button reads **Suggest changes** instead of **Edit Builder**. It opens the stack builder on a draft seeded from the profile's latest version, held in your own organisation. Choosing it again later resumes the same draft - your organisation has one open suggestion draft per target profile, so a second click never forks a second copy.
  </Step>

  <Step title="Edit like any other draft">
    Change add-ons, manifests, variables, and inputs exactly as in your own profiles. The draft autosaves as you work, and the header shows a readiness chip - **Ready to publish**, or a count of blockers you can click to see what submit would refuse.
  </Step>

  <Step title="Submit the suggestion">
    Choose **Submit suggestion**. Give it a title (one line summarising the proposed change - this is what the owner's review queue shows) and, optionally, a description explaining why the owning organisation should apply it. On submit you land on the profile's **Suggestions** tab with your proposal listed as *open*.
  </Step>
</Steps>

Submitting freezes the draft into the suggestion: the exact spec and inputs at that moment, plus the profile version the draft was seeded from (its base). The draft itself is consumed. A submitted suggestion cannot be edited - to revise one, withdraw it, choose **Suggest changes** again, and submit anew.

### While it is open

* Your suggestion appears on the profile's **Suggestions** tab. On a profile you do not own, the tab shows only your own organisation's suggestions; the owner sees everyone's.
* **Withdraw** takes an open suggestion out of review - the owning organisation can no longer approve it. Withdrawing still works even if the owner revoked your share grant in the meantime.
* Each suggestion carries a status: *open*, *approved* (with the version it was published as), *rejected* (with the owner's note, if they left one), or *withdrawn*.

### If the profile moves on while you edit

The draft's base is pinned to the version it was seeded from. You can still submit, and the owner's review flags the drift (see below), but your proposal will not include the newer changes. To start from the newer version instead, discard the draft with **Discard draft** and choose **Suggest changes** again - suggestion drafts cannot be rebased.

### Keep it as your own copy instead

A suggestion draft can also be published as a profile of your own: **Publish as copy** creates a brand-new profile in your organisation from the draft, independent of the original. Use it when the owner rejects your change, or when your variant diverges too far to be a suggestion.

***

## Review suggestions on a profile you own

Open the profile's **Suggestions** tab. It badges the number of open suggestions, and each row shows the title, status, proposing organisation, and when it was submitted.

<Steps>
  <Step title="Expand a suggestion">
    You get the proposer's description and the full change list from the suggestion's base version to the proposal - the same rendering as a version diff, covering structure, manifest settings, and add-on chart versions - plus the raw before/after view.
  </Step>

  <Step title="Check for upstream drift">
    If you have published versions since the suggestion was based, the review warns you: the proposal was based on an older version, and approving publishes the proposed contents as the next version *without* the newer changes. Approving never merges - it publishes exactly what was frozen at submit.
  </Step>

  <Step title="Approve or reject">
    **Approve** publishes the frozen contents as the profile's next version and closes the suggestion in one step - the row then shows which version it was published as. The release notes default to one composed from the suggestion's title; edit them before confirming if you want the version history to say more. **Reject** closes the suggestion without publishing; the note you leave is shown to the proposing organisation.
  </Step>
</Steps>

Only the owning organisation can approve or reject, and only the proposing organisation can withdraw. Resolving is first-writer-wins: if a colleague approves or rejects a suggestion while you have it open, your action reports it was already resolved and the list refreshes. Every submit, approve, reject, and withdraw is recorded in the [audit log](/guides/audit-log).

***

## Secrets never travel through a suggestion

The suggestion lane applies the same secret handling as publishing a profile version, in both directions:

* The draft behind **Suggest changes** is seeded from the published version, which stores secret *inputs*, never secret values - so the owner's credentials are not in what you edit.
* At submit, the payload goes through the same redaction as publish: any secret value in the draft is stripped and declared as a required secret input instead. A suggestion that would still carry a plaintext secret is refused outright, as is a spec carrying a secret placeholder at paths nothing declares as a secret input - so an approved version can never deploy a literal placeholder as a credential.
* The same checks run again at approve, before the frozen payload becomes a published version.

Whoever instantiates the approved version binds their own secret values at deploy time, exactly as with any other profile version.

***

## Stale drafts and rebase on your own profiles

The owner-side twin of upstream drift: you are editing your own profile in the builder and someone else publishes a new version first. Publishing your draft refuses rather than silently overwriting, and the builder offers the choice:

* **Reset to latest** replaces the draft's contents with the latest published version, discarding your edits.
* **Publish my edits anyway** keeps your edits and publishes them as the next version - an explicit decision that your draft supersedes the version published in between, whose changes are not merged in.

Rebasing applies only to drafts editing a profile your organisation owns. A suggestion draft pins its base instead, and its drift is surfaced to the owner at review time.

***

## From the CLI

The same lane is scriptable with the [Ankra CLI](/integrations/ankra-cli) (v0.13.0 or later); the full flag reference is at [ankra stack-profiles](/reference/cli/stack-profiles).

```bash theme={null}
# Open a draft on the profile you want to change. On a profile another
# organisation owns, this is a suggestion draft.
ankra stack-profiles drafts create --profile <profile-id>

# Refine what the launch form shows for an input
ankra stack-profiles drafts annotate <draft-id> --parameter replicas \
  --description "Replicas per zone; 3 is the tested production value"

# Preflight the checks submit will run
ankra stack-profiles drafts validate <draft-id>

# Send it for review
ankra stack-profiles drafts submit-suggestion <draft-id> \
  --title "Raise the default replica count to 3"
```

Reviewing as the owner:

```bash theme={null}
ankra stack-profiles suggestions list <profile-id>
ankra stack-profiles suggestions get <profile-id> <suggestion-id>
ankra stack-profiles suggestions approve <profile-id> <suggestion-id> \
  --changelog "Adopt the community replica defaults"
ankra stack-profiles suggestions reject <profile-id> <suggestion-id> \
  --note "We keep single-replica defaults for the starter tier"

# Proposer side: take an open suggestion back
ankra stack-profiles suggestions withdraw <profile-id> <suggestion-id>
```