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>
34 lines
1.6 KiB
Markdown
34 lines
1.6 KiB
Markdown
---
|
|
id: fleet/a-deploy-report-verifies-pm2-not-that-the-app
|
|
title: 'A deploy verifies PM2, not that the app still works'
|
|
theme: fleet
|
|
status: open
|
|
created: 2026-08-21
|
|
date_source: stated
|
|
order: 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:
|
|
|
|
```bash
|
|
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.
|