M7: Label who holds the Turn and settle an interactive send on admission

[Sandstorm831]

Parent

Spec #276; implementation sub-issue of M7 #275.

What to build

The interactive input's label is derived from the Run Projection's live Turn: while a Turn works it says the agent is working, and when the Step is blocked on the human it says it is the human's move; it never shows "Your Turn" during a live agent Turn. The interactive send Operation settles applied when Secant admits the Turn (the Run is durably running and the Turn is live), not when the Turn ends; the Turn's own outcome still arrives through the Run Projection. The draft clears on that settlement with no lingering sending state; a refused send settles not-applied, keeps the draft, and says why. The admission rule lives in the shared Application behind the Projection Port; headless has no interactive send (slicing rule 1's named exception). Run-control guidance on deferred settlement is amended to say where the send now settles (stories 87–92, 121).

Acceptance criteria

• A Projection Port test with the real Application and Run Store proves the interactive send settles on admission while the Turn is still live, and a refused send settles not-applied.
• Renderer tests prove the working and human's-move labels, the draft cleared on admission with no sending state, and a refused send keeping the draft with its reason.
• The run-control guidance amendment has landed, and the Workbench line "the draft clears only on an applied send" stays true.
• Prototype Crucible's launch and Run information architecture #23 evidence: keymap and focus, small terminals and resize, large content, interaction tuning, meaning without colour, and renderer and platform evidence, each shown by testRender frames with the fake Renderer Port.
• CI scenario: the Port and Workbench renderer tests are green on Windows x64, macOS arm64, and Linux x64.

Blocked by

• M7: Report structural violations from one rule catalogue in a dedicated gate step #277
• M7: Report guidance-structure violations in the contract and check Module guidance shape #278
• M7: Report vendor-provenance violations in the contract #279
• M7: Report release-workflow violations in the contract #280
• M7: Enforce unused code and clear today's findings #281
• M7: Fail lint on any warning and add two OpenCode style rules #282

Implementation packet

Owner: Application (interactive send admission behind the Projection Port), TUI presentation (Workbench interactive input), run-control guidance

Ratchet: a Port test that send settles on admission

Deletes: send settlement at Turn end, the lingering sending state, and "Your Turn" during a live agent Turn

Gate: ADR 0027 three-OS CI and recorded human evidence, with the slice scenario above.

Dependencies: no new runtime dependency

[Sandstorm831]

Starting context

Files are pinned at b976b6c, which carries every structural-ratchet slice (#277–#282). The spec's source facts date from fb3ee06. Where they differ, trust the Authority column and the files at b976b6c.

Input	Why it matters	Authority
Spec #276 stories 87–92 and 121, Implementation Decisions › Run Workbench (Turn label, Send settles on admission), Cross-cutting › Module ownership, Testing Decisions › Seams 3 (first bullet) and 4 (Workbench Turn label, clear-on-admission), and Out of Scope › Headless	The target. Admission means "the Run is durably running and the Turn is live". The admission rule lives in the Application. TUI owns presentation and key routing only. Headless gets no interactive send. The spec does not say how the Application learns that the Turn was admitted, what a send settles when its Turn is never admitted, what the input shows between Enter and admission, or the label's exact words.	Canonical spec
Operation	An Operation is Secant's admission and control result. It "does not imply … that the resulting Run work has completed". Story 92 follows from this definition.	Current guidance
Send path: interactiveTurnLive, submitSendInteractiveTurn, startSendInteractiveTurn, runInteractiveSend	Today the send's settler is the whole Turn. It writes running (L2312-L2317), awaits interactiveStep.turn(...), and only then returns applied (L2328-L2339). Refusals such as busy, not at the Step, or support unavailable already settle not-applied before any Turn. A Harness prepare failure also settles not-applied, and it rests the Run halted.	Current behavior
settleOperation and driveWithAbortProtocol	One settler promise decides the Operation outcome. The same promise is tracking.promise, which cancel and interrupt await and which finally clears. Settling on admission means splitting these two: the Operation records at admission, while tracking.promise still covers the whole Turn. The outcome must be recorded exactly once.	Current behavior
RunInteractiveStep and InteractiveTurnReport, composition's interactiveStepDriver, and execution's durable admission and driveInteractiveTurn	The Turn is admitted inside the opaque driver, when owner.admitTurn runs before the stdin frame. The Application gets only the final report. Two Turns are never admitted: an unusable Session returns early (L521), and a fenced admission drives not-started. Composition maps both to failed, so today the send settles applied.	Current behavior
observedOwner and the Turn-writes invariant	The precedent for wrapping owner writes to push a snapshot. Turn writes go through the raw owner and push no durable snapshot. Measured at b976b6c with a scratch Port probe (the Matt grill, a fake Claude Code Turn that blocks): while the human Turn was live, the send Operation read pending. A fresh read showed running with interrupt-turn offered, but an open run Projection's last durable update was running with only cancel-run. No followed client sees the live Turn until it ends.	Current behavior, Current guidance
liveTurn and the interactive boundary, Turn-scoped and interactive Offers, and InterruptTurnOffer	The Projection's live Turn is the admitted Turn with no result. It is surfaced only as the interrupt-turn and steer-turn Offers, which carry its turnId. RunView has no live-Turn field. Send and End are offered only at a blocked boundary with no live Turn.	Current behavior
Workbench: interactive Step, Offers, and interactiveTurnLive, dispatchSend, the settlement effect, InteractiveInput's hint and label, and the send seam	The TUI decides that a Turn is live from a missing send Offer, not from the live Turn. The label is a constant, "◇ Your Turn — you are driving this Session" (L94). "… sending…" (L70) shows for as long as the Operation is pending. The draft clears on applied and stays on a refusal. That rule already matches the target once applied means admitted.	Current behavior
Workbench renderer tests: the hand-driven outcome, interactiveRunOf, liveInteractiveRunOf, the sending hint, "Your Turn" during a live Turn, the refused send, and the narrow, no-colour input	Fixtures touched. These are the prior art and the tests to rewrite. L2761 asserts Your Turn during a live Turn, which is the bug. L2605 pins the lingering hint. Because the outcome is hand-driven, a test can settle applied while the snapshot still shows a live Turn.	Current tests
Port tests that assume a send settles at Turn end: headless suite send (it drives the Port directly), Matt grill and again, the other matt-* Port suites, and the standalone Matt-front replay with the revise send	Fixtures touched. Each awaits applied and then reads the Run as blocked with the Turn settled. Once applied means admitted, they must wait for the boundary on an observable condition, not a sleep (testing). The runtime-conformance program is its own CI step. The refused-before-a-Turn test is the prior art for not-applied. The fake Harness's block keeps a Turn live, so admission can be asserted before the Turn ends.	Current tests
Run-control › Settlement and Interactive-Step drive	The guidance to amend: say that send settles at Turn admission while tracking.promise still spans the Turn for cancel and interrupt.	Current guidance
Workbench › interactive input and the interactive Interrupt hint	"Only an applied send clears it" stays true. The hint line's precedence (pending, live Turn, boundary) is where the lingering state lives.	Current guidance
OpenCode session-screen research › Prompt, with OpenCode 228e9095ba packages/tui/src/component/prompt/index.tsx:L1092-L1146	OpenCode never awaits session.prompt and clears the prompt at once. On failure it shows a toast and the text is gone. Secant is stricter: it clears on admission and keeps the draft on refusal.	Research
ADR 0036 › Bottom region	The later redesign: a placeholder saying whose move it is, and no sending state. Do not contradict it. Do not build its Steer-as-message prompt.	Advisory

Reading rule

Start with the spec's Run Workbench bullets, then read runInteractiveSend beside settleOperation and driveWithAbortProtocol, then the Workbench input.

• Settle applied only after the Turn's durable admission succeeds. Every earlier refusal stays not-applied with its Problem. Keep tracking.promise on the whole Turn, so cancel, interrupt, and shutdown still find and await it. The Turn's own outcome reaches clients only through the Run Projection.
• Make the live Turn reach an open run Projection at admission, since it does not today (measured above). The Port test asserts through an open Projection's updates as well as fresh reads, because fresh reads already show the live Turn.
• Derive the label from the Projection's live Turn, not from a missing send Offer. It never says "Your Turn" while a Turn is live. No src/ branch on Bundle identity, no headless change, and --json stays unchanged.
• Rewrite the tests that pin today's behaviour, as testing requires. Do not keep the old tests beside the new ones. Amend run-control, and src/application/AGENTS.md if the push changes its Turn-writes bullet.
• M7: Show a working scanner while a Turn works #292 (scanner) and M7: Steer from the interactive input during an Interactive agent Turn #294 (Enter-to-Steer) are blocked on this ticket and read the same live-Turn signal. M7: Scope an interrupt to its Turn so a failed interrupt leaves no fired abort #298 (Turn-scoped interrupt) is open at the same time and edits the same send and abort code.

Open for the human

Choices the spec leaves open, each with the drafting recommendation. They are settled with the human when this context is refreshed for ready-for-agent.

1. How the Application learns of admission. Recommendation: wrap admitTurn on the owner handed to the Step driver, as observedOwner does for other writes, and push the Run Projection there. Reason: the change stays in the Application and the Owner line stays true. An admission callback would touch composition and execution too.
2. A send whose Turn is never admitted (unusable Session, fenced admission). Today it settles applied. Recommendation: not-applied with a new Problem, and the draft kept.
3. Between Enter and admission. A reopened Run prepares its Harness first. Recommendation: a short pending hint, with the field blurred until admission. Only the Turn-long "sending…" state goes.
4. Where the live Turn is read from. Recommendation: the interrupt-turn Offer, so no new Projection field is needed.
5. Agent-step Turns. Measured while drafting M7: Show a working scanner while a Turn works #292: an open run Projection also misses the live Turn during an Agent-step Turn. Recommendation: push every Turn admission, Agent steps included, so that M7: Show a working scanner while a Turn works #292 and M7: Steer from the interactive input during an Interactive agent Turn #294 need no Application change.

Still unknown:

• Whether the operation update or the Run push reaches the TUI first. This could flicker, and renderer tests cannot catch it.
• Whether the real TUI hides the interactive Interrupt today. This is inferred from the measurement, and the fix covers it.

Owner: Application (interactive send admission behind the Projection Port), TUI presentation (Workbench interactive input), run-control guidance
Ratchet: a Port test that send settles on admission
Deletes: send settlement at Turn end, the lingering sending state, and "Your Turn" during a live agent Turn
Gate: ADR 0027 three-OS CI and recorded human evidence, with the slice scenario above.
Dependencies: no new runtime dependency