Proposals Wait for an Explicit Accept

In plain terms: the junior's memos sit in the tray until the partner signs or returns each amendment. Turning to the next matter, or the junior handing in another memo, signs nothing. A small bar above the message box counts the amendments still waiting and steps through them one at a time, like Word's tracked changes.

2026-10-07 — the ruling (owner)

1. Only an explicit accept applies a change. Filing a new proposal never accepts an earlier open proposal on the same document; nor does sending Goldie the next message, nor moving the selection to another card. This reverses "moving on accepts" (owner ruling 2026-09-15, recorded in the proposals schema page, "Accept and reject").
2. New proposals join the queue. A document may hold several open proposals. When one is accepted, the others that were filed against the same revision move up to the new revision with it, so accepting one never strands the rest as stale. A person's own edit still makes them stale, as before.
3. One item is one step row of the proposal's list in Goldie's conversation (the ProposalChip rows). A bundled proposal counts each step separately and each is decided separately.
4. The resolution bar sits directly above Goldie's composer wherever her conversation panel shows a proposal (the document canvas and list rows): [▲] [▼] 4 changes pending · 2 of 4 [✕] [✓]. The count is of undecided steps ("1 change pending" in the singular). ▲ and ▼ move between undecided steps, go to that change on the page and highlight it; ▲ is disabled on the first and ▼ on the last. After ✓ or ✕ the bar moves to the next undecided step. At zero the bar disappears. Buttons are labelled "Previous change", "Next change", "Reject this change", "Accept this change"; the count is announced politely.
5. No Accept all or Reject all on the bar.
6. The bar and the review gutter stay in step: both read and write the same decision state, so a tick in the gutter drops the step from the bar's count and a ✓ on the bar shows as decided in the gutter.

In plain terms: one tray, many memos, each amendment initialled by hand — from the margin or from the bar, which are two pens on the same page.

2026-10-07 — amended: the count spans the queue; out-of-date changes (owner)

In plain terms: the bar counts every amendment waiting on every memo in the tray, not just the top memo's. "9 changes pending" means nine initials still to give. If signing one memo means another memo now quotes words the file no longer shows, that amendment stays in the tray marked "Out of date — this text has changed": it still counts, and the only thing it can get is a strike.

1. The count is cumulative. The bar counts every undecided change (one step row) across all open proposals on the document. Order: the oldest proposal first; within a proposal, top of the document down. ▲ and ▼ walk that whole list and go to each change on the page; after ✓ or ✕ the bar moves to the next undecided one. List rows already give every open proposal its own decision, so their bar spans them the same way.
2. Out-of-date changes stay, reject-only. When accepting one change leaves another pointing at text that no longer matches (two rewrites of the same clause, say), the stale change stays in the queue, shows "Out of date — this text has changed", is counted as pending, and can only be rejected: ✓ is disabled and the words say why. It is never refused silently and never dropped. A change ticked before its text moved on was never applied, so it is pending again and can be rejected.
3. Staleness is read on the server, against the text as it stands: each step's "before" (the words it replaces, kept at filing) is read again from the tree, and a step whose words no longer match is out of date (convex/folio/proposalBefores.ts, staleStepIndices). An accept that would apply an out-of-date step — on its own, by finishing its proposal, or by accepting the proposal whole — is refused in those words and applies nothing.

In plain terms: the clerk checks the quoted words against the file at the moment of signing; the screen only reports what the clerk found.

Follow-up, not built: a way to ask Goldie to redo an out-of-date change in one press. No simple existing path re-files a single step, so for now the Builder rejects it and asks her again in the chat.

2026-10-08 — asking accepts nothing; no whole-proposal buttons (owner)

In plain terms: pointing at a clause that is still only in the junior's memo and asking "what does this say?" no longer signs the memo. The clerk hands the junior the memo's own wording of that clause and tells her it is still waiting. And the fold-out list of amendments in the chat is now a table of contents only: it takes you to each amendment, but signing or striking happens one amendment at a time, in the margin or on the bar.

1. Asking Goldie about a proposed card does not accept its proposal. Before, sending a message with a proposed card selected accepted the whole proposal first, so the card existed to talk about. Now the turn goes to the proposal's own anchor, as before, and her briefing carries a note naming the card and the proposal's pending steps for it (convex/goldie/briefingFocus.ts, passed as proposedCard to goldie/turns.sendMessage). The proposal stays open and nothing is written. If a change is wanted, she files a new proposal, which joins the queue.
2. The chat's list of changes (ProposalChip) decides nothing. Its Accept all / Reject all footer and its tick boxes are gone; a row still goes to its card. Changes are decided one at a time from the resolution bar and the review gutter. The server's whole-proposal accept and reject stay, because the bar still uses them to decide a proposal of one step, and the server still refuses any out-of-date step.

In plain terms: one signature per amendment, and a question is never a signature.

Refused

• Keep "moving on accepts" for the canvas only. Refused: a change the Builder never ticked would still land.
• Block a new proposal while one is open. Refused: Goldie would be unable to answer the next request until the tray was cleared.
• Accept all / Reject all on the bar. Refused by the ruling: the bar is for deciding one change at a time.

Consequences

• convex/folio/proposalWrites.ts files a proposal without touching the open ones; convex/goldie/turns.ts no longer settles the tray before a turn (the 2026-09-15 settleProposal.ts is retired).
• applyProposal moves the queue's other proposals to the new revision.
• Undo of a Reject is no longer refused because another proposal is open.
• On the list screens, a tag proposal's steps can be decided one by one (convex/goldie/listProposals.ts, decide with index).
• The canvas shows the oldest open proposal; the next one is drawn once it resolves.

Current versus target

Current: the bar counts and decides every undecided step of every open proposal on the document (GB-361); the canvas's review gutter still draws only the oldest open proposal, and the next one is drawn there once it resolves. Out-of-date steps are detected on the server and are reject-only. Target: none set.

Authority for the proposal row and its accept path: the proposals schema.