todo: what tonight's deploy work left behind, and two items it closed

Closed:

- fleet/an-orchestrator-that-acts-on-every-server-at — built, and as none of the three shapes it
  proposed. Not a script, not a screen, not a chat capability: an agent handed a written procedure and a
  server list it has to read rather than one baked into it. All three verified facts in the item earned
  their place; two things it did not anticipate are now new items.
- fleet/a-way-to-mark-a-commit-this-one-ships-so-a — built as a TAG, which the item explicitly ruled out.
  The owner reversed it, and the argument that changed his mind is recorded: a codeword can be written by
  accident, because every document about deploying contains it, so the trigger needs rules about where in
  a subject line it sits and a rule like that is one somebody eventually gets wrong.

Opened, all from tonight and all with the evidence attached:

- a deploy verifies pm2 and not that the app serves anything — the commander raised this against itself
- the commander cannot finish its own host, so one machine is always a build behind
- the watcher loop is rewritten by an agent every arming, so its correctness is re-rolled each time
- plugins:update restarts every sidecar, so a report naming only officer understates what moved
- an agent spawned by a background job is invisible in the UI while being perfectly readable
- AskUserQuestion can fail to parse its own call
- a commander opened from /chat loses its commander controls, because isCommander comes from the screen
  rather than the session

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

todo/known-bugs/a-commander-opened-from-chat-loses-its-context.md

@@ -0,0 +1,30 @@
+---
+id: known-bugs/a-commander-opened-from-chat-loses-its-context
+title: 'A commander opened from /chat loses its commander controls'
+theme: known-bugs
+status: open
+created: 2026-08-21
+date_source: stated
+order: 4
+---
+
+**A commander opened from `/chat` reports the ordinary chat context, so the composer hides every control
+that only exists for a commander.** The visible symptom is the background-job dialog offering "Stop when
+it fires" and "Keep going" but not **"Exit and hand back to the agent, then re-arm"** — the one a watcher
+actually wants, and the dialog's own default inside a commander.
+
+Introduced 2026-08-21 by a deliberate UX change: a commander in the Live list opens in `/chat` rather than
+navigating away to Command HQ, because being thrown out of the page you are reading costs more than the
+metadata you did not ask for. That change is right and should stay.
+
+The defect is that `isCommander` is derived from **the screen** rather than from **the session**:
+`isCommander={manager.context === 'command-hq'}`, and `/chat` passes no such context. A commander is a
+commander wherever it is rendered.
+
+The fix is to carry it on the session. `ClaudeSessionSummary` and `/chat/live` both already have
+`isCommander`, derived server-side from the cwd; `GET /chat/sessions/:id` does not, and that is the one the
+chat detail reads. Adding it there and letting the composer take it from the session rather than the route
+closes this and makes the same thing work in any future surface that renders a chat.
+
+Related: the same `context` name means two different things either side of `EmbeddableChat` — a `useChat`
+option and a component prop, neither reading the other's — which is what hid the original bug twice.

todo/known-bugs/askuserquestion-can-fail-to-parse-its-own-call.md

@@ -0,0 +1,26 @@
+---
+id: known-bugs/askuserquestion-can-fail-to-parse-its-own-call
+title: 'AskUserQuestion can fail to parse its own call'
+theme: known-bugs
+status: open
+created: 2026-08-21
+date_source: stated
+order: 3
+---
+
+**`AskUserQuestion` rejected a well-formed call with `InputValidationError: called with input that could
+not be parsed as JSON`.** Seen 2026-08-21 in the deploy commander's first turn, on Sonnet.
+
+The tell is in the transcript: the failed call arrives as `{"__unparsedToolInput": {"raw": "{\"questions\":
+[…"}}` — the arguments reached the harness as a **string** rather than an object, and the harness reported
+that as the model's fault. The retry, byte-identical in intent, went through and the question rendered
+normally.
+
+So it is recoverable and it self-corrected, which is why it is filed here rather than treated as urgent.
+What makes it worth fixing anyway: this is the same tool as the stall bug fixed earlier the same day, on
+the path where an agent asks a question and waits. A parse failure there burns a turn, and if it happened
+on the **second** attempt too the agent would most likely give up asking and guess — which is the failure
+mode the question mechanism exists to prevent.
+
+Worth capturing the raw payload when this fires rather than only the first 200 bytes, since the message
+truncates exactly where the interesting part would be.