pastilhasandClaude Opus 5
c97da0292a
One commit —537cc29c, fixing what the 2026.08.30.01 rollout found on fofos: a plugin declaring `@tiptap/pm` was reported as a failed install. Nothing was broken on disk. That package has no root entry point by design — it is tiptap's single pinned copy of ProseMirror and you import `@tiptap/pm/state`, never the bare name — so the checker asked a question it could not answer. Worth its own release rather than waiting: `bun run plugins:update` exits 1 on fofos every time until this lands, so the plugin step of every future deploy fails there and reads as a new problem each time. No schema change and no dependency change, with the two commands that prove it in the plan. docs:check green. Only fofos has fofos-admin installed, so everywhere else this is a no-op in behaviour. ── Why .03 ── 2026.08.30.02 was tagged against a commit that was not on master: the rollout's own report had just been pushed and the release was cut without pulling first. The branch push was rejected and the tag was not, so a tag pointing off-branch existed for about ten seconds. The watcher claimed the version inside that window, and a claim is permanent by design — so .02 is spent and carries a claim with no .done, which is what "attempted and did not succeed" should look like. No host moved. Every one stayed on816f8695throughout. The lesson is in the ordering, and it is now the practice: pull, then push the branch, then tag only once the branch has landed. Pushing both in one command means a rejected branch still publishes a tag. Co-Authored-By: Claude Opus 5 (1M context) <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.