pastilhasandClaude Opus 5
78db9c8c93
No schema and no dependency change, verified against the previous tag rather than assumed. The last release needed a push for anthropic_accounts and this one needs none, so the plan says so explicitly — a host that runs db:push here has run something the release did not ask for. Two things the plan states that a reader could not infer from the diff. The email plugin's multi-account work is in ANOTHER repository and arrives through plugins:update, affecting only hosts where that plugin is installed. And officer-dev is skipped as always but is NOT behind this time: it was restarted repeatedly through the night as the work landed, so it is already running the tree this tag names. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
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.
A release is a tag, deploy/<version>, and nothing else triggers a deploy — not a commit message,
not a branch. A tag cannot be written into prose by accident, which a code word can and which every
document about deploying does.
What marks a release deployed is LOCAL: $OFFICER_ROOT/data/deploys/<version>.done. Not the report.
If the lock were the pushed report, a failed push would mean the release looked undeployed and the next
tick would roll it out again — and pushes here fail for unrelated reasons. So the report is an artefact,
valuable and not load-bearing.
See prompts/deploy-commander.md.