a prompt for the deploy commander, and the shape of a release

The agent watches for a commit whose subject BEGINS with the code word, rolls it out to the six
platforms in docs/servers.md, and reports back. It never decides what a deploy needs — the plan is
written for it in deploy/<version>.md, and an agent improvising a db:push is how a database gets a
schema nobody was ready for.

Four traps written in rather than left to be rediscovered, all verified tonight: take the checkout path
from PM2's pm_cwd because alpha has a stale second checkout that pulls successfully and changes
nothing; reach pm2 with `$SHELL -ic` because it lives under nvm in .zshrc and a login shell does not
read that, which is how I concluded twice that a machine had no pm2 while it was plainly running;
remotes differ per host so pull in place rather than assuming a URL; and macbookpro is a laptop that
may be asleep, which is a skip and not a failure.

Idempotence is the report's own existence — deploy/<version>.report.md on origin means deployed. A
watcher that restarts must not roll the same release out twice, and nothing else was standing between
it and doing so. The report's subject deliberately omits the code word, or a report would trigger a
deploy and loop.

Two gaps stated rather than papered over: there is no CLI for updating plugins, only an authenticated
route, so the plan has to say how or the report has to say it was skipped; and nothing wakes the agent
yet.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
2026-08-21 17:20:46 +00:00
co-authored by Claude Opus 5
parent 44f6c6d6ac
commit 07f854bf11
2 changed files with 137 additions and 0 deletions
+17
View File
@@ -0,0 +1,17 @@
# `deploy/`
One file per release, and one report per release.
```
deploy/
├── 2026.08.21.01.md the plan — what to run, in order, on which hosts
└── 2026.08.21.01.report.md what actually happened, written by the commander
```
The plan is written by hand before the release commit. The report is written by the deploy commander
afterwards and pushed back here.
**The report's presence is what marks a release deployed.** That is the whole idempotence mechanism: a
watcher that restarts checks for the report before acting, so it cannot roll the same release out twice.
See `prompts/deploy-commander.md`.