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. 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. 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. 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:
"Everything the Workshop offers must eventually be available through the Companion" (standing commitment). The Workshop's HeldAssertionCard lets the Operator commit in-engagement; the Companion's engagement page does not yet. Exactly the kind of gap the commitment says must close.
"Only show what is available" (seed v0.12, line 199). Must be respected in the design: the in-engagement affordance appears only where a commit action is possible (only when this engagement has held drafts). No disabled control.
Operator-authority over state transitions (seed v0.12, line 191). Commit stays the Operator's approved act — human as committing party, the same property CR-2026-121 built. 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.
Operator gets: the identical experience — held numbers, multi-select, Commit selected / Commit all — in the rail where drafts are already listed.
Mechanism: reuse HeldNoteCard / commitAssertion / HELD_COMMIT; the card path commits through the human session (same authenticated POST as dashboard and Workshop), so R-B20 / human-authority is satisfied with no new work.
Cost: low — largely reuse-and-place.
Risk: the dashboard card may carry cross-engagement assumptions (it shows engagement names per item); in-engagement those are redundant. Minor presentation adjustment.
Option 2 — Engagement-scoped variant
A commit affordance on the engagement page purpose-built for the single-engagement context — same commit mechanism, presented for "these are your current engagement's drafts," potentially by making the rail's existing "Held assertion — awaiting commit" rows actionable in place rather than adding a separate card.
Operator gets: the same commit actions, on a surface designed for in-engagement use — no redundant engagement labels, drafts presented as part of this engagement's working state.
Mechanism: same commit POST and authority model; the difference is presentation — the rail rows become actionable rather than hosting a transplanted dashboard card.
Cost: low-to-moderate. More design intent than Option 1; no new backend.
Risk: slightly more frontend design; payoff is a surface 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, not as a card in the rail.
Operator gets: commit at the point of discussion — "commit held 2," or a confirm-card inline in the thread.
Mechanism: substantially overlaps with CR-2026-121's already-built verbal commit path (commit_assertion intent, confirm-back, human authority). Less "new affordance," more "surface the verbal path prominently in-engagement and/or render the confirm-back inline."
Cost: moderate, partly already paid — the verbal path exists; the work is discoverability.
Risk: the larger interaction-design question; touches how commit relates to conversation (connects to the queued Companion-as-Operator-interface direction). Could be over-scoped for a gap Options 1/2 close directly.
Recommended default
Recommendation — Option 2 (converging with Option 1)
Option 2 — engagement-scoped variant — as the default, with a note that it converges with Option 1.
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, commits them there.
It satisfies "only show what is available" cleanly: the actionable rows appear only when held drafts exist (the rail already lists them only when present), so there is no disabled-control problem to design around.
It reuses the entire commit backend and authority model (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). If, at CR Step 0, the rail's structure makes lifting the existing card materially cheaper, 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 connected 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 separate pieces of work. This note's gap (the Operator reached for a commit control 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: 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 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 is scoped as a separate follow-on now or later.
Any implementation detail dependent on live tree-truth (deferred to the CR's Step 0).
Whether this ships before or after other queued work — user-visible and low-cost, but not urgent the way the fidelity defect was (that was an active misstatement; this is a missing convenience on a surface that already lists the items).