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>
29 lines
1.4 KiB
Markdown
29 lines
1.4 KiB
Markdown
---
|
|
id: fleet/plugins-update-restarts-every-sidecar-so-the
|
|
title: '`plugins:update` restarts every sidecar, so the report understates what moved'
|
|
theme: fleet
|
|
status: open
|
|
created: 2026-08-21
|
|
date_source: stated
|
|
order: 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_time` for
|
|
every process rather than only the ones it restarted. Cheap, and it is the honest minimum.
|
|
- **Make the script not do it** — a `--no-restart` flag, with the deploy restarting what the plan names.
|
|
That is the better shape (a plan that says "restart `officer` only" 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.
|