platform/deploy/2026.08.30.01.report.md

2026.08.30.01 — rollout report

7 of 7 targets succeeded. officer-dev skipped by design — it is the host the rollout ran on.

One plugin failed on one host (fofos-admin on fofos) and it is a false alarm in the checker, not a broken install. The owner fixed it mid-rollout in 537cc29c, which is NOT in this tag. Detail below.

No schema change, no bun install, no bun db:push — the plan says so and shows the two git diff --name-only commands behind the claim. Nothing was improvised.

Per host

Host	HEAD before	HEAD after	plugins:update	officer restart_time	/api/health	file-browser ls
officer-dev	—	—	—	—	—	SKIPPED — ran here
alpha	e9b71522	816f8695	15/15, exit 0	6 → 7	401	200, 77 entries
fofos	601849be	816f8695	4/5, exit 1	3 → 4	401	200, 39 entries
macbookpro	e9b71522	816f8695	no plugins installed	6 → 7	401	200, 62 entries
macbruno	e9b71522	816f8695	1/1, exit 0	9 → 10	401	200, 41 entries
production-pertento-bridge	e9b71522	816f8695	1/1, exit 0	7 → 8	401	200, 53 entries
edge-pertento-bridge	e9b71522	816f8695	2/2, exit 0	8 → 9	401	200, 29 entries
deadpool-rezio-bridge	e9b71522	816f8695	2/2, exit 0	25 → 26	401	200, 49 entries

Every host landed on 816f8695, exactly the tag. fofos started ahead of the previous tag and behind this one, as the plan predicted, so its fast-forward moved 12 files rather than 23.

401 on /api/health is healthy — the plan says so and all seven agreed. Ports were read from each host's own .env, never assumed: 9010 on macbookpro and production-pertento-bridge, 9000 elsewhere.

The file browser check

This release touched the listing loader, the clipboard and the row markup, so the plan asked for one signed /api/file-browser/ls per host. Seven hosts, seven 200s, every one with a plausible count and none of them zero. The counts differ because the homes differ.

Signed as that host's own owner, read from its own users table rather than assumed — conceiba@gmail.com on macbruno, brunorezio@gmail.com on deadpool-rezio-bridge, pastilhas@officer.dev on the rest.

Schema

No schema verification was performed, because this release changes no schema. No db:push step exists in the plan and none was run, so there is nothing to verify by query. The clipboard is a key in user_state, a JSONB column that already existed.

The plugin sidecars applied their OWN schemas during plugins:update, which belongs to the plugin updater and not to this release: music on alpha (4 tables), proxy-manager on fofos (3) and on macbruno (3), offscale on edge-pertento-bridge (1), email on deadpool-rezio-bridge (1).

The one failure: fofos-admin on fofos

bun run plugins:update exited 1 with:

FAILED: packages installed, but @tiptap/pm cannot be resolved from …/plugins/fofos-admin

The install is fine and the plugin is not broken. Verified on the host rather than assumed:

• plugins/node_modules/@tiptap/pm is present, with its dist and the prosemirror packages.
• @tiptap/pm declares no main, no module, and an exports map with no "." — it exists only as subpaths. Code imports @tiptap/pm/state, never the bare name.
• Bun.resolveSync('@tiptap/pm', pluginDir) therefore fails, while @tiptap/react and @tiptap/starter-kit both resolve. unresolvableDependencies reads that as a failed install.
• fofos-admin's own checkout is clean, so this is not the usual uncommitted-change cause.

Also verified there, and it is this release working as intended: react resolves out of the PLATFORM's node_modules, not the plugins tree. The eviction added in 9719e367 did its job.

The owner shipped the fix at 11:20 while the rollout was in flight — 537cc29c, "a package with no root entry point is not a broken install". It is one commit PAST this tag and is therefore deployed nowhere. fofos will keep failing that step on every plugins:update until a release carries it.

What this cost on fofos: fofos-admin did not finish its update — no assets publish, no access grant, no recorded at. Its code was already at the latest commit, and the platform mounted /fofos-admin normally. The other four plugins updated.

A commit landed on master mid-rollout, and the tag absorbed it

alpha, fofos, macbookpro, macbruno and production-pertento-bridge fetched origin/master at 816f8695. edge-pertento-bridge and deadpool-rezio-bridge fetched it at 537cc29c.

Because every host merged --ff-only deploy/2026.08.30.01 and not the branch, all seven are on the tag and none carries the extra commit. This is the exact failure of 2026-08-23, and merging the tag is what prevented it.

More restarted than officer

plugins:update restarts a sidecar whenever it moves a plugin, before the plan's own restart. Naming only officer would understate what moved, so: officer-music on alpha, officer-av-club on fofos, officer-gitea on production-pertento-bridge, officer-gitea and officer-offscale on edge-pertento-bridge, officer-email on deadpool-rezio-bridge. macbruno moved proxy-manager, which declares no sidecar, so nothing extra bounced there.

After every restart, pm2 jlist showed every officer* process online on all seven hosts. None was errored and none failed to come back.

ecosystem.config.cjs was never restarted anywhere. No vault was touched. On production-pertento-bridge the eight Pertento-owned processes — Dashboard, Tracking, Uptime and the five Crons * — were filtered out of every read and never named in a restart.

What I did not do

• officer-dev — skipped entirely. Not pulled, not restarted. The rollout ran inside its officer-claude-code sidecar, and restarting it would have ended the session writing this report. Its working tree already held this code. The owner restarts it deliberately, as the last step.
• Did not fix the fofos-admin checker. The fix exists in 537cc29c and belongs to a release, not to a rollout editing five hosts.
• Did not re-run plugins:update on fofos after diagnosing it. It would fail identically — the code that decides is in the tag.
• Did not run bun run docs:check. Not the commander's job.
• One untracked file noted, not touched: scripts/chk.ts on fofos. Untracked is a note, not a skip, and a fast-forward could never have touched it. Every host was clean on --untracked-files=no.