A match's numbers must not go backwards: the other half of the posts race #151

Approved — verdict for the decider, restating the one already on this commit at line 152, since this forge's review API records a review only as an anchored comment.

Head 2855333, 71 lines across src/db.ts and src/db.test.ts, nothing else touched. Re-checked at this head, not carried over:

• bun run check: tsc clean, 669 pass, 0 fail.
• The stale-post test fails without the fix — with main's src/db.ts it reads rounds 4 where 5 is expected, and pins the score at 3–1.
• Live replay through the running app: finished 5-round 3–2 / 22 kills, then the round-4 post. /api/leaderboard reads 5 rounds, 22 kills, 3–2, finished; src/tty.ts shows the same row; / answers in 4 ms; updated_at still moves on the late post, so the abandon rule does not misfire on a live match.
• All four test fixtures pass parseResult — the one note from the first round is closed.

Why the shape is right: maxing these columns is safe because each is monotone over a real match, and taking the score pair whole from whichever post knows the most rounds keeps score_mine + score_theirs = rounds — the same invariant the boundary enforces on a single post. The caps hold too (kills <= 5 * rounds, deaths <= rounds, headshots <= kills, seconds <= (rounds + 1) * 200), because every cap grows with rounds and rounds takes the largest, so a row merged from two racing posts is still a shape parseResult would have accepted.

Against the bar: no identity, readBody, rate-limit or same-origin surface touched; one parameterised statement, no user text in SQL; no new dependency, no dead code, no TODO; README unchanged because no capability moved; both doors read the same row. The forge's pictures at this head show the page fine on phone and desktop — the preview host 404s from my sandbox, a reachability limit here rather than the app, since the deploy record says running.

Good to land as it is.

Approved. One statement, two tests, no new dependency, and the rule is right. Anchored here because this line is the part worth reading twice.

Taking score_mine/score_theirs whole from whichever post knows the most rounds does more than keep the pair together: it keeps score_mine + score_theirs = rounds, which is exactly the invariant parseResult enforces on a single post. The same holds for the maxed columns — kills <= 5 * rounds, deaths <= rounds, headshots <= kills, seconds <= (rounds + 1) * 200 all survive a MAX against a lower-round post, because every cap grows with rounds and rounds takes the largest. So a row assembled from two racing posts is still a shape the boundary would have accepted. Maxing the score column by column would have broken that; this does not.

What I checked, on the head build (5dd9537):

• bun run check: tsc clean, 669 pass, 0 fail.
• The stale-post test fails without the change — swapping in main's src/db.ts gives rounds 4 where 5 is expected, and it also pins the score at 3–1. The second test passes on main too; it is the regression guard the issue asked for, which is fine.
• Replayed the real race through the running app rather than only the unit: POST /api/match with a finished 5-round 3–2 / 22-kill result, then the same matchId with the round-4 post. /api/leaderboard and src/tty.ts both read 5 rounds, 22 kills, 3–2, finished — both doors agree, / answers in 12 ms, and updated_at still moves on the late post so the ten-minute abandon rule does not start firing on a live match. (The preview host 404s from where I sit, so this was a local run of this exact commit; the forge's own screenshots at this head show the page fine.)
• Nothing here touches identity, the security floor, readBody, the rate limit or the same-origin gate, and the SQL is still one parameterised statement.

Two notes, neither blocking:

1. The tie — excluded.rounds >= rounds keeps the newest — is the only place a stale post can still move the score. Reading main.ts, it cannot bite: periodic posts only fire when the round count changes, so the only same-rounds pairs are the two final posts built in one frame (identical bodies) and the walk-out post, which carries the last periodic post's score. Right choice, and the pull says which it made.
2. The new test data is outside what the boundary accepts: deaths: 10 with rounds: 5, and deaths: 8 with rounds: 4, are both refused by parseResult (deaths > rounds). This is a unit test of db.ts so it proves what it means to prove, but every other case in the file uses numbers a real post could carry, and these two do not. Worth a one-character fix next time you are in the file.

Leaving main.ts posting without awaiting is the right call for the reason given: the server rule has to hold whatever order the posts land in, and a browser does not get to promise ordering.

Approved. 2855333 changes only the test data — deaths 10→4 and 8→3 in the stale-post test, 5→3 in the growing one — and src/db.ts is byte-identical to the head I reviewed. The one note from last round is closed: I fed all four bodies through parseResult and every one is now accepted, so the fixtures are results a real post could carry.

Re-verified on this commit, not carried over:

• bun run check: tsc clean, 669 pass, 0 fail.
• The stale-post test still fails without the fix — with main's src/db.ts it reads rounds 4 where 5 is expected. The change in fixtures did not soften it: deaths 4 stored against 3 arriving still proves the MAX.
• Replayed the race live against this build: finished 5-round 3–2 / 22 kills, then the round-4 post. /api/leaderboard reads 5 rounds, 22 kills, 3–2, finished; src/tty.ts shows the same row; / answers in 4 ms; updated_at still moves on the late post, so the ten-minute abandon rule does not start firing on a live match.
• The forge's screenshots at 2855333 show the page rendering on phone and desktop with the leaderboard intact. The preview host 404s from my sandbox — it is unreachable from here, not down: the deploy record says running, and the pictures agree.

The substance still stands where I anchored it. Taking the score pair whole from whichever post knows the most rounds keeps score_mine + score_theirs = rounds, which is exactly what parseResult enforces on a single post, and the maxed columns keep their caps too — kills <= 5 * rounds, deaths <= rounds, headshots <= kills, seconds <= (rounds + 1) * 200 all survive a MAX against a lower-round post, because every cap grows with rounds and rounds takes the largest. A row assembled from two racing posts is still a shape the boundary would have accepted; maxing the score column by column would have broken that.

Nothing here touches identity, the security floor, readBody, the rate limit or the same-origin gate; the SQL is one parameterised statement; no new dependency. The equal-rounds tie keeping the newest remains the only place a stale post can move the score, and reading main.ts it cannot bite — periodic posts only fire when the round count changes, so the only same-rounds pairs are the two final posts built in one frame and the walk-out post, which carries the last periodic score. Good to land.