---
name: project-patch-stack
description: "patch stack architecture plan — geckos+braid+WAS+plan98.js, sequencing, what's missing"
metadata: 
  node_type: memory
  type: project
  originSessionId: 41c331c6-05ce-43bc-a61f-585f976f5104
---

Four layers for collaborative state:
- geckos: ephemeral fast lane, P2P after signaling, dies with session
- braid: server in-memory snapshot, new subscribers catch up from here
- WAS: ground truth snapshot, survives reload + server restart
- plan98.js: reducer sandbox, broadcast callback already fires on every teach

**What already exists in plan98.js:**
- `createStore` has `broadcast` callback (line ~640)
- geckos `stateUpload`/`stateDownload` events send serialized reducers: `{ mergeHandler: fn.toString(), parameters: [] }`
- `secureEval` sandboxes the reducer string on the receiving end
- geckos client connects to plan98-multiplayer container on port 9208

**What plan1 is missing:**
- geckos server (plan98-multiplayer container handles it; plan1 needs its own or to reuse)
- braid Version/Parents framing on geckos messages (the missing link)
- geckos signaling endpoint in plan1's server.js

**Warm boot story (already works):**
wasLoad() → WAS snapshot → subscribe() → if braid empty, merge guard pushes WAS state back up → other tabs follow

**WAS patch log:** only makes sense after braid switches from full snapshots to named ops. Right now "patch log" = duplicate snapshots = no value.

**Why:** VPN-trusted service. No CIDs, no Ed25519 signatures on patches, no reducer registry file needed. The sandbox guards scope leakage; VPN guards peer identity. Reducers are the functions in the elf — discovery is the codebase.

**How to apply:** When starting geckos work in plan1, port the plan98-multiplayer server logic into plan1/server.js or start the plan98-multiplayer container on port 9208.