pastilhasandClaude Opus 5
816f869535
The file browser's clipboard moves to the server, files can be dragged between windows, and plugins reach further into the file browser. No schema change and no dependency change — checked rather than assumed, and the plan records the two commands that prove it. The clipboard needs no migration: it is a key in `user_state`, a JSONB column that already exists, written through the same route the dock and the view mode already use. Eleven commits since 2026.08.29.04, one of which is that release's report. Surveyed all seven target hosts while writing the plan. Every one answered and every one is clean. `fofos` sits ahead of the previous tag and behind this one — it has been hand-pulled all day while the fofos plugin work was written against it — and that commit is an ancestor of this tag, so its fast-forward is ordinary. 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.