A world that starts from a snapshot: `restoreWorld`, without touching `createWorld`'s signature #148

Approved. Both findings from my last pass are fixed, and I checked the fixes rather than taking them on trust. (This forge's review API only stores an anchored comment — the verdict is here, on restoreWorld itself.)

What I ran at 159e0ba

• bun run check: tsc clean, 690 pass / 0 fail across 63 files, on the merge of main that brings #153's second map in.
• The app boots and / answers 200 in 17 ms, with the security floor intact (CSP, X-Content-Type-Options, Referrer-Policy). This diff touches no server code, no identity, no storage, no tty.ts — nothing on the security or both-doors list is in reach of it.
• Mutation, one behaviour at a time, to prove the tests bite:

- naive startTeam, no half-time flip → past half time, a restored player lands back in their own slot fails. Last round the whole branch could be deleted with 667/667 still green; now it cannot. The test plays a real SHORT match through update until the swap has actually happened and asserts round > halfTime first, so it cannot pass vacuously — exactly right. - drop the winScore guard → the decided-match test fails. - drop skipBotBuy → two tests fail. Covered from the first pass, still covered.

The change itself. buildWorld is the right seam and createWorld's signature is untouched, which is what #134 asked for. restorePlayer runs before startRound, so magazines and the held weapon are rebuilt from the restored slots rather than from the pistol makePlayer handed out. skipBotBuy is one named field with a comment saying why, set once and cleared by the startRound that reads it. The two refusals sit together at the top, before anything is built. No dependency, no dead code, no TODO, no commented-out code. The preview renders as it did before, which is the correct answer for a module nothing calls yet — the wiring is #135's, explicitly out of scope here.

One thing left, and it is not yours to fix here: #155. Saved records no map. It was written when de_forge was the only one; #153 landed a second, and restoreWorld defaults map to DE_FORGE, so the resume wiring has no source of truth to pass it — a resumed round 9 would be played on whatever the Map select happens to hold, with the score and money of a match played somewhere else. That is saved.ts's shape, not this diff, and #135 is told to keep off world.ts; I have opened #155 for the field and its validation and marked #135 blocked by it, so the resume never ships able to move the map under a player.

Good, careful fix. Land it.

The shape is right and the logic is right — I checked the hard part by hand and it works. buildWorld is the correct seam, createWorld's signature is untouched, skipBotBuy is one named thing with a comment saying why, restorePlayer runs before startRound so ammo and the held weapon are rebuilt from the restored slots, and the half-time replay does exactly what saved.ts's comment demands: I played a SHORT match past round 4, snapshotted it, restored it, and every one of the ten players came back with the same name, side, money, primary and pistol. No dependency, no server surface, no secret, nothing user-visible — correct for a change the issue scoped to world.ts alone. Check is green on the head (bun run check, 667 pass, run here).

The one thing to fix: the half-time replay has no test. Every test in the diff uses SHORT (halfTime = 4) at rounds 1, 2 and 3, so pastHalf is false in all three and the branch never runs. I confirmed it by mutation — replacing

const startTeam = pastHalf ? rules.other(save.playerTeam) : save.playerTeam;
...
if (pastHalf) for (const p of world.players) p.team = rules.other(p.team);

with the naive const startTeam = save.playerTeam; and no flip, and the full suite still passes, 667/667. That is the single subtlest line in the change, the one saved.ts wrote a paragraph warning about, and the one whose failure mode is silent and nasty: a restored player wearing the gear of whoever held their slot before the swap. It needs a test that would fail without it.

Concretely, one test, and it passes on your code today:

test("past half time, a restored player lands back in their own slot, not the pre-swap one", () => {
  const world = createWorld(SHORT, "me", "ct", 5, 777);
  while (world.match.round <= halfTime(SHORT)) update(world, NO_INPUT, 1 / 64);
  world.me.primary = "awp";
  world.me.money = 1234;
  world.players[7].primary = "ak47";
  const want = world.players.map((p) => ({ name: p.name, team: p.team, money: p.money, primary: p.primary, secondary: p.secondary }));
  const restored = restoreWorld(snapshot(world, crypto.randomUUID()));
  expect(restored).not.toBeNull();
  if (restored === null) return;
  expect(restored.players.map((p) => ({ name: p.name, team: p.team, money: p.money, primary: p.primary, secondary: p.secondary }))).toEqual(want);
  expect(restored.match.playerTeam).toBe(world.match.playerTeam);
});

(Stepping the match forward to past half time takes well under a second with SHORT; that is how I verified it.)

One smaller thing worth handling while you are in the file: parseSaved accepts score.t/score.ct up to winScore inclusive, so a snapshot of a decided match is valid input, and restoreWorld hands back a live freeze world with match.matchWinner === null — the match plays on past its own win condition. Either refuse a save whose score already reaches winScore (the same return null you already use for the player count, and it belongs next to it) or set matchWinner. A line of test either way.

Nothing else: no dead code, no TODO, no commented-out code, and the preview renders as it did before, which is the right answer for a change nothing calls yet.