Files
platform/deploy
pastilhas 091cfcca96 deploy report 2026.09.14.01 — 4 of 4 targets
alpha, fofos, macbookpro, deadpool-rezio-bridge all at the tag, officer
back online, health answering. officer-dev skipped as the rollout host;
macbruno unreachable; both Pertento hosts on the skip list.
2026-09-14 20:16:51 +01: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
2026-08-23 18:38:26 +00:00
2026-08-24 02:15:40 +00:00
2026-08-24 02:58:36 +00:00
2026-08-24 03:41:15 +00:00
2026-08-25 16:13:24 +00:00
2026-08-26 03:37:40 +00:00
2026-08-26 04:31:51 +00:00
2026-08-29 14:20:27 +01:00
2026-08-30 11:13:11 +01:00
2026-08-30 11:38:06 +01:00
2026-09-09 23:17:12 +01:00
2026-09-14 20:11:15 +01: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.