platform/deploy/2026.08.21.03.report.md

2026.08.21.03 — deployed

6/6 hosts. Every platform the plan reaches is on 3343b21a, officer restarted and back online, and no other process on any host was left in a state other than online.

officer-dev is the seventh platform and was skipped entirely — it is the host this deploy ran on. See below; its skip is now two releases deep.

This was a drill. The release changes package.json and adds its own plan file, nothing else, and it exists to watch the claim rule work. It did: scripts/deploy-claim.sh claim 2026.08.21.03 was taken before any host was touched, and state reads done.

The release

Tag deploy/2026.08.21.03 → 3343b21a; package.json at that commit says 2026.08.21.03. They agree. Plan: deploy/2026.08.21.03.md — pull, plugins:update, restart officer only. No bun install, no db:push, and neither ran anywhere.

Host	Before	After	plugins	restarted	restart_time	back
alpha	55ecbf4f	3343b21a	12/12	officer	61 → 62	online
fofos	55ecbf4f	3343b21a	1/1	officer	16 → 17	online
macbookpro	55ecbf4f	3343b21a	none installed	officer	3 → 4	online
edge-pertento-bridge	55ecbf4f	3343b21a	2/2	officer	5 → 6	online
production-pertento-bridge	55ecbf4f	3343b21a	1/1	officer	7 → 8	online
deadpool-rezio-bridge	55ecbf4f	3343b21a	none installed	officer	1 → 2	online
officer-dev	3343b21a	3343b21a	not run	none	155	skipped

Every host came in at 55ecbf4f — the previous release, level for the first time in three deploys — and every pull was a real fast-forward. Checkout paths were taken from each officer process's pm_cwd, so alpha's stale second checkout at ~/dockers/officer.dev/platform was never touched. macbookpro was awake.

More than officer restarted, and the plan did not ask for it. bun run plugins:update bounces each plugin's sidecar as it goes: twelve on alpha, two on edge, one each on fofos and production-pertento-bridge. Every one came back online. Nothing was left down.

What was NOT done, and why

• officer-dev was skipped completely — no pull (it is already at the tag, which was cut here), no plugins:update, no restart. This session runs inside officer-claude-code on it, and restarting officer there ends the rollout mid-flight.

  Its running process is now two releases old. restart_time is 155, unchanged since before 2026.08.21.02 — so the same restart the last report left outstanding is still outstanding, and it now carries both releases. The code for both is on disk. pm2 restart officer on officer-dev finishes them, whenever the owner wants it. Outstanding, and no longer new.

• fofos still cannot sync its capabilities. Third deploy running, same two failures, same unexplained cause:

  • capabilities: failed — fatal: detected dubious ownership in repository at '/home/pastilhas/officerdev/capabilities'
  • affordances: NOT published — EACCES: permission denied, mkdir '/home/pastilhas/officerdev/capabilities/affordances/officerdev'

  Both say that checkout is not owned by pastilhas. Still not papered over with a safe.directory entry, because a safe.directory line would silence the first message and leave the EACCES — they are one cause, and one stat settles it. plugins:update exited 0 and the gitea plugin itself updated, so this costs capability sync on that host and nothing else. Unexplained.

• fofos still carries one untracked file, scripts/chk.ts. A note, not a skip — the rule works.

• No bun install and no db:push ran anywhere. The plan says this release needs neither, and deploy/2026.08.21.02..deploy/2026.08.21.03 is two files.

• Nothing was verified beyond pm2. officer is online with a moved restart_time on all six hosts; no HTTP request was made to any domain. That is what the plan asked to check.

Notes for the next one

• The macbookpro PATH rule in docs/servers.md is now correct and was followed as written. export PATH=$PATH:/opt/homebrew/bin for the bun command, pm2 as a separate command, and both worked first time. Nothing to change.

• $SHELL -ic "pm2 jlist" with stderr discarded came back empty once, on edge-pertento-bridge, and the same command with 2>&1 a second later returned the full list. Transient, and it looked exactly like a dead pm2. Capture stderr and parse the JSON out of the stream rather than trusting the whole of stdout to be JSON — an interactive shell puts its own noise (starship, aliases) in there.

• officer-dev's skip needs a home other than a report. It has been carried forward twice now, and a report is not a place work waits — the next deploy will write the same paragraph. Either the owner restarts it, or it belongs in TODO.md.