platform/deploy/2026.08.26.01.report.md

2026.08.26.01 — report

5 of 5 target hosts succeeded. Two hosts skipped by plan (officer-dev, edge-pertento-bridge); neither is a failure. Every target ended at e9f1760f = deploy/2026.08.26.01 exactly.

No schema change in this release, and that was verified rather than assumed — the diff between deploy/2026.08.25.01 and this tag touches no schema.ts and leaves bun.lock untouched. No bun install was run anywhere. No direct SQL was run on any host; none was authorised.

First release under a new watcher, and the first the loop has ever executed. The claim was taken by the watcher before this agent was spawned; this agent recorded done after the rollout.

One finding the owner should see: db:push is not a no-op on any host

bun db:push exited 0 and printed Changes applied on all five. Per doctrine that is not evidence, so each host was re-run with --verbose to see what push actually wanted. Every host wants the same statement, every single run:

ALTER TABLE "command_hq_sessions" ALTER COLUMN "reference_paths" SET DEFAULT '{}';

alpha additionally wants a drop-and-re-add of pk_music_now_playing (the music plugin's composite primary key).

This release did not cause it and it is not damage. The reasoning is deductive rather than a guess: this release changes zero schema.ts files, so drizzle's desired state is byte-identical before and after the merge — anything push wants is pre-existing drift. It was verified by query that the database is already in the state the schema code asks for:

Host	command_hq_sessions.reference_paths default	pk_music_now_playing	roles
alpha	'{}'::text[] — correct	present (contype=p)	4
fofos	'{}'::text[] — correct	n/a	4
production-pertento-bridge	'{}'::text[] — correct	n/a	4
deadpool-rezio-bridge	'{}'::text[] — correct	n/a	4
macbookpro	'{}'::text[] — correct	n/a	4

So drizzle cannot match '{}' against the stored '{}'::text[] and re-emits the ALTER forever. It is the array-default cousin of the named-composite-constraint mis-diff already documented in src/databases/CLAUDE.md → "Composite keys", and pk_music_now_playing on alpha is that exact documented case.

Why it matters even though it is harmless today: it permanently spends the signal. The plan said "expect no changes to platform tables — if it wants to alter one, stop and report it", and that stop condition can never fire cleanly while a platform table is on the standing-diff list. A future release that really does want an unexpected ALTER will look exactly like tonight. Worth fixing at the schema code, not on the hosts.

The rollout was not stopped for it. Non-destructive, pre-existing, and the databases are in the state the code asks for.

postdb:push seeders ran clean everywhere: seed:roles 0 seeded / 4 already present on all five, backfill:session-models 0 seeded on all five.

The reason for this release — verified on fofos

The plan exists because proxy-manager imports ChatHeader, which did not exist before 2ed47fa6, so the plugin's frontend rebuild failed and the SPA silently kept its old bundle.

Verified after the restart, from the logs and the build output rather than by eye:

• [plugins] frontend built in 7693ms (3 outputs) at out-log line 1777 of 1808 — the current boot.
• The No matching export … for import "ChatHeader" line is in the error log above the last gen-index / server.tsx boot markers, i.e. it belongs to the previous boot. No rebuild failed after the successful build.
• build/ was rewritten at 04:46:04, seconds after the restart, and chunk-b7epbzfm.js contains proxy-manager 41 times.

ChatHeader itself greps to 0 in the bundle — expected, production bundling renames it. The absence of the build error is the signal, not the presence of the symbol.

The owner still needs a hard refresh (Ctrl/Cmd-Shift-R) before judging /proxy-manager in a browser that is holding the old bundle. Not checked from a browser by this agent.

Per host

Steps in plan order everywhere: ff-merge to the tag → bun db:push → bun run plugins:update → pm2 restart officer.

alpha — success

• HEAD 007cc9a1 → e9f1760f. Tree clean, no untracked files.
• db:push exit 0. Standing diff as above; database verified correct by query.
• plugins:update: 14/14 updated in 59s, exit 0. This bounced fourteen sidecars on its own, before any restart the plan asked for — the report line below understates what actually moved.
• pm2 restart officer: restart_time 3 → 4, online, uptime 14s at check.
• All 21 PM2 entries online. officer-claude-code untouched (uptime 28h).

fofos — success

• HEAD 007cc9a1 → e9f1760f. Tracked-clean. One untracked file: scripts/chk.ts — noted, not a reason to skip, and not touched.
• db:push exit 0; proxy_manager_connection, proxy_manager_dns_credentials, proxy_manager_domains all present, as the plan predicted for a proxy-manager host.
• plugins:update: 3/3 updated in 28s, exit 0 (browser, gitea, proxy-manager).
• pm2 restart officer: restart_time 29 → 30, online, uptime 26s at check.
• All 11 PM2 entries online. Frontend rebuild verified — see the section above.
• Note: this host's .env names the database OFFICERDEV_POSTGRES_URL, not POSTGRES_URL as on the others. Cost one failed probe. Worth knowing for the next orchestrator that reads .env directly.

production-pertento-bridge — success

• HEAD 007cc9a1 → e9f1760f. Clean, no untracked files.
• db:push exit 0; standing diff only; verified correct by query. 39 tables in public.
• plugins:update: 1/1 updated in 4s, exit 0 (gitea).
• pm2 restart officer: restart_time 8 → 9, online, uptime 22s at check.
• All 15 PM2 entries online. officer-claude-code untouched (uptime 76h).
• Every command on this host prints an nvm/.npmrc globalconfig warning. Pre-existing, cosmetic, nothing failed because of it — but it is noise an orchestrator has to filter, and it will eventually hide something.

deadpool-rezio-bridge — success

• Login br, checkout /home/br/officerdev/platform, taken from PM2's pm_cwd.
• HEAD 007cc9a1 → e9f1760f. Clean, no untracked files.
• db:push exit 0; standing diff only; verified correct by query.
• plugins:update: 2/2 updated in 8s, exit 0 (email, offscale).
• pm2 restart officer: restart_time 14 → 15, online, uptime 22s at check.
• All 9 PM2 entries online.

macbookpro — success (it was awake)

• Checkout /Users/pastilhas/projects/officer-suite/platform. PATH appended with /opt/homebrew/bin for the bun commands; pm2 run as a separate command, per docs/servers.md.
• HEAD 007cc9a1 → e9f1760f. Clean, no untracked files.
• db:push exit 0; standing diff only; verified correct by query.
• plugins:update: no plugins installed — nothing to update, exit 0.
• pm2 restart officer: restart_time 16 → 17, online, uptime 27s at check.
• All 6 PM2 entries online.

Skipped

officer-dev — skipped, by plan and by doctrine

Not pulled, nothing restarted. This agent runs inside officer-claude-code on this machine; restarting officer here ends the rollout. It already carries this code — its HEAD was e9f1760f before the rollout began.

Its working tree holds another session's uncommitted work — modified src/servers/hono.ts and src/workspaces/hooks/src/useClient.ts, plus an untracked src/servers/hono-error-shape.test.ts. Left alone. The report commit below names only its own path.

The owner restarts this host deliberately, as the last step, once happy with the rest.

edge-pertento-bridge — skipped, by plan. Not contacted.

And docs/servers.md disagrees with the plan about this host. The doc's "Deliberately skipped" section says "None today" and lists edge-pertento-bridge in the platforms table as "a deploy target again". The plan says skip it: 300+ commits behind, no roles table, and a plain db:push there would create a foreign key onto an empty table. Its catch-up is a by-hand job the owner is doing separately.

The plan won — it is authoritative for a release, and it is the more recent statement. Nothing was sent to that host, not even a reachability probe. docs/servers.md should be corrected, because the next orchestrator that reads the doc rather than the plan will db:push a host that cannot take one. Not fixed here: a rollout does not edit documentation.

What was NOT done

• officer-claude-code was not restarted on any host, per the plan. The widened chat credential (an API key follows its holder, minus admin) lives in that sidecar, so it is not active anywhere yet. It is the owner's call when to take that — it ends every live agent session on the host, including this one. Pending on all five targets plus officer-dev.
• officer-dev was not deployed. Skipped whole, per above.
• The sonnet default was not confirmed from a UI on any host. The plan names it as the easiest visible check; this agent has no browser. It shipped in the code that is now at e9f1760f on all five, unverified at the surface.
• /proxy-manager was not opened in a browser. Verified from the build and the logs instead.
• bun run docs:check was not run — not a rollout step, and this agent does not fix documentation.