pastilhasandClaude Opus 5
9c8af9d424
two commits, one feature, and a plan that leaves things out for stated reasons. NO SCHEMA, NO DEPENDENCY, NO PLUGIN CHANGE — checked with git rather than asserted, because asserting it is exactly what sank 2026.08.27.01. db:push is deliberately not a step. yesterday's report established that it prints "Changes applied" when it applies nothing, so its output is not evidence, and on this fleet it re-applies a default on command_hq_sessions.reference_paths every time plus churns pk_music_now_playing on two hosts. running it here would be noise against a database this release does not touch. so the rollout is a merge and one restart. the verification step is an unauthenticated POST to the new route: 401 means mounted, 404 means the bundle did not move — a check that works without a session, on an owner-only feature. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043
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.