pastilhasandClaude Opus 5
03fbb1189f
no schema change and no dependency change, and the plan says so with the two commands that prove it rather than the claim alone. so there is no db:push step and no bun install step, and the plan says neither should be improvised. ten commits, all code. THE BEHAVIOUR CHANGE IS NAMED RATHER THAN DISCOVERED: /todos now 404s. the board is the kanban plugin, in the marketplace, installed nowhere by default — the intended state. `role_permissions` rows naming `todos` are orphaned and the plan says explicitly NOT to clean them up: absence denies, a row naming a permission that does not exist grants nothing, and a data edit nobody asked for does not belong in a rollout. the plan adds one verification this release earns: an `ls` call per host, because the listing route changed to union plugin-claimed file types with core's own. a 500 there is a failed host. surveyed the fleet while writing it. av-club is installed on fofos ALONE, so fofos is the only host that gains HEIC — everywhere else the file browser is exactly what it was, which is the property the extension point was built for and worth stating so its absence elsewhere is not read as a fault. edge-pertento-bridge did not answer the survey. not listed as skipped on that evidence — one quiet moment is not a down host, and the last time this fleet assumed otherwise it cost four attempts against a machine that was fine. 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.