# 2026.08.25.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 `007cc9a1` = `deploy/2026.08.25.01` exactly. The schema change was verified **by query on each host's own database**, not by exit code. All five returned both columns. First release under a new watcher. The claim was taken by the watcher before this agent was spawned; this agent recorded `done` after the rollout. ## The schema change Two nullable columns on `api_keys`. The plan's query, run per host: ```sql select column_name from information_schema.columns where table_name = 'api_keys' and column_name in ('permissions','excluded_kinds'); ``` | Host | `permissions` | `excluded_kinds` | Result | | ---------------------------- | ------------- | ---------------- | ---------------- | | `alpha` | ARRAY, null | ARRAY, null | 2 rows — pass | | `fofos` | ARRAY, null | ARRAY, null | 2 rows — pass | | `production-pertento-bridge` | ARRAY, null | ARRAY, null | 2 rows — pass | | `deadpool-rezio-bridge` | ARRAY, null | ARRAY, null | 2 rows — pass | | `macbookpro` | ARRAY, null | ARRAY, null | 2 rows — pass | No half-applied push anywhere — no host returned `permissions` alone. `bun db:push` exited 0 on all five and printed `Changes applied`. That was treated as not-evidence, per the plan; the table above is the evidence. `postdb:push` seeders ran clean everywhere (`seed:roles` 0 seeded / 4 already present on all five). **No direct SQL was run on any host.** None was authorised and none was needed. **No `bun install` was run on any host**, per the plan — `bun.lock` is untouched by this release. ## Per host ### `alpha` — success - HEAD `23657210` (`deploy/2026.08.24.02-29-g23657210`) → `007cc9a1` (`deploy/2026.08.25.01`) - Tree clean of tracked changes. No untracked files. - Path `/home/pastilhas/officerdev/platform`, taken from PM2 `pm_cwd` — **not** the stale second checkout at `~/dockers/officer.dev/platform`. - `bun db:push` exit 0 → verified by query, 2 rows. - `bun run plugins:update` — **14/14 updated in 57s**, exit 0. Fourteen plugin sidecars restarted themselves during this step (atelier, bitcoin-wallet, email, gitea, invoices, jellyfin, minesweeper, music, offscale, photos, soulseek, transcribe, transmission, vault). - `pm2 restart officer` — `restart_time` 2 → 3, `online`. - Health after: **21/21 processes online**, none errored. ### `fofos` — success - HEAD `e0d80fd3` (`deploy/2026.08.24.02`) → `007cc9a1` - Tree clean of **tracked** changes. One untracked file present: `scripts/chk.ts`. Noted, not touched, not a reason to skip — a fast-forward could not have affected it. - Remote is HTTPS here, as documented. Pulled in place. - `bun db:push` exit 0 → verified by query, 2 rows. - `bun run plugins:update` — 1/1 (gitea), exit 0; its sidecar restarted itself. - `pm2 restart officer` — `restart_time` 28 → 29, `online`. - Health after: **10/10 processes online**, none errored. - The August root-ownership problem did not recur: git and the plugin step both ran clean. ### `production-pertento-bridge` — success - HEAD `e0d80fd3` (`deploy/2026.08.24.02`) → `007cc9a1` - Tree clean, no untracked files. - `bun db:push` exit 0 → verified by query, 2 rows. - `bun run plugins:update` — 1/1 (gitea), exit 0. - `pm2 restart officer` — `restart_time` 7 → 8, `online`. - Health after: **15/15 processes online**, none errored. - Cosmetic only: the interactive shell prints an nvm warning about a `globalconfig`/`prefix` in `~/.npmrc`. It did not affect any step. Not fixed — outside a rollout's scope. ### `deadpool-rezio-bridge` — success - Logged in as **`br`**, not `pastilhas`. Checkout `/home/br/officerdev/platform`. - HEAD `e0d80fd3` (`deploy/2026.08.24.02`) → `007cc9a1` - Tree clean, no untracked files. - `bun db:push` exit 0 → verified by query, 2 rows. - `bun run plugins:update` — 2/2 (email, offscale), exit 0; both sidecars restarted themselves. - `pm2 restart officer` — `restart_time` 13 → 14, `online`. - Health after: **9/9 processes online**, none errored. ### `macbookpro` — success (it was awake) - Awake and reachable, so it was a target rather than a skip. - HEAD `8e2670ff` (`deploy/2026.08.24.02-96-g8e2670ff`, one commit short of the tag) → `007cc9a1` - Tree clean, no untracked files. - `/opt/homebrew/bin` **appended** to PATH for the `bun` commands; `pm2` run as a separate command through `$SHELL -ic`, per `docs/servers.md`. Both worked. - `bun db:push` exit 0 → verified by query, 2 rows. - `bun run plugins:update` — `no plugins installed — nothing to update`, exit 0. Nothing restarted here by that step. - `pm2 restart officer` — `restart_time` 15 → 16, `online`. - Health after: **6/6 processes online**, none errored. ## Skipped ### `officer-dev` — skipped, and deliberately The host this rollout ran on. Not pulled, not restarted, nothing touched. Restarting `officer` here would have ended the rollout mid-flight. Its checkout is **ahead** of the tag: HEAD `e1f5d01b`, two commits past `007cc9a1`, with uncommitted work belonging to another session (`src/servers/hono.ts`, `src/workspaces/hooks/src/useClient.ts`, and an untracked `src/servers/hono-error-shape.test.ts`). It therefore already holds this release's code and more. **The owner restarts it deliberately when they are happy with the rest** — that is the one outstanding action from this deploy. ### `edge-pertento-bridge` — skipped by the plan. NOT a failure. Excluded by name in `deploy/2026.08.25.01.md`, which is the authority here. It has no `roles` table while both its accounts hold roles, so a single `db:push` would create the foreign key against an empty `roles` and fail — possibly while still exiting 0. It also missed two releases carrying one-off steps that a fast-forward does not replay. Not contacted at all. No time spent on it. Bringing it forward is a watched, by-hand operation the owner is doing separately. ## What did not get done - `officer-dev` was not restarted — by design, see above. It is the only host not running a freshly-started `officer` process, though it is on newer code than the tag. - No verification of the release's *behaviour* was attempted: whether a commander asks its first question in the owner's language, and whether a Member's phone can now register for notifications, are the plan's "what to check" items and they need a human with a browser. Hard-refresh before judging either — a stale bundle looks exactly like a failure. - Documentation was not checked or edited. `bun run docs:check` is the release-cutter's step, not this agent's.