Sharpee multiuser — world-model as replicated state

Reading the diagram

• Orange (authoritative) — the sandbox owns execution and the canonical WorldModel. Same as today; ADR-153 isolation untouched.
• Blue / green (mirrors) — server and each client hydrate a local WorldModel from the snapshot the sandbox attaches to every OUTPUT. Reads only; no writes.
• The dashed gray arrows are commands flowing down (browser → WS → server → IPC → sandbox). The orange arrows are OUTPUT flowing up, now carrying a serialized world along with text blocks and events.
• StatusLine, transcript enrichment, future map / inventory / scope-aware UI all read from the local mirror — same contract as Zifmia's useGameState.

What this changes vs. today

• tools/server/src/wire/server-sandbox.ts — extend Output with world: SerializedWorld; same on Restored.
• tools/server/src/sandbox/deno-entry.ts — call world.toJSON() after executeTurn and after RESTORE; attach to the outbound frame.
• tools/server/src/wire/browser-server.ts — extend story_output and restored with the snapshot.
• tools/server/src/rooms/room-manager.ts — keep a per-room hydrated WorldModel; refresh on each turn.
• tools/server/client/src/state/roomReducer.ts — accept and store the serialized world; hydrate into a real instance via React context.
• StatusLine.tsx, etc. — query the world directly. Identical pattern to Zifmia.

Open questions

• Snapshot bandwidth — full toJSON per turn vs. delta. Start full; measure; optimize only if it bites.
• Late-joiner sync — the welcome RoomSnapshot needs to include the latest world JSON so a fresh tab doesn't render blank until the next turn.
• Save/Restore alignment — the existing ISaveData blob and the per-turn snapshot can be the same shape, or two distinct shapes if saves want extra metadata.