platform/deploy/2026.08.28.01.report.md

2026.08.28.01 — report

7 of 7 target hosts succeeded. officer-dev skipped: it is the host that ran the rollout, and it was already at the tagged commit.

Every host moved from 91147b40 (deploy/2026.08.27.02) to 9c8af9d4 (deploy/2026.08.28.01) by git merge --ff-only onto the TAG. Every host started from the same commit, so the fleet was coherent before this release and is coherent after it. No host was dirty in tracked files, none diverged, none needed a skip.

This is the first release rolled out under the new watcher loop. The rollout procedure is the same one that ran the previous nine; what was unproven was the loop around it.

Per host

Host	HEAD before	HEAD after	Restarted	Route probe
alpha	91147b40	9c8af9d4	officer 1→2, online	401 (9000)
fofos	91147b40	9c8af9d4	officer 4→5, online	401 (9000)
macbookpro	91147b40	9c8af9d4	officer 1→2, online	401 (9010)
macbruno	91147b40	9c8af9d4	officer 4→5, online	401 (9000)
production-pertento-bridge	91147b40	9c8af9d4	officer 2→3, online	401 (9010)
edge-pertento-bridge	91147b40	9c8af9d4	officer 3→4, online	401 (9000)
deadpool-rezio-bridge	91147b40	9c8af9d4	officer 20→21, online	401 (9000)

Every restarted process came back online with restart_time moved. Nothing was left errored or stopped on any host.

The verification, per host

The plan's check is an unauthenticated probe of the new route: 401 proves it is mounted, 404 would mean the bundle did not move. Run on each host against that host's own port, taken from its .env and not from habit:

curl -s -o /dev/null -w '%{http_code}\n' -X POST http://127.0.0.1:<port>/api/users/1/impersonate

All seven answered 401. None answered 404, so the frontend bundle and the route moved everywhere.

Three hosts — fofos, production-pertento-bridge, edge-pertento-bridge — answered 000 (connection refused) on the first probe and 401 seconds later. That is bun start still coming up, not a fault: pm2 returns as soon as it has respawned the process, before the server binds. A probe fired immediately after a restart is testing the wrong moment. The probes here retried until the port answered.

No schema change — checked, not assumed

The plan claimed no schema change, no dependency change and no plugin change. That claim was re-derived before the first host was touched, not taken on trust:

git diff --name-only deploy/2026.08.27.02..deploy/2026.08.28.01^{}

Ten files: two deploy/*.md, package.json, and six under src/ — a route, a router line, two frontend files, a workspace app and its index. No schema.ts, no drizzle config, no bun.lock, nothing under plugins/.

So there is no schema verification section in this report, because there was nothing to verify. That is the honest answer rather than an omission.

Steps the plan deliberately did NOT include, and which were NOT run

• bun db:push was not run on any host. The plan forbids it and gives the reason: it prints Changes applied even when it applies nothing, so it is not evidence, and on this fleet it is not free — it re-applies a default on command_hq_sessions.reference_paths everywhere, and drops and re-adds pk_music_now_playing on alpha and edge-pertento-bridge. Nothing in this release touches a schema, so running it would have been churn.
• bun run plugins:update was not run on any host. No plugin changed, and 2026.08.27.02 updated them across the fleet yesterday.
• officer-claude-code was not restarted anywhere. It ends every live agent session on the host and nothing in this release needs it.
• officer-opencode was not restarted anywhere. This release changes nothing it reads at boot.

The consequence worth stating: only officer moved on each host. Unlike 2026.08.27.02, where the plugins step bounced every sidecar, nothing else on the fleet restarted during this rollout.

Version agreement

The tag deploy/2026.08.28.01 is annotated and dereferences to 9c8af9d4. package.json at that commit reads 2026.08.28.01. They agree, so there was no question of which tree to deploy.

Say what was not done

• officer-dev was skipped entirely — not pulled, nothing restarted. It is the machine this rollout ran on, and restarting officer-claude-code there would have ended the session mid-rollout. It is already at 9c8af9d4, so its code is current; what it has not had is a restart of officer. That is the owner's to do, deliberately, as the last step. Until then officer-dev is running the previous release's process against the new code on disk.
• fofos carries an untracked scripts/chk.ts. Left alone. An untracked file is a note, not a reason to skip a host, and a fast-forward could never have touched it.
• The eight non-Officer processes on production-pertento-bridge were not touched. Dashboard, Tracking, Uptime and five Crons * were all online with unchanged restart_time after the rollout — checked, not assumed. The restart named officer alone.
• No host needed a retry for SSH. deadpool-rezio-bridge, which refused once during the 2026.08.27.02 survey, answered first time. macbookpro was awake.
• Nothing was rolled back and nothing needed repair. No host failed, so no half-applied state exists anywhere.