platform/deploy/2026.09.09.01.report.md

2026.09.09.01 — report

4 of 4 target hosts succeeded. officer-dev skipped entirely, as the host the rollout ran on. macbruno and both Pertento hosts skipped per the plan and docs/servers.md.

Every target ended at be3139f9 — the commit deploy/2026.09.09.01 points at. plugin_ports was verified by query on each host's own database, not inferred from db:push exit codes.

Two hosts were already at the tag before the rollout touched them. alpha was at be3139f9, not the 19bbbab9 the plan recorded, and fofos was at be3139f9 as expected. Something pulls these checkouts between a tag being cut and the rollout reaching them — auto-pull.sh on a minute crontab is the obvious candidate. Their merges were no-ops. Only macbookpro and deadpool-rezio-bridge were genuine fast-forwards, and they are also the only two where bun install had work to do.

Per host

Host	HEAD before → after	bun install	plugins:update	plugin_ports by query	officer restart_time	health
officer-dev	—	—	—	—	—	SKIPPED — the host this ran on
alpha	be3139f9 → be3139f9	no changes	16/17, exit 1	✓ present, 5 cols	10 → 11, online	401 (9000)
fofos	be3139f9 → be3139f9	no changes	4/5, exit 1	✓ present, 5 cols	380 → 381, online	401 (9000)
macbookpro	c97da029 → be3139f9	+ @anthropic-ai/sdk@0.71.2	no plugins installed	✓ present, 5 cols	0 → 1, online	401 (9010)
deadpool-rezio-bridge	c97da029 → be3139f9	+ @anthropic-ai/sdk@0.71.2	2/2, exit 0	✓ present, 5 cols	0 → 1, online	401 (9000)

401 on /api/health is healthy — the endpoint is behind auth. Ports were read from each .env.

The schema check run per host was select to_regclass('public.plugin_ports'), answered plugin_ports on all four, with columns id, app_name, name, port, allocated_at timestamptz. Databases: officer_dev on alpha and macbookpro, officer on fofos and deadpool-rezio-bridge. No db:push prompted for anything — < /dev/null was used on every host, as the plan required.

What the owner should act on

• plugins:update failed on two hosts, both for uncommitted work in a plugin checkout. Nothing was discarded. Each is one git commit or git checkout -- away from clean:
  • alpha — plugins/av-club at 62972c1, 3 modified: docs/SECURITY.md, sidecar/config.ts, sidecar/paths.ts. That plugin did not update on alpha and is still on its old checkout.
  • fofos — plugins/fofos-website at 7001eb0, 1 modified: frontend/Layout/Footer/Footer.tsx. Same consequence: that plugin did not update.
• alpha could not fetch. git fetch origin --tags failed with Connection closed by 77.42.39.155 port 22 — gitea's public SSH, rate-limited at the proxy. Its origin is git@gitea.officer.dev. It made no difference this time because the tag was already local, but a host that genuinely needed the tag would have failed there. The remote on that host is the thing that is wrong; pointing it at the tailnet address removes the whole class. The same recommendation was made in the 2026.08.30.03 report about macbookpro, which fetched cleanly today.
• macbruno was not attempted. The plan recorded it unreachable at cut time (Connection timed out, 2026-09-09) and named it skipped, so no retry budget was spent on it. It is at c97da029 as far as anyone knows and will be a real fast-forward whenever it is next reached.
• officer-dev still wants the marketplace column. plugins.release_tag in marketplace_db is out of scope for this rollout by the plan's own words — bun db:push covers officer_db only, and officer-marketplace runs on this host alone, which is the host the rollout skips. Whoever restarts officer-dev deliberately should apply it then. Nothing improvised a second push to reach it.

Not done, deliberately

• officer-dev — not pulled, not restarted, nothing touched. It is already at be3139f9 in code.
• macbruno, production-pertento-bridge, edge-pertento-bridge — skipped, no fault on any of them.
• The bunx tsgo error at src/servers/sidecar/claude/claude-manager.ts:667 was neither checked nor fixed. The plan names it as pre-existing and type-only; nothing in this rollout would have surfaced it.