platform/deploy/2026.08.24.01.report.md

2026.08.24.01 — deploy report

5 of 5 target hosts succeeded. Two hosts skipped by plan, neither a failure.

Every host went 2646842c → c813eef6, the tag commit, by fast-forward. No host was dirty in tracked files. No bun install was run — the plan forbade it and bun.lock was untouched. No direct SQL was run and none was authorised.

Host	Before → after	db:push	plugins	officer	Result
alpha	2646842c → c813eef6	applied 2 statements (see below)	13/13	online, 73 → 74	✅
fofos	2646842c → c813eef6	applied 2 statements	1/1 (gitea)	online, 26 → 27	✅
production-pertento-bridge	2646842c → c813eef6	applied 2 statements	1/1 (gitea)	online, 5 → 6	✅
deadpool-rezio-bridge	2646842c → c813eef6	applied 2 statements	2/2 (email, offscale)	online, 11 → 12	✅
macbookpro	2646842c → c813eef6	applied 2 statements	none installed	online, 13 → 14	✅
officer-dev	c813eef6 (already)	not run	not run	not restarted	⏭ skipped — self
edge-pertento-bridge	—	—	—	—	⏭ skipped — docs/servers.md

Every process on every host reported online after the restart: alpha 20/20, fofos 8/8, production-pertento-bridge 15/15, deadpool 9/9, macbookpro 6/6. No process came back errored and none failed to restart.

The plan said db:push must report no changes. It did not, on any host.

This is a finding, and it is not what the plan's stop-condition describes, which is why the rollout continued.

bun db:push printed Changes applied on all five hosts. Run again in --strict --verbose, it wants the same two statements every time:

ALTER TABLE "command_hq_sessions" ALTER COLUMN "reference_paths" SET DEFAULT '{}';
ALTER TABLE "music_now_playing" DROP CONSTRAINT "pk_music_now_playing";
ALTER TABLE "music_now_playing" ADD CONSTRAINT "pk_music_now_playing" PRIMARY KEY("user_id","device");

The same diff appears on officer-dev, this release's own source host, whose database has been running this schema for days. That is the decisive check: the plan's condition is "that host and this tree disagree about something else", and no host disagrees with the tree — the tree disagrees with itself, identically, everywhere. It is the drizzle-kit mis-diff already documented in src/databases/CLAUDE.md under "Composite keys", here on a named composite primary key rather than a unique constraint, plus a spurious array-default diff.

Verified by query per host rather than by exit code, as the doctrine requires:

• alpha — pk_music_now_playing = PRIMARY KEY (user_id, device); reference_paths default '{}'::text[]. Both exactly what the schema code says.
• fofos, production-pertento-bridge, deadpool-rezio-bridge, macbookpro — reference_paths default '{}'::text[]. music_now_playing does not exist on these four (information_schema count 0): the music plugin is not installed there, so there is nothing for that half of the diff to touch. Not a fault.

So no host's schema is wrong. What is wrong is that db:push cannot serve as the proof step this plan wanted it to be — it reports work on a database that already matches.

What the owner should know: on alpha, where the table exists, every deploy drops and re-adds a live table's primary key for no reason. Harmless so far and verified intact afterwards, but it is real DDL on real data, repeated each release. The fix belongs in the schema code, not in a rollout.

Notes

• fofos carries one untracked file, scripts/chk.ts. Noted, not a reason to skip — a fast-forward cannot touch it.
• bun run plugins:update restarts each plugin's sidecar itself. On alpha that is 13 sidecars bouncing before the officer restart the plan asked for. Listed above as the plugin count; "restarted" is therefore more than officer alone on every host but macbookpro.
• officer-dev is current in tree at c813eef6 but its officer process was not restarted, so it is still serving the previous bundle. Restarting it is the owner's deliberate last step.

Not verified by this deploy

The plan's visual check — open a .m4a and confirm the audio player shows no transcribe icon, while an image still offers OCR and a video still offers extract-audio. That needs a browser and a hard refresh, and no host was checked that way. The code is deployed; that it looks right is unconfirmed.