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>
35 lines
2.0 KiB
Markdown
35 lines
2.0 KiB
Markdown
---
|
|
id: fleet/the-deploy-commander-cannot-finish-its-own-host
|
|
title: 'The deploy commander cannot finish its own host'
|
|
theme: fleet
|
|
status: open
|
|
created: 2026-08-21
|
|
date_source: stated
|
|
order: 5
|
|
---
|
|
|
|
**The deploy commander cannot finish its own host, so one machine is always a build behind until somebody
|
|
restarts it by hand.** After `2026.08.21.03` that skip was two releases deep on `officer-dev` —
|
|
`restart_time` unchanged at 155 — with the code for both sitting on disk.
|
|
|
|
The skip itself is correct and should not be removed. The commander is a session inside
|
|
`officer-claude-code` on that machine; restarting `officer` there ends the rollout mid-flight, and it is
|
|
not hypothetical — a manual deploy on 2026-08-21 had to leave that one sidecar alone to survive writing
|
|
its own report. Restarting only `officer` and leaving the sidecar would technically work and is worse: it
|
|
puts one host in a state nobody chose, a step behind the rest, discovered later.
|
|
|
|
So the question is what finishes it, and there are three honest answers:
|
|
|
|
- **A deferred restart the platform runs after the session ends.** Cheapest. The commander writes a
|
|
one-shot request, something outside the agent's process honours it, and the report says a restart is
|
|
pending rather than outstanding. Needs a thing that is not the agent and not `officer` — `at`, a systemd
|
|
transient unit, or PM2 itself.
|
|
- **A second machine deploys this one.** Cleanest and needs no new mechanism at all: any other host's
|
|
commander has no reason to skip `officer-dev`. Costs a second armed watcher and raises "who deploys the
|
|
deployer" — two watchers must not both claim a release, which `scripts/deploy-claim.sh` already prevents
|
|
per host but **not across hosts**, since the claim is local by design.
|
|
- **Leave it manual and make it loud.** The report already says "outstanding". A notification would close
|
|
most of the gap for none of the work.
|
|
|
|
Not a decision to make from the code — it is the owner's call which of those three shapes he wants.
|