platform/deploy/2026.08.21.02.report.md

2026.08.21.02 — deployed

6/6 hosts. Every platform the plan reaches is on 55ecbf4f, officer restarted and back online, and no other process on any host was touched by the restart step.

officer-dev is the seventh platform and was skipped entirely — it is the host this commander runs on. See below.

Rolled out one host at a time from officer-dev, by the procedure in prompts/deploy-commander.md.

The release

Tag deploy/2026.08.21.02 → 55ecbf4f; package.json says 2026.08.21.02. They agree. Plan: deploy/2026.08.21.02.md — pull, plugins:update, restart officer only. No bun install, no db:push, and neither was run anywhere.

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

Every host was clean of TRACKED changes and every pull was a real fast-forward. pm2 jlist after each restart showed zero processes in any state other than online, so nothing was collaterally bounced.

Checkout paths were taken from each officer process's pm_cwd, not assumed — so alpha's stale second checkout at ~/dockers/officer.dev/platform was never touched.

What was NOT done, and why

• officer-dev was skipped completely — no pull, no plugins:update, no restart. This session runs inside officer-claude-code on it, and its officer process would have been restarted out from under the rollout. Its checkout is already at 55ecbf4f (the tag was cut here), so the code is present and the running process is a build behind. pm2 restart officer on officer-dev, when the owner is happy with the rest, finishes this release. Outstanding.

• deadpool-rezio-bridge was two releases behind, not one. It came in at bd41dff5 — the deploy/2026.08.21.01 commit — while every other host was at eee73e77. The fast-forward carried both, 14 files, and it is now level. Nothing was wrong with it; it simply had not had the interim commits.

• fofos still cannot sync its capabilities. Same dubious ownership refusal as 2026.08.21.01, same unexplained cause, still not papered over with a safe.directory entry. New this time and probably the same root: its gitea plugin could not publish affordances — EACCES: permission denied, mkdir '/home/pastilhas/officerdev/capabilities/affordances/officerdev'. Both point at that capabilities checkout being owned by somebody other than pastilhas, which is worth one stat before the next deploy. plugins:update exited 0 and the plugin itself updated. Unexplained, and now costing two things instead of one.

• fofos carries one untracked file, scripts/chk.ts. A note, not a skip — that is the rule the last report asked for and it worked.

• No bun install and no db:push ran anywhere. The plan says this release needs neither.

Notes for the next one

• macbookpro needs the PATH helped after all — carefully. The last report said "$SHELL -ic and nothing else"; that is right for pm2 and wrong for bun. bun is at /opt/homebrew/bin/bun, and .zshrc does not put /opt/homebrew/bin on the interactive PATH, so bun run plugins:update failed command not found before it ran a line. What works is appending that one directory for that one command (export PATH=$PATH:/opt/homebrew/bin) and running pm2 as a separate command. Appending shadows nothing — pm2 stays at ~/.local/bin/pm2 and node at node@22. Replacing the PATH is what broke pm2 last time. docs/servers.md says "do not help the PATH" and should say "append, never replace, and only for bun".

• $SHELL -ic on macbookpro also aliases ls to eza, which is not installed, so a probe using ls reports a missing file that is plainly there. Use command ls or a plain non-interactive shell for file tests.

• plugins:update restarts sidecars itself. It prints sidecar: started per plugin, so on alpha twelve sidecars bounced during step 3 — before the plan's restart step, and not something the plan asked for. That is the script's own behaviour and it is not new, but a report that only lists officer under "restarted" is understating it. Worth a line in the plan format.