Files
platform/deploy/2026.08.23.06.report.md
2026-08-24 02:26:08 +00:00

8.6 KiB

2026.08.23.06 — deploy report

5 of 5 target hosts succeeded. Two hosts skipped by design: officer-dev (the host running the rollout) and edge-pertento-bridge (listed under Deliberately skipped in docs/servers.md).

Every host went e15ab230 → 2646842c by git merge --ff-only deploy/2026.08.23.06. No host was ahead, none had diverged, and no tracked file was dirty anywhere. --force was never used and no SQL beyond the plan's block was run.

Per host

alpha — ✅

  • HEAD e15ab230 → 2646842c, remote SSH, tree clean, no untracked files.
  • SQL: both blocks applied. RAISE EXCEPTION did not fire — no role held a provisioning_script. DELETE FROM command_hq_sessions removed 0 rows; the table was already empty.
  • Verified by query on officer_dev: Developer grants_postgres=t grants_docker=t; Admin, Member, Super Admin all f/f; provisioning_script absent (0 columns); dir_name and reference_paths present NOT NULL, session_id nullable.
  • bun db:push exit 0, no prompt. Seed reported 0 seeded, 4 already present — the Developer flags were written by the seed's re-assert path, confirmed by re-querying after the push, not by the message.
  • bun run plugins:update — 13/13 in 54s, exit 0, capabilities: pulled. Every plugin's sidecar restarted as part of this step: atelier, bitcoin-wallet, email, gitea, invoices, jellyfin, minesweeper, music, offscale, photos, soulseek, transmission, vault.
  • Orphan removed: capabilities/affordances/officerdev/ existed and was deleted. Capabilities tree clean afterwards — no leftover ?? extensions/, so the new .gitignore had already arrived.
  • pm2 restart officer — restart_time 72 → 73. All 20 processes online.

fofos — ✅

  • HEAD e15ab230 → 2646842c, remote HTTPS, no tracked changes.
  • Untracked file left in place: scripts/chk.ts. Noted, not a reason to skip, not touched.
  • Database is officer, not officer_dev, and the URL is in OFFICERDEV_POSTGRES_URL rather than POSTGRES_URL. Matched the code's own precedence (OFFICERDEV_POSTGRES_URL ?? POSTGRES_URL, officer_db/src/db.ts:9) so the migration went to the database the server actually opens.
  • SQL: both blocks applied, exception did not fire, DELETE removed 0 rows.
  • Verified by query: Developer t/t, other three f/f, provisioning_script absent, dir_name and reference_paths NOT NULL, session_id nullable.
  • bun db:push exit 0, no prompt, no plugin schemas on disk.
  • bun run plugins:update — 1/1 in 7s, exit 0, capabilities: pulled. officer-gitea sidecar restarted by this step.
  • Orphan removed: capabilities/affordances/officerdev/ deleted; tree clean afterwards.
  • pm2 restart officer — 25 → 26. All 8 processes online.

macbookpro — ✅ (awake, with two deviations worth recording)

  • HEAD e15ab230 → 2646842c, remote SSH, tree clean, no untracked files.
  • SQL: both blocks applied. psql is at /opt/homebrew/opt/libpq/bin/psql and on the non-interactive PATH, as the plan said. DELETE removed 0 rows.
  • Verified by query: Developer t/t, other three f/f, provisioning_script absent, dir_name and reference_paths NOT NULL, session_id nullable.
  • bun db:push exit 0, no prompt, run with /opt/homebrew/bin appended to PATH.
  • bun run plugins:update — exit 0, but no plugins installed — nothing to update, so the step exited before its capabilities pull. See What I could not do below.
  • No orphan to remove. ~/projects/officer-suite/capabilities is not a git checkout — it holds only empty agents/ extensions/ processes/ skills/ tasks/ tools/ and has no affordances/ at all.
  • pm2 restart officer (run as its own command, PATH untouched) — 12 → 13. All 6 processes online.

production-pertento-bridge — ✅

  • HEAD e15ab230 → 2646842c, remote HTTPS, tree clean, no untracked files.
  • SQL: both blocks applied, exception did not fire, DELETE removed 0 rows.
  • Verified by query on officer_dev: Developer t/t, other three f/f, provisioning_script absent, dir_name and reference_paths NOT NULL, session_id nullable.
  • bun db:push exit 0, no prompt. Its shell prints an nvm/.npmrc globalconfig warning before every command — cosmetic, pre-existing, unrelated to this release.
  • bun run plugins:update — 1/1 in 5s, exit 0, capabilities: pulled. officer-gitea restarted.
  • Orphan removed: capabilities/affordances/officerdev/ deleted; tree clean afterwards.
  • pm2 restart officer — 4 → 5. All 15 processes online (nine of them are this host's non-Officer Pertento jobs — Crons, Dashboard, Tracking, Uptime — none of which were touched).

deadpool-rezio-bridge — ✅ (login br)

  • HEAD e15ab230 → 2646842c, remote HTTPS, tree clean, no untracked files.
  • Database is officer via OFFICERDEV_POSTGRES_URL, same shape as fofos.
  • SQL: both blocks applied, exception did not fire, DELETE removed 0 rows.
  • Verified by query: Developer t/t, other three f/f, provisioning_script absent, dir_name and reference_paths NOT NULL, session_id nullable.
  • bun db:push exit 0, no prompt, 2 plugin schemas (email, offscale).
  • bun run plugins:update — 2/2 in 8s, exit 0, capabilities: pulled. The email plugin advanced c60e3d6 → c1c3674 — the only plugin anywhere in this rollout that was not already current. officer-email and officer-offscale sidecars restarted by this step.
  • No orphan, as the plan predicted; checked anyway and affordances/officerdev does not exist.
  • pm2 restart officer — 10 → 11. All 9 processes online.

Skipped

  • officer-dev — the host this rollout ran from. Nothing pulled, nothing restarted. Confirmed current rather than assumed: HEAD is 2646842c, the tag's commit, and a direct query shows Developer t/t with the other three f/f, provisioning_script absent, dir_name/reference_paths present and session_id nullable. Its own officer process is untouched and still runs the pre-restart build of this commit — the owner restarts it deliberately, as the last step.
  • edge-pertento-bridge — in Deliberately skipped since 2026-08-23. Not contacted, no retry budget spent.

Commanders deleted

None, on any host. command_hq_sessions held 0 rows everywhere — every DELETE reported DELETE 0. Each host was counted by query before the delete ran, so this is measured rather than inferred. Nobody's standing job was removed by this release.

officer-dev's one commander, Platform Deployer, had already been deleted there before the rollout began, per the plan.

What I could not do

  • macbookpro did not get the capabilities pull. bun run plugins:update exits early with no plugins installed and never reaches the capabilities repository, which the plan named as how the new .gitignore arrives. It does not matter on that host — its capabilities directory is not a git checkout, so there is no repository for a .gitignore to land in and no affordances/ to be duplicated. I did not invent a git pull the plan had not authorised. Nothing is outstanding on that host; the note is about the step's shape, not a missing change.
  • The release's own "what to check" list is unrun. Asking an agent to name its skills, switching a panel to Swedish, and creating a commander to confirm it produces a directory are interactive checks in a browser. This deploy agent cannot make them, so no host has been confirmed working by use — only by schema query and process state.
  • officer-dev needs pm2 restart officer to run the code it already has checked out.

Two things worth carrying forward

fofos and deadpool-rezio-bridge name their database differently from the other three — the URL lives in OFFICERDEV_POSTGRES_URL and the database is officer, not officer_dev. Any future plan step that reaches for POSTGRES_URL alone will connect to a socket that is not there, which is what it did here on the first attempt. The code's precedence is OFFICERDEV_POSTGRES_URL ?? POSTGRES_URL; follow it rather than either name.

The seed's own output does not prove the Developer flags were written. It prints 0 seeded, 4 already present on every host, because it counts inserts and the roles already existed — while the flags are re-asserted by a separate update path. On all five hosts the flags read f/f immediately after the SQL and t/t only after db:push. Nothing was wrong; the message is simply not the evidence, and the query after the push is.