Does the policy transfer? The arena only knows de_forge, so nobody has measured the bots on the second map #165

Approved. Both gaps are closed, and I checked them the same way I found them.

The anchored line is the fix. I deleted the map argument from createWorld in createArena again, leaving everything else as written, and this time the suite went red — arena.test.ts:39, one fail out of twelve, on exactly the mutation that silently spawned de_cinder's cells inside de_forge's walls last round. The 75% in the README now has a test standing behind it rather than a coincidence. bun run check is green at ac4e67d, 699 pass, up the five scripts/duel.test.ts adds, and the four measured numbers reproduce exactly on this head: de_forge 175/29/36 shipped (73%) against 93/74/73 scripted (39%), de_cinder 181/31/28 (75%) against 103/70/67 (43%).

scripts/duel.test.ts is real too — I replaced the isMapName guard with a cast and it failed on the catalogue case, so the fallback that keeps a typo'd --map from reading as the other map's numbers is held down. Pulling the flag reader out into scripts/args.ts and having measure.ts share it was the nicer end of the nit; one three-line module named for one thing, both callers tested, and measure.test.ts is still green over it. (train.ts keeps its own arg() — a different helper with typed defaults, and leaving it alone is the right call for a change this size.)

The rest of the list has nothing to answer for. src/rl/arena.ts is reached only by scripts/train.ts and src/rl/{ppo,pool,shard}.ts, never by the server or the bundle, so no request, identity, body-cap or escaping surface moves; the only inputs are a script's own argv, validated against a closed catalogue; no shell, no SQL, no new dependency, no secret, no dead code. Nothing lands on the page or in src/tty.ts, so the two-doors rule is not in play, and CARD is untouched because the default path is untouched — which is what the unchanged arena tests prove.

The preview URL still answers 404 at / for me, and so does production, so I am reading that as the platform and not this branch; the forge's screenshots at this head render the menu, the map select and the leaderboard on phone and desktop, and the branch served locally answers / in ~11 ms with CSP, nosniff and Referrer-Policy intact.

Honest numbers, a commit cited instead of a hand-edited weights.ts, and a clear statement that the policy transfers rather than degrades. Ship it.

Close, and the measurement itself is sound — I reran it at 489c3d3 and got the README's four numbers exactly: de_forge 175/29/36 shipped (73%) against 93/74/73 scripted (39%), de_cinder 181/31/28 (75%) against 103/70/67 (43%). bun run check is green here too, 694 pass. No runtime surface is touched — src/rl/arena.ts is reached only by scripts/train.ts and src/rl/{ppo,pool,shard}.ts, never by the server or the bundle — so there is nothing to say about identity, request bodies, escaping or headers on this one. No new dependency, no secret, no dead code, and it is honest about CARD's 72%/42% rather than hand-editing weights.ts. One miss, and it is the line the whole pull rests on.

Fix first: the new test does not cover the change that produces the number. This anchored line is the only place the named map reaches the world, and nothing asserts it. src/rl/arena.test.ts checks where the duellists stand, and those coordinates come from openCellsOf(arena.map) in reset — not from the world. I deleted the map argument from this createWorld call, leaving everything else as written, and the whole arena suite still passed, 12 of 12. The arena was then spawning players on de_cinder's open cells inside de_forge's geometry — wrong walls, wrong line of sight, wrong bullets — and bun run scripts/duel.ts --map de_cinder returned 67%/36% instead of 75%/43%. That is an eight-point swing in the README's headline claim with a green check over it. World already carries map, so expect(arena.world.map).toBe(DE_CINDER) inside the loop you already wrote closes it; a canSee assertion across a pair of cells the two maps disagree about would be stronger still.

Second: scripts/duel.ts's parseArgs is exported and has no test, while its twin in scripts/measure.ts has scripts/measure.test.ts beside it reading the same --map/--seed flags — including a case whose comment is exactly this failure: “a typo that silently measured the default map again would read as the new map's numbers.” duel.ts falls back to de_forge on any unknown --map, which is the right behaviour and safe — I checked that --map ../../etc/passwd and --duels -5 --seed abc all print de_forge's numbers under a de_forge heading — but it is silent, and a scripts/duel.test.ts in the shape of measure.test.ts is the cheap way to keep it. Optional while you are there: this parseArgs re-implements measure.ts's flag reader almost verbatim, and one shared reader would suit the repo's one-concept-per-module shape. Nit, not a blocker.

The preview URL answers 404 at / for me right now, but production answers 404 too and the forge's screenshots at this head render the menu, the map select and the leaderboard on both phone and desktop, so I am reading that as the platform rather than this branch; serving the branch locally, / answers 200 in 11 ms with CSP, nosniff and Referrer-Policy intact. Nothing on the page or in src/tty.ts changes here, so the two-doors rule has nothing to answer for.

Add the arena.world.map assertion and the duel.ts argument test and this is a straight approve — the work behind it is right, and the honesty about the CARD drift is the best part of it.