Wishes & amendments.

Two related-but-different mechanisms for changing a project after content has been authored. Wishes are open suggestions filed against any phase; amendments are formal proposals against locked content. Both have their own panel on the right rail.

Wishes #

A wish is an open suggestion — a feature request, a constraint, or a concern — filed against a specific phase. Anyone with access can file one: workspace members through the Submit a wish tab on the wish panel, and named stakeholders through their portal.

A wish has:

• Phase — which phase it relates to. Stakeholders can target any of vision, features, brief, design, architecture, quality, or security.
• Department — who's making the request (auto-filled from the submitter's role; selectable on stakeholder submissions).
• Priority — blocking, important, or nice-to-have.
• Description — the free-text body. The Improve menu in the bottom-right of the textarea offers AI rewrites before submit.

The wish panel header shows a pending count badge so phase owners can see at a glance how many newly filed wishes are waiting.

The two-tab layout #

The wish panel has two tabs:

• Inbox — the triage view. Splits into a "Pending" group (newly filed, awaiting triage) and a "Handled" group (everything else).
• Submit a wish — the workspace-member submission form (stakeholders submit from their own portal, never from this tab).

Submitter identity #

Each wish row shows where it came from:

• From an org member — the submitter's department label appears as plain text under the row's department/phase strip.
• From a stakeholder — a primary-tinted Stakeholder badge appears with the person's name, email, and (if provided) organization. If their access has since been revoked, the badge dulls to Stakeholder · revoked so you know they can't be reached without re-inviting them.

This is why the share model is named-only — see Stakeholders for context.

Triage #

Each pending wish offers three actions:

• Accept — marks the wish as approved. Use this when you intend to fold the request into the section. Accepting does not apply changes to the spec — that's a separate step (see "Merge into section" below).
• Defer — parks the wish without accepting or rejecting it. Useful when it's on-topic but blocked on an external decision.
• Reject — closes the wish with a required reason. Stakeholder submitters see the reason on their next portal visit, so be specific.

There is no "convert to amendment" action — if the target phase is locked, you'll be guided to amendments separately. Reject the wish and re-file as an amendment, or unlock-edit-relock if the change is small.

Conflict check on accept #

When you click Accept, the dialog runs an AI conflict check against the project's other open wishes and (when accepting against the features phase) the existing feature list. Within ~5–15 seconds it returns:

• A list of likely overlapping items, each with a one-line reason.
• A pre-checked "Tag this wish as a conflict on accept" checkbox.

If you accept with the box checked, the wish is stamped with a conflicts record (referenced wish IDs / feature IDs / a short note). Accepted-with-conflict wishes show a small amber conflict chip on the row, and the Merge into section dialog later replays a warning so you don't merge the same idea twice.

If the check returns no matches, the block stays silent — no visual weight when there's nothing to flag. If the check fails (network, model error), accept still works without the tag.

Statuses #

A wish moves through these states:

pending may appear on legacy stakeholder-portal wishes — it's treated the same as submitted in the inbox filter.

Merge into section (AI-assisted) #

Accepting a wish gets it out of the inbox; merging is what changes the spec. Accepted wishes whose phase is vision, features, brief, design, architecture, quality, or security show a Merge into section button under the row in the Handled list.

Clicking it opens a dialog that:

1. Snapshots the current section content at the moment you opened the dialog.
2. Calls the content-tier model with the wish + section, asking for a surgical edit that only addresses the wish.
3. Renders a field-level diff of the proposed change — strings show before/after with strikethrough; arrays show +/− lines with item summaries; object arrays group by id and report added / removed / modified counts.
4. Applies on Apply changes, marking the wish as merged and showing a sonner toast with the changed-fields count. Discard cancels with no spec change.

The merge runs against your snapshot, not whatever's in the database when you confirm — so a teammate editing the section in parallel won't be silently overwritten. If the AI can't find a place to land the wish, the dialog says "No changes proposed" and the action becomes Close.

The wish stays accepted if you discard, so you can re-open the merge later or hand-edit the section instead.

Amendments #

An amendment is a proposed change to a locked phase. Wishes go on phases at any state; amendments only exist after lock.

An amendment has:

• Target phase — must be currently locked.
• Proposed content — the new draft of the affected fields.
• Diff preview — generated automatically; shown to the approver before they accept.
• Author and timestamp — for the audit log.

The phase owner reviews each amendment. On accept, four things happen in order:

1. The phase is unlocked.
2. The proposed content is applied.
3. Any downstream phase that was complete is flagged "needs review" — the change may have invalidated what they assumed.
4. The phase is re-locked.

On reject, the amendment is closed with a reason. The phase stays locked, no content changes.

Every accept and reject writes to the project audit log.

Amendments from code #

Amendments marked From code were proposed by a coding agent running /sg-sync, after it found code that the spec doesn't describe: a hotfix, an emergency patch, a manual change. They look and work like any other amendment, plus:

• Found in lists the files (and commit) the proposal is based on, so you can check the code before accepting.
• The author is the coding agent's token label, for example "Claude Code · laptop (code sync)".
• The developer approved each one in their session before it was sent, but nothing changes in the spec until someone here applies it.

Reject anything that shouldn't become part of the spec, such as a temporary workaround; the reason is kept with the amendment. See Connecting coding agents for how /sg-sync works.

When to use which #

In short: wishes are conversational, amendments are formal. Use wishes liberally; reserve amendments for committed changes.

Adding a feature while implementation is running #

Both wishes and amendments work mid-build. A features-phase wish or an add-feature amendment becomes a new story in the BMAD pack with ready-for-dev status; the connected coding agent picks it up on its next /sg-dev call. Story keys for stories already in flight don't shift when a new feature is added — the FR-id assignment is max + 1, persisted on Save pack.

See Mid-build amendments for the end-to-end loop, including a 60-second test.

For the end-to-end flow of inviting reviewers, triaging their submissions, and merging the good ones, see Collecting wishes.