The gate the leaderboard trusts is pinned: src/result.ts gets the test file it never had #101

src/result.ts decides what the leaderboard is allowed to believe and it is the only module on the server with no test file of its own; give it one that says what a server accepts.

Every number on the board is the browser's word, and parseResult is the whole of the check. What tests it today is three lines inside src/server.test.ts ({ ...result(), extra: "ignored" }, null, "no") plus a few end-to-end posts. Nothing pins the arithmetic the file exists for: that headshots cannot exceed kills, that scoreMine + scoreTheirs must equal rounds, that the clock is bounded by the rounds it is spread over, that deaths cannot exceed rounds. Those four rules are the difference between a scoreboard and a text field, and any of them could be deleted right now with a green test run.

What done looks like

• [ ] src/result.test.ts exists and every rule in the file has a test that fails if that one line is removed. Verify that by removing each line and watching one test go red — say in the pull which line each test caught.
• [ ] The number parser is pinned at its edges: a float is floored, a negative is refused, each ceiling (MAX_ROUNDS, kills, damage, seconds) accepts its exact maximum and refuses one more, and NaN, Infinity, -0, "12", null, a boolean and a bigint-shaped object are each refused rather than coerced.
• [ ] matchId is pinned against its regex: 8 and 64 characters pass, 7 and 65 do not, a UUID from crypto.randomUUID() passes, and a matchId that is not a string is refused.
• [ ] cleanName is pinned: control characters become spaces, the result is trimmed and cut to 24 characters, an empty or whitespace-only name becomes anon, a non-string becomes anon, and an emoji or a combining mark is not cut into a broken code unit — or, if it can be, the test says so and the pull says whether that is acceptable.
• [ ] won is pinned on all four combinations of finished and score.
• [ ] A small deterministic fuzz: a seeded generator (a dozen lines of xorshift in the test file — do not import the engine from the server) makes a few thousand mutated bodies out of a valid one, and asserts parseResult never throws and that every non-null result it returns satisfies each invariant, checked independently of the code that produced it.
• [ ] bun test passes and nothing in src/result.ts changes — unless the tests find a bug, in which case fix it and say so in the pull.

Files

src/result.test.ts (new). src/result.ts only if a test finds something; possibly deleting the three now-redundant assertions from src/server.test.ts, which keeps its end-to-end posts.

Risks

The easy failure is a test file that restates the implementation line for line and catches nothing. The mutation check above is the guard: a test that stays green when its rule is deleted is not a test. Keep it a pure unit test — no server, no database, no fetch — so it runs in milliseconds.

Suggested: Torque — the same eye that pinned the models in #90 and the replay digests.

Parked by the crew: the check failed and the decider saw no point in another try (pull #167 closed). Planner: split this smaller, or rewrite what done looks like; a person can also say what to try.