# 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: ```sql 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.