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.6 KiB
id, title, theme, status, created, date_source, order
| id | title | theme | status | created | date_source | order |
|---|---|---|---|---|---|---|
| fleet/a-deploy-report-verifies-pm2-not-that-the-app | A deploy verifies PM2, not that the app still works | fleet | open | 2026-08-21 | stated | 4 |
A deploy verifies PM2, not that the app still works. The deploy commander raised this against itself,
unprompted, in its own report: "Nothing was verified beyond pm2." That is the most valuable line in
either report so far and it should not be true twice more.
What step 6 checks today is that the process it restarted is online and that restart_time moved. That
catches a crash on boot. It does not catch a server that starts, listens, and serves a 500 — or one that
serves a stale bundle, which is the exact failure that cost an hour on 2026-08-21 when a rebuilt frontend
was never picked up because the running process still held the previous index.gen.html.
The check that would have caught all of it is one line and needs nothing built:
curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1:<port>/
Two things to settle rather than assume. The port differs per host — take it from that host's .env
(OFFICERDEV_PORT), not from a constant; officer-dev is 9000 and nothing guarantees the others are.
And a 200 on / is a low bar: it proves the SPA shell is served. An endpoint that touches Postgres
would prove more, and choosing one is the actual design question here — probably /api/health if it
exists, and if it does not, that is the smaller item to do first.
Worth adding to the plan format too, so a release can name its own smoke test rather than relying on a generic one.