## Recommended order of operations

Given where you are, I'd resist the urge to build all three subsystems at
once. The dependencies point to a specific sequence:

1. **Add `seq` to the RingBuffer and `lastAppliedSeq` to the worker.** This is
small, and everything downstream depends on it. You'll thank yourself later.
2. **Local persistence first (OPFS, not IndexedDB).** OPFS is dramatically
faster for many small writes, and it's synchronous inside a worker. Get
"reload the tab, world is still there" working. This forces you to nail down
the snapshot format without any network complexity.
3. **Then a single WS relay** (FastAPI or a 50-line Node `ws` server  both
fine). One server, two clients, verify seq ordering works. This is where
you'll discover whether your snapshot consistency story is actually right.
4. **Then bots.** Bots are just a WS client that reads the edit stream and
occasionally emits edits. Once step 3 works, bots are a Python script.
5. **RLE, compression tuning, WebRTC, claims/ownership, anti-cheat**  all
later, and only if profiling or gameplay demands them.

The proposal's big idea  the world is a log of sequenced edits, snapshots are
checkpoints  is the correct one. The missing piece is that **every one of
those words needs a sequence number attached**, and the proposal doesn't say
that anywhere. Fix that first and the rest becomes straightforward.