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.

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.