pastilhasandClaude Opus 5
530e5880e1
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>
1.7 KiB
id, title, theme, status, created, date_source, order
| id | title | theme | status | created | date_source | order |
|---|---|---|---|---|---|---|
| known-bugs/a-commander-opened-from-chat-loses-its-context | A commander opened from /chat loses its commander controls | known-bugs | open | 2026-08-21 | stated | 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.