pastilhasandClaude Opus 5
e9b71522ed
The file preview becomes a carousel, zoom starts working again on every plugin screen, and a platform event bus arrives with thumbnails warmed on arrival. No schema change and no dependency change — verified against the range rather than assumed, and the plan says so explicitly so neither step gets improvised. Six of the seven hosts sit exactly on the previous tag. fofos does not: it has been hand-pulled all day while this work was written against it, and its commit is an ancestor of the tag, so it fast-forwards like any other host with fewer commits to travel. 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.