Files
platform/deploy
pastilhas 79186b291d deploy report 2026.08.23.04
5 of 5 targeted hosts. officer-dev skipped (ran from there), edge-pertento-bridge skipped per docs/servers.md.

db:push reported changes on every host against a plan expecting none. Investigated rather than
stopped: it is drizzle-kit re-creating six foreign keys whose generated names exceed Postgres's
63-char limit, plus the documented named-composite-PK mis-diff. Present identically on the
untouched control host. Argument and evidence in the report.
2026-08-23 14:02:19 +00:00
..
2026-08-23 01:56:03 +00:00
2026-08-23 02:52:30 +00:00
2026-08-23 03:56:07 +00:00
2026-08-23 13:51:50 +00:00

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.