M7: Move ids off the everyday Workbench header

[Sandstorm831]

Parent

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

What to build

The Run id and process id leave the everyday Workbench header. The Run id is shown in the Workbench once the Run leaves an active state and stays listed in Previous Runs. Ids, process, digest, and recovery facts remain in the details panel (stories 96–99).

Acceptance criteria

• Renderer tests prove the header carries no Run id or process metrics while the Run is active, shows the Run id once it leaves an active state, and that the details panel still carries ids, process, digest, and recovery facts.
• Previous Runs still lists the Run id.
• 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 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: TUI presentation (Workbench header and details panel)

Ratchet: renderer tests for the header without ids and the Run id after an active state

Deletes: the Run id and process id in the everyday header

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, the main commit that closed #281. It carries the unused:check gate link. OpenCode is cited at 228e9095ba, the commit the session-screen research read.

Input	Why it matters	Authority
Spec #276 stories 96–99, Implementation Decisions › Run Workbench › Header, Cross-cutting › Everyday versus expert, and Testing Decisions › Seams 4 ("the header without ids, the Run id after an active state")	The target. The spec does not define "active state". It does not say where the Run id shows once the Run rests, or whether the liveness words ("live in this instance") leave with the process id. It says ids and process "remain in the details panel", but at b976b6c the panel shows neither (see the details-panel row).	Canonical spec
Charting record › Standing rules (Everyday versus expert information) and ADR 0036 › Layout and › Bottom region	The standing rule: "The Run id stays in Previous Runs and is shown whenever a Run leaves an active state." ADR 0036 has no header at all and shows the id beside a finished Run's outcome. ADR 0036 is read only to avoid contradicting it; its bottom region is not M7 work.	Canonical (charting record); ADR 0036 advisory
Run states	"Active" is not a glossary term. The glossary names running and blocked as live, halted and failed as resting and resumable, and succeeded and cancelled as terminal.	Current guidance
Header: the header block, livenessText, positionText, compactHeader, restingProseLine, headerRows, HEADER_COMPACT_WIDTH	Below 80 columns the one-line header leads with Run <id> and ends with the liveness phrase, and it has no Bundle name. Wide, the second line is Run <id> · <position> · <liveness>. The liveness phrase carries (process N). headerRows counts 1 or 2 rows plus the resting-prose line, so the row count must still match what renders.	Current behavior
Details panel: buildDetailsRows, whose identity rows carry the Bundle, digest, Workspace, and launch time; restingProse; Workbench guidance on the panel	The panel has no Run id and no process today, so this ticket adds both. It builds the rows once, and the container reserves exactly detailsRows().length, so a new row is counted for free. The guidance line lists what #194 moved into the panel; add the ids and process there.	Current behavior; current guidance
What stays: the takeover confirm, NotFoundView, the Previous Runs row	None of these is the everyday header. The takeover confirm names the owner process, the not-found view names the Run id, and every Previous Runs row leads with the Run id.	Current behavior
RunView runId and liveness and headless renderRun	The Projection already carries the Run id and ownerPid, so nothing below presentation changes. Headless run show keeps Run <id> and prints Live: in this instance (process N) only when the Run is live. That is a ready pattern for the panel row. Headless is the expert surface and does not change.	Current behavior
Tests (fixtures touched), in run-workbench.test.tsx. To rewrite: L508-L534 asserts run-77 on a running Run; L1720-L1747 asserts Run run-1 in the compact header of a running Run; L1763-L1779 asserts the process in the header. Prior art: runOf, mountWorkbench, panel identity, resize and state words, takeover pid, the per-state loop. In previous-runs.test.tsx, the id is listed and survives 40 columns.	The three tests that pin today's header are rewritten, not kept beside the new ones. control.setRun can move a mounted Run from running to a resting state, and that transition is where the Run id must appear. run-workbench.test.tsx passes at b976b6c's source (run 2026-09-30).	Current tests
OpenCode identifiers research and its header row; OpenCode 228e9095ba packages/tui/src/routes/session/index.tsx:L201-L205 and packages/tui/src/util/presentation.ts:L29-L38	OpenCode has no header. It shows the session id only in the exit epilogue (Continue opencode -s <id>), and in the sidebar of non-release builds.	Research
Three-OS check job, Test step	The CI scenario: the Workbench renderer tests run in this step on Windows x64, macOS arm64, and Linux x64.	Current behavior

Reading rule

Start with the spec's Header bullet and the standing rule, then the header block and buildDetailsRows, then the three tests to rewrite.

• This is presentation only. Do not change the Projection, the Application, or headless.
• While the Run is active, the header carries no Run id and no process id at any width.
• The details panel carries the Run id and the process whenever the header drops them. The Bundle, digest, Workspace, and recovery rows stay.
• Keep headerRows() equal to the rows rendered. Clip every header and panel row with clip, and keep the state in words at every width, so colour is never the only signal.
• The takeover confirm, NotFoundView, and Previous Runs keep their ids.
• run-workbench.tsx is also edited by M7: Label who holds the Turn and settle an interactive send on admission #290, which is unblocked now, and by M7: Show a working scanner while a Turn works #292 and M7: Steer from the interactive input during an Interactive agent Turn #294, which follow M7: Label who holds the Turn and settle an interactive send on admission #290. None of them waits on this ticket. Keep this change to the header and the panel rows.
• Left to the implementer: the exact wording and order of the new panel rows.
• Open for the human (recommendation in brackets). 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.
  • Active means [the glossary's live states, running and blocked, so the id shows at halted, failed, succeeded, and cancelled].
  • Once the Run rests, the id shows [where it sits today: the compact line and the wide second line].
  • The liveness phrase [leaves the header whole and becomes one panel row, shown only while the Run is live, as headless does].
  • The compact header of an active Run [leads with the Bundle name and state, like the wide first line].

Owner: TUI presentation (Workbench header and details panel)

Ratchet: renderer tests for the header without ids and the Run id after an active state

Deletes: the Run id and process id in the everyday header

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

Dependencies: no new runtime dependency