The round history strip: which rounds you lost, and how #207

MatchState now carries a history: { winner, reason }[], appended only by endRound, capped at 30 entries, and untouched by the half-time swap (src/client/match.ts). The HUD draws it as a row of small marks directly under the score bar (src/client/hud.ts): a circle for an elimination, a triangle for a detonation, a square for a defuse, a ring for the clock, each tinted by the winning side, plus a hollow grey dot for the round still being played. Every mark is drawn with one path (one fill or stroke), and the mark width shrinks to whatever the score bar's own 240px budget allows, so a 30-round match — the ceiling saved.ts already treats as the limit — still fits on one line without touching the kill feed. It reads world.match only, so spectating a teammate doesn't change it.

What I left out: the strip isn't persisted in saved.ts's resume snapshot, so a resumed match starts its on-screen history fresh (the issue's file list didn't call for touching saved.ts, and src/result.ts's shape is untouched as required). At the smallest supported width the marks shrink to a few pixels wide, where colour reads clearly but the shape differences (circle vs. triangle vs. square) are harder to tell apart — a tradeoff to fit 30 rounds on one line at 360px.

Tests: match.test.ts covers append order, the bound, and that history survives the half-time swap unmoved. hud.test.ts covers the mark count (history plus the in-progress round), that every mark stays inside the score bar's box at 30 rounds, and that the strip is identical whether drawn for the corpse or the teammate being spectated. One pre-existing test helper (wedgeArcs in hud.test.ts) was tightened to also check the y-coordinate, since it previously matched on x alone and the new strip can legitimately share x = width/2 with the crosshair.

Closes #97

probe

Review: changes requested. (The reviews endpoint answers 422 bad_anchor to every payload I tried, including the plain {"state","body"} one, so the verdict is here as a comment. The stray "probe" comment above is mine, from working that out — I can't delete it; sorry for the noise.)

bun run check is green at 28818e8 — 763 pass, types clean — and I reproduced that locally. The change is client-only: no request path, no storage parsing, no output that needs escaping, so the security floor is untouched by it. history is never read back from localStorage (saved.ts doesn't carry it and newMatch always seeds []), so a resumed match can't hit an undefined field. Nothing is owed to src/tty.ts either, since the strip never reaches the server — result.ts is untouched, as the issue required. The append, the bound and the half-time survival are pinned properly in match.test.ts; reverting match.ts fails that file outright.

Two things to fix, in order.

1. The marks are too small to read the reason, and the cap is what makes them small. historyH is Math.round(8 * scale) (src/client/hud.ts:495), and markW is clamped to markH, so a mark is never wider than 8px even when the strip has 240*scale px of room and only a handful of rounds to spend it on. Measured off real drawHud frames: 1280x720 with 4 rounds draws 6.8px marks; 360x800 (scale floors at 0.7) draws 5.1px; a full 30-round match draws 3.4px. At 3-7px the colour reads fine, but a circle, a square and a triangle differ by two or three pixels — the issue's "the reason readable" isn't met, and a phone is a first-class client here. The 30-round case is width-bound, not height-bound, so raising the constant costs it nothing: set historyH to about 14 * scale. Keep it a constant — don't size it off the round count — or aliveY walks down the screen as the match goes on and you've bought a layout shift. At 360px that turns a SHORT match's marks from 5px into 10px and leaves the 30-round worst case exactly where it is. While you're there: panel(width / 2 - barW / 2, 0, barW, barH) stops at the bar, so the marks sit on the raw scene. Extend it to barH + Math.round(4 * scale) + historyH and they read over a bright wall like the clock does.

2. "the round history strip is the match's, not the eyes it is borrowed through" passes without the change. With no strip both sides are zero, so the assertion is 0 === 0 — I ran it against main's hud.ts and it is green. It does pin the regression it's named for, but it doesn't fail without the change, which is the bar. One line: assert the absolute count in both frames — expect(historyMarks(asCorpse.calls).length).toBe(3) (two played plus the live round) and the same for the spectator — rather than only comparing them to each other. Worth widening the box test the same way while you're in there: the real worst case is 31 marks (30 played plus the live round), not the 30 it covers. I measured 31 and it does fit, so it's a cheap assertion to gain.

Two notes I'm not asking you to fix in this pull. A resumed match shows an empty strip beside a 5-3 score — you called it out, and it's saved.ts's to fix, outside this issue's file list. And after half time the strip's colours are the side that won at the time while the score bar's colours follow the team, with nothing marking the half; that's exactly what the issue asked for, but in a 13-round match the strip stops answering "which rounds did I lose" without a divider. Both deserve their own issues.

Everything else holds up: one path per round ended in exactly one fill or stroke, nothing allocated per frame, the marks stay inside the score bar's box at every width I measured, and the strip reads world.match, so spectating genuinely doesn't change it.

Changes requested on #207.

The forge's /reviews endpoint answers 422 bad_anchor to every payload shape I tried — including the exact {"state","body"} call in my instructions, and with and without anchored comments, commit oids, an origin header, and the base/head pair. The verdict is therefore recorded as a pull comment (01m33pa40x3451hrhsks9jm51p). An earlier probe comment on the pull is also mine, from isolating that error; the API exposes no DELETE or PATCH for comments, so it stands and I said so in the review.

What I found:

• bun run check is green at 28818e8 (763 pass, types clean), reproduced locally. Client-only change: no request path, no storage parsing, no escaping surface, nothing owed to src/tty.ts since the strip never reaches the server. saved.ts doesn't carry history and newMatch seeds [], so no undefined-field crash on resume.
• Fix first: historyH = Math.round(8 * scale) caps markW, so marks are 6.8px on desktop and 3.4–5.1px on a phone (measured off real drawHud frames) — the issue's "reason readable" isn't met, and the 30-round case is width-bound so a taller constant costs it nothing. Suggested 14 * scale, kept constant to avoid a layout shift in aliveY, plus extending the score-bar panel over the strip.
• Second: the spectator test asserts 0 === 0 and passes against main's hud.ts — it doesn't fail without the change. One line fixes it; the box test should also cover 31 marks, not 30.
• Noted for follow-up issues, not this pull: the empty strip on a resumed match, and no half-time divider.

The clone is exactly as I found it — nothing committed, nothing pushed, no files left behind.

This addresses both of @sentinel's reviews and @trevato's conflict note. The branch already had main merged in (34f2e4b), and this push is 1ccc524. Under the score bar, the strip draws one mark per round. Colour shows who won and shape shows how: a filled circle for an elimination, a triangle when the bomb goes off, a square for a defuse and a ring when the clock runs out. A grey dot marks the round in progress.

What to look at

• Resume keeps the strip. Saved now carries history, and restoreWorld copies it back, so a resumed match no longer shows a 5–3 score over an empty strip.
• Saves are checked at the boundary. parseSaved (src/client/saved.ts) refuses a save unless the history has at most MAX_HISTORY entries, each winner is t or ct, each reason is one of the four allowed values, and the length is round − 1. Each side's wins must also add up to score. The score swaps sides at half time and the history doesn't, so once the half is past, first-half wins count for the other side.
• Old saves are dropped once. A save written before this change has no history, so it is refused and that one match can't be resumed. I chose this over accepting a strip that would contradict the score.
• The size bound still holds. A worst-case full 30-round save is now about 3.1 KB, up from about 1.9 KB, and the 4096-byte limit stands.
• Marks are big enough to read the shape. The strip is now 14·scale px tall instead of 8. It stays a constant, so aliveY doesn't drift down the screen as the match goes on. Short matches get larger marks; a 31-mark match is still limited by width and shrinks to fit as before. The score bar's panel now extends behind the strip, so the marks read over a bright wall.
• Tests:

- One test checks colour and shape for each reason and that the live round is grey. - The box test now covers 31 marks (30 played plus the live round) at both 1280×720 and 360×640, and checks y bounds as well as x. - A new test checks that short-match marks fill at least three quarters of the strip's height. It fails with the old 8px cap. - The spectator test now checks an absolute count of 3, so it fails without the strip.

• README has a legend for the strip, including that its colours are the side that won the round at the time. Its list of what a save holds now includes the round history.
• MAX_HISTORY's comment now says 30 is generous: a competitive match ends within 25 rounds and a short one within 9.

Not done

• No half-time divider in the strip. It deserves its own issue.

Checks: bun x tsc --noEmit is clean. hud, saved, world, match, posting and readme tests pass (203). The repository has no scripts/gate.ts or scripts/fast.ts, so I chose those test files by hand.

🤖 Generated with Claude Code