`bun run scripts/measure.ts`: what a hundred seeded rounds say about the round the bots play #65

Approved. I read all 294 lines, ran the script, and checked the branch merges clean onto current main.

What I verified

• The README's baseline is true and reproducible. bun run scripts/measure.ts at this branch's base (fccb9eb) printed exactly the table the README claims: 79 rounds, plant 58%, detonated 37 · time 20 · elimination 16 · defused 6, defuse 13% of planted, median 123s, longest 156s, 5.4s a match. Two runs at one seed differ only in the wall-clock lines, so the determinism the issue asked for holds. --rules long works too: 25 rounds at most, ~16s a match, which is why it is not the default.
• It merges and stays green. The branch is one commit on fccb9eb and main has since moved two ahead (#52, #42). Merged locally: no conflicts, 306 pass / 0 fail in 6.26s, against 6.20s for main alone, so these tests cost about 60ms. update(world, dt, input) and world.bombPlanted are untouched by either commit, so playMatch still steps the world main ships.
• No blast radius on the app. Nothing under src/ imports rounds.ts or measure.ts, and the built client is byte-identical on main and on the merge (static/app.8f08f8416e.js both times). No route, no request handling, no identity, no disk write, no dependency, no shell, no eval — the security floor and the terminal are simply not in this change's path, and there is no new capability for src/tty.ts to mirror.
• Round attribution is right. startRound clears world.bombPlanted, and a record is pushed on the tick the phase becomes "over", before the next freeze — so a detonated round still counts as planted. roundStart is set on over → freeze and starts at 0 for the first round, so no round's clock swallows the previous endDelay. maxTicksFor bounds a stuck match rather than looping forever, and 2 * winScore - 1 is the real ceiling (I saw exactly 9 and 25).
• Against the issue's list: every field it named is in the table; the arithmetic is a module and the script only parses, steps and prints; no test plays a match, which the issue explicitly required; the README section names the commit the numbers were taken at. Nothing touches bot behaviour, a CI gate, or browser frame time.

Nits, none blocking, worth a line if this is touched again

1. --seed -3 is silently turned into 4294967293 by seed >>> 0, while --matches -3 falls back to the default — two halves of one contract disagreeing. Rejecting a negative or non-integer seed the same way is one condition.
2. The README's "median round 123 s" is measured freeze-start to decided, so it includes freezeTime (8s) and the 40s fuse, which is how it exceeds the 115s round clock. The pull description says this; the README section does not, and that is where the next reader will look.
3. world.match.reason as EndReason is the change's one unchecked cast; the type is EndReason | null and it only happens to always be set at "over".
4. The sample is taken with an idle CT standing in spawn, so it is effectively 5v4 in the T's favour — stated honestly, but worth remembering before anyone argues bot balance from the detonated count.

Two things that are not yours. The preview at https://cs--65--forge-trevato-apps.open-platform.sh answers a bare 404 not found with no security headers from here, which is the edge rather than the app: the app's own 404 is HTML carrying the full floor, and booting the merge locally gives / at 200 with CSP, nosniff, Referrer-Policy and an HttpOnly session cookie intact, while the forge's pictures at this head show the page healthy on phone and desktop. And two comments reading probe — one on scripts/measure.ts line 72, one on the thread — are mine, left by a call while I worked out this API; there is no delete route, so please ignore them.

Approved at ec48014. All three nits from the first round are properly fixed, and I re-ran everything against today's main.

The fixes hold. Number.isInteger(seed) && seed >= 0 now rejects a negative or fractional seed the same way a negative --matches is rejected, with a test for each case and --seed 0 explicitly kept as a real seed rather than a falsy one — I confirmed end to end that --seed -3 prints seed 20260917 in the header line and --seed 0 prints seed 0. The as EndReason cast is gone, replaced by a null check that throws at the tick a round is recorded, and the now-unused type import went with it. The README says the round length is freeze plus whatever of the clock and the fuse ran, which is why the longest is past 115s, and it names the 5-on-4 idle-person caveat next to the numbers a reader would otherwise over-read.

Re-verified at this head. bun test is 264 pass / 0 fail at the head and 323 pass / 0 fail on a clean merge with today's main — note main has moved three commits on since the branch's base (#42, #66, #64), and createWorld's new optional difficulty parameter means this still compiles and runs untouched, on DEFAULT_DIFFICULTY. The defaults still print the exact table the README claims at fccb9eb (79 rounds, plant 58%, detonated 37 · time 20 · elimination 16 · defused 6, defuse 13%, median 123s, longest 156s). The built client is byte-identical to main's (static/app.8f08f8416e.js), nothing under src/ imports either new module, and the screenshots at this head show the page exactly as main has it on phone and desktop — no route, no identity, no body read, no rate limit, no storage, no dependency, and nothing new for src/tty.ts to mirror.

It already earns its keep. Running the same defaults on the merge with today's main gives 89 rounds, plant 60%, detonated 38 · time 24 · elimination 15 · defused 12, defuse 23% — the defuse rate has nearly doubled since fccb9eb, which is presumably #66's blast and #64's difficulty, and is exactly the kind of drift that used to be invisible. Two things for whoever merges, neither blocking: re-take the baseline block at the merge commit so the README opens on current numbers rather than a three-commit-old snapshot, and a --difficulty flag is now the obvious next flag, since the measurement silently pins whatever DEFAULT_DIFFICULTY happens to be.

The two comments reading probe on this pull are mine from working out this API in the first round; there is no delete route, so please ignore them.

I read every changed line, ran the suite at this head (90 pass, 0 fail), walked the preview as a guest, and ran src/tty.ts with FORGE_APP_USER_ROLE=user. The core of this is right and I want to say so first: ownership is decided in openOrder and nowhere else, the three ways in are an admin, buyer_id === who.id from the verified header, and a constant-time token compare; buyer_id is only ever written from ctx.who in placeOrder; forBuyer is parameterised with %/_ escaped and can only narrow; the anon POST /checkout writes no row, takes no stock and redeems no code (I confirmed on the preview: 303 to /checkout, cart intact); /orders/find now refuses an owned order in a miss's words, after the same digest, with nothing written to its trail; every page is cache-control: no-store, so opening an order by account rather than by URL token does not become a shared-cache leak. The terminal matches the page — as nora I got stock/orders/tax, 3 answered "That is an admin's to read." without drawing the tab, r was refused, / was offered — and desk.ordersFor is tested for nora/sam/admin/anon including % as a needle. The new behaviours all have tests that would fail without them.

Two things to do before this lands.

1. Fix first: the sign-in button this pull adds can land on a 404, which is the thing #42 just fixed. ordersPage passes path: returnTo(ctx.url), and it is also the renderer for a failed POST /orders/find — so on that page the new Sign in to see your orders button points at /__forge/signin?to=%2Forders%2Ffind, and GET /orders/find is a 404 (verified on the preview). A shopper who mistypes a guest lookup and then signs in lands on nothing. The page is always the /orders page, so the fix is to stop deriving it: pass path: "/orders" (the header's link on that response has the same target today and gets fixed with it). Worth a test alongside the existing "signing in from a page the token opened lands somewhere that answers".

2. It does not merge. Head 54055fa merges dc3c613, but main is now b40cb34 — #37, #48 and #53 landed since, and the forge reports conflicts in README.md and src/tty.ts. #53 rewrote desk.ts (an admin's change naming who made it) and #48 changed how bodies are read, so the merge lands on exactly the gating table this pull rewrites. Merge main, re-run bun test, and re-check the terminal gate by hand afterwards.

Smaller, take or leave:

• desk.needsAdmin is now called only from units.test.ts; tty.ts uses knows/mayPress. Either keep it as the thing the offered/gated invariant is stated in terms of, or drop it.
• payMock and the not-pending redirects still put ?token= back in the URL for a signed-in buyer who opened the order without one, writing the token into their history for no reason. order.buyer_id === "" ? "?token=…" : "" would keep it out.
• src/who.ts's comment on WITHOUT_SECRET still describes "Find an order" listing "the orders this browser placed"; that page is now an account's list plus a guest half.
• The pull description says /orders/find "still hands back the token for any order on number-plus-email, which is unchanged behaviour" — the code does the opposite, and the opposite is right. Please correct the description, since it is what the next reader trusts.

Nothing here is a data leak and nothing needs rethinking; fix the sign-in target, merge main green, and I will approve.

Disregard my previous comment on this pull (01m2sc8rd65qkjzr7jtdj8frex) - it is another pull's review text that a clobbered scratch file put here under my name, and it has nothing to do with this change. This comment is my review of #65.

Approved. I read every changed line, ran the pull's head out of tree (the clone untouched), and exercised scripts/measure.ts myself.

Verified

• bun test at 4a7068c: 344 pass, 0 fail, 7.3s. Main at 861e20b is 332 pass / 6.8s, so the twelve new tests cost about half a second and, as #45 asked, none of them plays a match.
• The README baseline reproduces exactly: the defaults printed rounds played 89, plant rate 60%, detonated 38 / time 24 / elimination 15 / defused 12, defuse rate 23%, median 123s, longest 156s, in 67.9s of wall clock (5.7s a match). Numbers a reader can check are worth more than numbers a reader must trust.
• Determinism holds: --matches 2 run twice printed a byte-identical table. --rules long --difficulty hard --matches 1 also works (20 rounds, 12.6s), so maxTicksFor is not clipping COMPETITIVE.
• The app still boots and the security floor is intact: / answers 200 in 18ms with CSP, X-Content-Type-Options, Referrer-Policy, Permissions-Policy and the HttpOnly session cookie unchanged. Nothing in the diff touches the server, the JSON API or src/tty.ts, so identity, body caps and rate limits are untouched: this is offline tooling, argv is its only input and it is validated (finite, positive, integer, enumerated), with no shell, no SQL, no eval, no secret and no new dependency.

The round accounting reads correctly. Every round passes through "over" before "match_over" (match.tick only promotes on the next tick), so no match loses its last round; world.bombPlanted is still this round's when that transition is seen, because startRound clears it on the over -> freeze edge; world.time is monotonic in update, and roundStart is re-armed on that same edge, half-time included. summarize is honest where it is easy not to be: an empty list gives zeros rather than NaN, a reason that never happened is counted zero rather than omitted, and the defuse rate is of planted bombs rather than of all rounds - each with a test that would fail without it.

It does what #45 asked and stops there: no bot behaviour changed, no CI gate on the numbers, nothing about browser frame time. The added --difficulty is a fair extension now that #64 has landed - documented, tested, defaulted to normal. The README's caveats (why a round runs past the 115s clock, why an idle person makes it effectively 5-on-4, that the baseline moved 13% to 23% defused across #66 and #64) are what will keep this useful in three months.

Nits, none blocking, none worth another round:

1. An unrecognised or misspelled flag is silently ignored - --match 40 runs the 12-match default and looks like it worked. One line rejecting an argv entry that starts with -- and is not a known flag would save someone a puzzled 70 seconds.
2. --matches has no upper bound; --matches 1e9 is accepted and runs until it is killed.
3. 1 matches in the wall-clock line.
4. src/client/rounds.ts lives in the client tree but nothing the browser bundles imports it. #45 sanctioned the location and the bundle is unaffected, so leave it - worth knowing only if src/client ever comes to mean "this ships".

The preview host 404s at / for me, but production 404s identically at the same moment and this pull changes no server code; the forge's screenshots at this head show the page and the leaderboard rendering normally.

probe