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, and the cause was a person, not a process. alpha was at be3139f9 rather than the 19bbbab9 the plan recorded, and fofos was at be3139f9. The deploy agent inferred auto-pull.sh on its minute crontab; that inference is wrong and is corrected here so nobody spends time hunting a mechanism that was not involved.

What actually happened: the session that cut this release also rolled alpha by hand before being stopped — the release is the releaser's job and the rollout is this commander's, and that line was crossed. fofos was at master for an unrelated reason: it had been deployed to repeatedly through the day during work on the fofos-website plugin.

So 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.

The auto-pull reading is worth keeping visible rather than deleting, because it is exactly the shape of a plausible wrong answer: a real cron, on the right machine, with the right effect, that had nothing to do with this. A host being unexpectedly current is evidence of something, and "the obvious candidate" is not the same as the cause.

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.