Scoping note — In-engagement commit affordance

Version. v0.1 Date. 2026-06-25 Author. Claude.ai (scoping), under Operator direction. Status. Scoping note. Frames a surface-design question, lays out alternatives, recommends a default. Precedes a Change Request. Not a Step 0 — the CR will require live-tree grounding (see "What this note does not do"). No build authorized. Grounds on. Seed v0.12 (in context); this session's screenshots (engagement E0007/E0060, dashboard); CR-2026-121 completion record; CC component-level findings (the commit affordance lives only in DashboardView.tsx; the engagement-page components carry zero references to it).

Plain-language summary

The Companion can commit held drafts — but only on the dashboard's "Needs you" zone, a cross-engagement triage surface. When the Operator is working inside an engagement, talking to the Companion about that engagement's held drafts, there is no way to commit them without leaving for the dashboard. The engagement page lists the held drafts in its inbox rail, but as a read-only list with no commit control.

This was observed twice this session: the Operator went to the engagement page looking for the commit affordance and it was not there. The affordance was built into the dashboard (CR-2026-121 §5.1 scoped it to DashboardView's "Needs you" card); the engagement page was never under that CR.

This note frames the question — should the commit affordance also live on the engagement page, and in what form — lays out three options, and recommends one. It does not build anything and does not decide; the Operator decides which option becomes a CR.

The gap, grounded

What the session established, not assumed:

• Dashboard (/dashboard, "Needs you" zone): full commit affordance — held items badged "Held N," checkboxes (multi-select), "Commit selected" / "Commit all." Confirmed rendering live. This is cross-engagement: held items from every engagement collect here for triage.
• Engagement page (/operator/engagement/{address}): the inbox rail lists this engagement's held assertions ("Held assertion — awaiting commit") and pending shapes — but as a read-only list. No checkbox, no commit button, no held-number-with-action. Confirmed by screenshot (E0007) and by CC: HeldNoteCard / commitAssertion / HELD_COMMIT live only in DashboardView.tsx; the engagement-page components (CenterPane, RightRail) have zero references to them.
• Operator behavior: the Operator reached for commit on the engagement page twice (E0060, then E0007). That is where the action feels like it belongs — in context, while talking to the Companion about the drafts — not on a separate cross-engagement dashboard.

The gap is precise: the held items are already listed on the engagement page; they are simply not actionable there.

Seed alignment — why this is expected, not scope creep

Three seed commitments bear on this, and all three point toward closing the gap rather than leaving it:

• "Everything the Workshop offers must eventually be available through the Companion" (standing commitment, from project context). The Workshop's HeldAssertionCard lets the Operator commit in-engagement. The Companion's engagement page does not yet. This gap is exactly the kind the commitment says must close.
• "Only show what is available" (seed v0.12, line 199). This cuts both ways and must be respected in the design: the in-engagement affordance appears only where a commit action is actually possible (i.e., only when this engagement has held drafts). No disabled control, no empty "Commit" button when nothing is held.
• Operator-authority over state transitions (seed v0.12, line 191). Whatever the surface, commit stays the Operator's approved act — the same property CR-2026-121 built (human as committing party, confirm-before-commit on the verbal path). The in-engagement affordance inherits this; it does not introduce a new authority model.

No conflict. Closing this gap implements a standing commitment and stays inside the seed's surface and authority rules.

The three options

Option 1 — Same affordance, second location

Render the dashboard's held card (the existing HeldNoteCard and its commit machinery) in the engagement page's inbox rail, filtered to this engagement's held items.

• What the Operator gets: the identical commit experience — held numbers, multi-select, Commit selected / Commit all — in the rail where the drafts are already listed.
• Mechanism: reuse HeldNoteCard / commitAssertion / HELD_COMMIT; the engagement page already knows its held items (it lists them). The card path commits through the human session (the same authenticated POST the dashboard and Workshop use), so R-B20 / human-authority is satisfied with no new work.
• Cost: low. Largely a reuse-and-place exercise — lift the existing component into the rail, scope its data to the current engagement.
• Risk: the dashboard's card may carry cross-engagement assumptions (it shows engagement names per item because it spans engagements); in-engagement those are redundant. Minor presentation adjustment, not a rebuild.

Option 2 — Engagement-scoped variant

A commit affordance on the engagement page purpose-built for the single-engagement context — same commit mechanism, but presented for "these are your current engagement's drafts" rather than a filtered slice of an all-engagements list.

• What the Operator gets: the same commit actions, but the surface is designed for in-engagement use — no redundant engagement labels, the held items presented as part of this engagement's working state, potentially integrated into the rail's existing "Held assertion — awaiting commit" rows (make the rows that already exist actionable, rather than adding a separate card).
• Mechanism: same commit POST and authority model; the difference is presentation — the rail rows become actionable in place rather than hosting a transplanted dashboard card.
• Cost: low-to-moderate. More design intent than Option 1 (the rail rows gain action affordances) but no new backend; the commit endpoint already exists.
• Risk: slightly more frontend design work; the payoff is a surface that reads as native to the engagement page rather than a dashboard component visiting.

Option 3 — In-conversation commit

Commit woven into the Companion conversation itself — the Operator is already talking to the Companion about the drafts; commit happens inline in the chat (a commit affordance attached to the conversation, or the verbal path made prominent), not as a card in the rail.

• What the Operator gets: commit at the point of discussion — "commit held 2" or a confirm-card inline in the chat thread, where the conversation about the draft is already happening.
• Mechanism: this substantially overlaps with what CR-2026-121 already built — the verbal commit path (commit_assertion converse intent, confirm-back, human authority) already exists. Option 3 is less "build a new affordance" and more "surface the verbal path prominently on the engagement page, and/or render the confirm-back as an inline card."
• Cost: moderate, and partly already paid — the verbal path exists; the work is making it discoverable/visible in-engagement (right now the Operator may not know they can say "commit held 2" in the engagement conversation).
• Risk: the larger interaction-design question of the three. Touches how commit relates to conversation, which is a deeper Companion-design thread (and connects to the queued "Companion-as-Operator-system-interface" direction). Could be over-scoped for a gap that Options 1/2 close directly.

Recommended default

Option 2 — engagement-scoped variant — as the default, with a note that it converges with Option 1.

Reasoning:

• The rail already lists this engagement's held items as "Held assertion — awaiting commit" rows. The most direct, most native fix is to make those existing rows actionable in place — the Operator sees the drafts there, and commits them there. That is Option 2's core, and it reads as part of the engagement page rather than a dashboard component transplanted in.
• It satisfies "only show what is available" cleanly: the actionable rows appear only when held drafts exist (the rail already behaves this way — it lists them only when present), so there is no disabled-control problem to design around.
• It reuses the entire commit backend and authority model (the card-path POST, human committing party, R-B20) — no new endpoint, no new authority surface. The work is frontend presentation.
• It converges with Option 1 in mechanism; the only difference is whether the held rows become actionable in place (Option 2) or host a lifted dashboard card (Option 1). Option 2 is the more native presentation of the same capability. If, at CR Step 0, the rail's structure makes lifting the existing card materially cheaper than making rows actionable, fall back to Option 1 — same outcome for the Operator, the choice is an implementation detail surfaced by live grounding.

Option 3 is deferred, not rejected. The verbal path it would surface already exists (CR-2026-121); making it prominent in-engagement is worth doing, but it is a distinct, larger interaction-design question that connects to the queued Companion-as-Operator-interface direction. Closing the card-surface gap (Option 2) and surfacing the verbal path in-engagement (Option 3) are complementary, not alternatives — but they should be separate pieces of work. This note's gap (the Operator reached for a commit control on the engagement page and found none) is closed by Option 2; Option 3 is a follow-on enhancement.

What a CR for this would need (not done here)

This note is not a Step 0. Before a CR is drafted, live-tree grounding must establish:

• The exact engagement-page rail component (CC named CenterPane / RightRail; the held-row rendering site needs locating) and how it currently fetches/lists this engagement's held items.
• The dashboard HeldNoteCard / commitAssertion props and data shape, to assess reuse (Option 1) vs. in-place actionability (Option 2).
• Whether the engagement page already holds the held-item data needed to commit (held assertion IDs, held numbers) or would need an additional fetch.
• The card-path commit endpoint the dashboard uses, confirmed reachable from the engagement-page context with the human session.
• Test placement: the engagement-page commit affordance needs frontend tests analogous to CR-2026-121's DashboardView.test.tsx, plus the fidelity language ("Held, awaiting your commit," not "saved") carried onto this surface — the same honest-state copy, on the new location.

The CR should be drafted in a fresh chat with that grounding, per session discipline.

What this note does not decide

• Which option (1, 2, or 3) becomes the CR — Operator's decision; default recommended is 2.
• Whether Option 3 (in-conversation / verbal-path-prominence) is scoped as a separate follow-on now or later.
• Any implementation detail that depends on live tree-truth (deferred to the CR's Step 0).
• Whether this ships before or after other queued work — it is user-visible and low-cost, but not urgent in the way the fidelity defect was (that was an active misstatement; this is a missing convenience on a surface that already lists the items).

DUNIN7 — Done In Seven LLC — Miami, Florida Scoping note — In-engagement commit affordance — v0.1 — 2026-06-25