feat: supervisor Q&A in Chat, Decision Log, and the dashboard tab rework (#24)

[sam-bretz]

Closes #24.

This PR was first opened as partial. It now covers the whole issue: a real back-and-forth with the supervisor, the complete tab removal, and every Decision Log entry the issue lists.

Asking the supervisor

Keys and commands: ? in the dashboard (tab in the composer switches between steer and ask), envctl run ask <run> --node <stage> --text …, and MCP envctl_action with action ask.

It can't change the work. A question is stored on the revision next to messages, not inside any attempt, so answering one can't touch an attempt's result, review, digest or approval. TestQuestionsLeaveTheWorkAndItsApprovalUnchanged checks this.

How it's answered. The coordinator runs a separate, read-only invocation of the stage's supervisor, using the stage's supervisor model:

• Claude gets only Read,Glob,Grep. Bash is excluded because it can write as easily as it reads.
• Codex runs with --sandbox read-only.
• A running worker keeps going, because the answer runs as a separate job.

Grounding. With Claude, the answer branches the supervisor's own session using --fork-session. It knows what it reviewed, and the question isn't added to the transcript the supervisor resumes when steered. Codex can't branch a session, and continuing one would add to it. So Codex.Request refuses Fork, and Codex starts fresh from a prompt holding the stage's summaries, review, checks, pull requests, steering and earlier answers.

Durability. The job ID is derived from the question, the same way readiness probes do it. After a restart the coordinator finds the job it already started instead of asking twice, and each answer is recorded exactly once.

Limits.

• A run at its token ceiling refuses new questions.
• Answers count toward that ceiling and are attributed to the stage.
• A question whose VM has been released (closed, cancelled or superseded run) fails and says to rewind.

Answering after acceptance. Questions are scheduled before the engine's completed-revision skip, so a finished stage can still be asked about while the run keeps its VM.

The rest of the issue

• Checkpoint is gone as a tab. Tabs are now Chat, Changes, Tests and Decision Log.
• Chat reads as one conversation in time order. It shows attempts, worker summaries, supervisor accepts and rejections, steering, questions with a "thinking" state and then the answer, and approvals with who approved and when. It also lists the stage's artifacts, so , . o still work.
• Blockers are in the run summary, visible from every tab. Service states show when a preview is configured or a service is down.
• The Decision Log adds questions, Plan's scope, retries and stall nudges, token-ceiling stops, and publication results (the PR URL, or why publishing failed).

New durable state: revision notes

Token-ceiling stops, stall nudges and publication failures weren't recorded anywhere the dashboard could read back reliably:

• Recovery keeps only the latest cause, and it's cleared when a runtime is released.
• The captain's log exists only when a tracker is configured.

Revisions now keep Notes. Each note is appended inside the same mutation that makes the decision, so it's written once even though the engine reaches those points on every tick. Stall nudges come up from the backend, which is the only part that knows when it sent one.

Two regressions tests caught in my own changes

• Inherited checkpoints went invisible. A rewind copies earlier checkpoints into the new revision without the attempts that produced them. My first Chat thread was built only from attempts, so an inherited stage showed nothing, and with the Checkpoint tab removed there was nowhere else to see it. The existing history test caught it. TestAStageCarriedOverByARewindStillShowsItsResult now guards it, and I confirmed it fails without the fix.
• "worker: worker (resume 1)". Removing the "Live:" prefix made a worker whose phase is worker read that way. Now it reads live: worker (resume 1).

Testing

gofmt -l . prints nothing, go vet ./... is clean, and the full go test ./... passes. New tests, by layer:

• workflow: attaching a question to the latest attempt, every refusal case, the token ceiling, usage accounting, and work and approval staying unchanged.
• agent: read-only tools, forking, and Codex refusing to fork.
• engine: answering while running, waiting and accepted; exactly one harness call per answer; every failure path; and each note recorded once.
• localexec: the answer invocation (fork versus fresh, the stage's model) and the prompt's grounding, including "is there a PR open?"
• daemon: the ask action.
• CLI: waiting, failure, timeout, no-wait, and run show.
• dashboard: conversation order, approval actor and time, inherited checkpoints, the ? composer, and tab toggling.

Docs updated: the first-workflow key table, "Watch it" and a new "Ask instead of steering" section; the CLI reference; and the agent guide.

Not verified against a live harness. The guest-job path, the actual --fork-session behaviour and Codex's --sandbox read-only are covered by tests up to the invocation boundary but haven't been run against real agents in a VM. Asking one real question on a running stage before merge is worth doing.

Merge-order note (unchanged): #39 also edits Chat's model line, so whichever of #39 and this PR merges second will conflict. The fix is to keep both changes.

🤖 Generated with Claude Code

[sam-bretz]

Rebased onto main after #40, #41 and #42 merged. One conflict, in the dashboard footer: #41 added c close while this PR renamed To/i chat to Steer/i steer. Both belong, so the footer now reads Steer <recipient> · i steer · … · c close · … in both the full and compact layouts. No semantic overlap with #41's finished-runs grouping or VM visibility. Full go test ./... passes.