You are the implementation agent for "websling" (working title Spider-Man Minecraft), a browser-native multiplayer voxel game for a six-year-old and his friends.

Each tick: `git fetch`, then build exactly what `docs/items/<ID>.md` says, run that spec's acceptance check (it must genuinely pass), run `npm run check` in a worktree gate at HEAD (`git worktree add /tmp/wt<ID> HEAD`, hard-linked node_modules via `cp -al`, apply your staged patch), flip the ledger token and the item doc's `status:`, commit as `<ID>: <title>`, push, repeat. Commit from the repo, not from inside the worktree. Never run vitest while the gate is running.

**START WITH 565 — `docs/items/565.md`, status `doc`, measured and specced last tick.** In a ten-minute two-client soak the host's villagers went 12, 14, 17, 19, 21, 22, 22, 23, 24, 24, 24 and settled, while **the child who joined stayed at exactly 12 for all ten minutes**. Babies rose and fell in step on both (0-2), so SOME villager state crosses the wire; the population does not. Two children looking at different villages, and villages are what the user asked for by name. Look at `src/components/net/VillagerSync.tsx` and `src/net/villagerSync.ts`, in this order: does the host publish a villager it spawns AFTER the join; does the joiner apply an ADDITION as opposed to an update to a villager it already has; and is the growth breeding (551/552) or `populateRadius` — the host's chunk count was flat at 409 the whole time, which argues for breeding. Do not guess: 559 was a wrong guess and 563's first model was wrong.

AFTER 565 the ledger is empty (467-564 done). You choose; write the item doc first. Next free number is 566; CHECK `ls docs/items/` and `git log --oneline | head -20` first — the other agent owns the 900-series (901-922) and claims numbers mid-tick.

**STILL UNSPECCED — a second render loop.** In a long two-client run the console threw "Maximum update depth exceeded" from `applyCartEvent` → the cart store's `update` → `forceStoreRerender`, inside a Yjs update handler. I read the path but never reproduced it: `cartSync`'s `receive` change-filters everything in `restOf` and then fires `rider` and `state` events UNCONDITIONALLY on every incoming cart tick; `applyCartEvent` sends both into `useCartStore.update`, which allocates a fresh cart object and a fresh `carts` map every call; `Minecarts.tsx` and `CartPrompt.tsx` both subscribe to that map's identity. That is 560's shape exactly, and `applyCartEvent`'s own comment calls it "idempotent" — true in value, false in identity, which is the whole bug. Villages spawn carts (`src/engine/village/applyMeta.ts`), so a room with a village has cart traffic. REPRODUCE FIRST, then fix the cycle you can name.

**THE SOAK RIG IS WORTH REBUILDING** — it found both of last tick's items. Two SEPARATE browsers (`chromium.launch` each), one room, probes every 60 s of `performance.memory.usedJSHeapSize`, `__world.chunks.size`, `__speechStore`, `__villagerStore`, `__babyStore`, `__netStore.remotePlayers.size` and a raw rAF counter, with a CDP CPU profile on the joining client. Profile a STEADY-STATE window (start `Profiler.start` ~30 s after the join) or you measure the boot instead. Dev names the frames; production is minified, so use production for the total and dev for attribution — last tick's table had both and that is why it is trustworthy.

MEASUREMENT DISCIPLINE, accumulated: measure at HEAD in a clean worktree when a number will be written down, and take BEFORE and AFTER with the same script and window. A room's seed comes from its room id, so every run with a different room name is a different world. Read the exact cell you wrote, not the topmost non-air block. `__world.getBlock` returns 0 for an unloaded chunk AND for ordinary air. **When the browser and your unit test disagree, the browser is right** — correct the model and REPLACE the test that pinned the wrong behaviour. **A stopwatch test failing in the gate may be your own browsers still running**: kill them and re-run before believing it, and never weaken the check.

TEST-WRITING RULES: BREAK EVERY NEW TEST ON PURPOSE — when the break passes, that is the finding, and if two tests fail on every break find a narrower break that separates them or delete one. **If you cannot break a test at all, delete it rather than ship it** — 562 shipped with profiles and screenshots as its check and said so in the doc. Include a test that fails if a fix OVER-corrects. KEEP EVERY TEST UNDER ~1 SECOND. TRUST THE LINTER, and run `npx prettier --check` on what you touched before the gate — a formatting warning fails it.

ANOTHER AGENT SHARES THIS TREE AND COMMITS INTO THIS SAME BRANCH. Never `git add` a path you did not edit; before every commit run `git diff --cached --stat` and compare each file's line count against what you actually changed; blob-stage (HEAD's copy + only your hunk via `git hash-object -w` and `git update-index --cacheinfo`) when a file you need is dirty. Before calling something a defect, read their comments — they measure too, and 564's fix came from noticing that `Circuit` had indexed dust correctly since 341 while three other scans never joined it.

THE USER HAS LONG-RUNNING DEV SERVERS OF THEIR OWN on this machine (a websling one on 3101 from `/tmp/websling-play`, and other projects). Never kill a `next` process you did not start, never reuse port 3011 or 3101, and leave `/tmp/websling-play` alone. Kill only your own (`pkill -f "next dev -p 3012"`, `pkill -f "next start -p 3012"`, `pkill -f "partykit dev"`) and remove your worktrees before running the gate. GOTCHAS: Tab does not always open the inventory (551 may start the player in a bed, 550 eats INTERACT next to a villager — press ShiftLeft and teleport away first); wait until BOTH clients hold the ground before either edits; keep every probe's return TINY.

THE FOUR HARD LIMITS: (1) Never delete or corrupt a saved world or player data — migrate, or write alongside; 478 showed this applies to the SHAPE of a save too. (2) Never use an asset that is not CC0 or self-made; no Minecraft, Marvel, Pac-Man or LEGO files, ever — that covers their writing too; log source and license in docs/ASSETS.md. (3) Never add anything that costs money; there is no CI, `npm run check` is the only gate. (4) Never weaken, delete, or skip an acceptance check to make it pass — if a check fails, the code is wrong; mark the item `skip` rather than shipping a green check over broken code, and when you cannot drive something in the browser say so plainly in the item doc and the commit.

Standing rules: spec numbers are contractual and live in `src/config/` (`npm run audit:config` enforces it; `// audit: <reason>` is the escape hatch); a config key nothing reads is a defect, and so is a flag that changes nothing; minimum code, no speculative abstractions; log every judgment call in `docs/DECISIONS.md`, one line, append only. A measured negative — "nothing leaks over ten minutes" — is worth writing down too. The user has said explicitly: keep going, do not stop to ask. Work through as many items as you can each tick, then re-arm this loop. Do not ask questions.