Files
platform/deploy/2026.08.26.02.md
T
pastilhasandClaude Opus 5 121a77ce7f release 2026.08.26.02
one fix, and it is a crash: /browser fails to render with react #185 on every
host running .01 with the browser plugin installed, which is the fleet.

useAuthoredLayout takes structure from source every render, which is right and
is what lets a plugin's layout change reach people who already opened it. what
it did not account for is WorkspaceView repairing an unrecognised appType and
WRITING THE REPAIR BACK — self-limiting when structure was persisted, an
infinite loop when it cannot stick.

fofos is already at the fix by hand, mid-work. the plan says so rather than
leaving the commander to read it as drift.

no schema change, no dependency change, and officer-claude-code stays untouched
again — nothing here needs it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Officer-Session: 656f5c85-e49a-4f1f-b9f3-042a04b4d043
2026-08-26 04:31:51 +00:00

3.0 KiB

2026.08.26.02

One fix, and it is a crash. A screen whose layout names a panel it does not own now renders instead of failing with React #185, "maximum update depth exceeded".

No schema change. No dependency change. Do not run bun install. bun db:push stays a step because it is cheap and proves the database agrees with the code, but it must report no changes.

What broke, and where it shows

useAuthoredLayout shipped in 2026.08.26.01: a locked screen persists its SIZES and takes its STRUCTURE from source on every render. That is still right, and it is what lets a plugin change its layout and reach people who have already opened it.

What it did not account for is WorkspaceView's appTypes guard, which repairs an unrecognised appType and writes the repair back. That was self-limiting while structure was persisted — the repair stuck and the next render agreed with it. With structure coming from source it can never stick, so it is recomputed, rewritten, discarded and recomputed every render until React gives up.

The browser plugin's layout names officerdev/chat, which is not one of its own panel keys. So /browser fails to render on any host with that plugin installed. That is every host running 2026.08.26.01 with it — which is the fleet.

The fix drops a write whose result equals the current value. Not an optimisation: it is what terminates the loop, and persisting an identical tree was pointless anyway.

Every host

  1. git fetch origin --tags then git merge --ff-only deploy/2026.08.26.02
  2. bun db:push — expect no changes. If it wants to alter something, stop and report it.
  3. bun run plugins:update
  4. pm2 restart officer

fofos is already at the fix — it was fast-forwarded by hand at 05:22 to a7c9dab2 while the owner was working on it. Step 1 will fast-forward it to this tag anyway, which only adds the version bump and this plan. Nothing about that is a problem; note it rather than treating it as drift.

macbookpro: append /opt/homebrew/bin to PATH for the bun commands, run pm2 separately. Asleep is a skip with a note.

Do not restart officer-claude-code. Unchanged from the last release, same reason: it ends every live agent session on the host, and it is the owner's call. Nothing in this release needs it.

Hosts

  • officer-dev — skip it. Restarting officer there ends the rollout. It already has this code.
  • edge-pertento-bridge — skipped. Still 300+ commits behind with no roles table; its catch-up is a by-hand job. Do not contact it.
  • alpha, fofos, production-pertento-bridge, deadpool-rezio-bridge — the targets.
  • macbookpro — a target if it is awake.

What to check

Open /browser. It should render rather than showing "This screen failed to render". That is the whole release, and it is one click to confirm. Hard refresh first — a stale bundle looks identical to the bug.

No direct SQL is needed anywhere, and none is authorised.