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.4 KiB
1.4 KiB
id, title, theme, status, created, date_source, order
| id | title | theme | status | created | date_source | order |
|---|---|---|---|---|---|---|
| fleet/plugins-update-restarts-every-sidecar-so-the | `plugins:update` restarts every sidecar, so the report understates what moved | fleet | open | 2026-08-21 | stated | 7 |
bun run plugins:update restarts sidecars itself, printing sidecar: started per plugin. On alpha
that is twelve processes bouncing during step 3 — before the plan's own restart step, and not something
any plan asked for.
Nothing is broken and this is not new behaviour. The problem is honesty: a deploy report whose "restarted"
column reads officer is describing one restart when thirteen happened, and the whole value of these
reports is that they can be trusted about what moved.
Two ways out, and they are not the same decision:
- Make the report accurate — the plan format grows a note, or the commander reads
restart_timefor every process rather than only the ones it restarted. Cheap, and it is the honest minimum. - Make the script not do it — a
--no-restartflag, with the deploy restarting what the plan names. That is the better shape (a plan that says "restartofficeronly" should mean it) but it is a change to something that works, and a plugin whose sidecar is not restarted after an update may well be broken in a way nobody notices until later.
Do the first regardless. The second is a real design call.