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
1.8 KiB
Markdown
35 lines
1.8 KiB
Markdown
---
|
|
id: fleet/the-watcher-loop-is-rewritten-by-an-agent-every
|
|
title: 'The watcher loop is rewritten by an agent every time it arms'
|
|
theme: fleet
|
|
status: open
|
|
created: 2026-08-21
|
|
date_source: stated
|
|
order: 6
|
|
---
|
|
|
|
**The watcher loop is rewritten from scratch by an agent every time one arms**, so its correctness is
|
|
re-rolled on every arming. The first one on 2026-08-21 was careful, logged honestly, set a `timeout` on
|
|
its network call, routed stderr away from the JSON it was parsing — and still contained an unbounded
|
|
retry, because the obvious way to ask "have I done this release" is to test the `.done` file, and that
|
|
file only exists on **success**.
|
|
|
|
`scripts/deploy-claim.sh` fixed that one instance by moving the rule into code. The general problem is
|
|
untouched: the next loop can get something else subtly wrong, and nothing will notice until it costs
|
|
money or misses a release.
|
|
|
|
Things a platform-owned loop would make constant rather than re-derived, all of them learned by an agent
|
|
getting them wrong once:
|
|
|
|
- Claim the version before spawning anything.
|
|
- `OFFICER_ROOT` set explicitly — it is **empty** in the sidecar's environment, so the lock path resolves
|
|
to `/data/deploys` and every release looks permanently undeployed.
|
|
- stderr kept out of the `stream-json` stream, or the `claude.ai connectors are disabled` warning corrupts
|
|
the first `jq` parse.
|
|
- `jq --unbuffered`, or the job panel shows nothing for twenty minutes and reads as hung.
|
|
|
|
The tension worth naming: an agent writing its own loop is also the reason this worked at all on the first
|
|
night, from a prose description, with no watcher feature built. A fixed script is more correct and less
|
|
general. The likely answer is a **script the loop calls** rather than a script that replaces it — which is
|
|
what the claim rule already is, and it could absorb the four items above the same way.
|