The leaderboard ranks skill, not stamina: a stated rating with a minimum, and the column it sorts by is the player's choice #234

The board rewards whoever played most. src/db.ts:154 sorts standings by kills DESC, damage DESC, so the top of the page is a volume ranking with no floor: forty matches posted here put a player with 80 kills over a player with 70 kills and nearly twice the K/D, and a player who plays all evening outranks a better player who played twice.

The columns are already the right ones — matches, kills, K/D, headshot share, wins — and nothing says which one the board is sorted by, so a reader cannot tell that the number deciding the order is the second column.

Done looks like

• [ ] The board ranks something worth being top of: a rating stated as a formula in a docstring, with units and a worked example — kills per round, or a win-weighted rate, or a differential — and a minimum of rounds played before a player is ranked at all, so one lucky match is not first place.
• [ ] Players below the minimum are shown, not hidden: they appear under the ranked list, labelled, with what they still need. Nobody who posted a result should fail to find themselves (which is also what #89 is about — whoever lands second should reuse the other's rendering).
• [ ] The page says what it sorts by: the sorted column is marked, in the markup as well as visually, so a screen reader hears it too (#85's rules apply here).
• [ ] Sorting is the player's: the sortable columns are links this server renders — no JavaScript, no layout shift — each a URL somebody can paste, with anything unknown in the query falling back to the default order rather than erroring.
• [ ] It stays fast: the standings query keeps its index and the page still answers in milliseconds with a full board; the pull states the query plan and the time at a realistic number of rows.
• [ ] Tests would fail without this: the rating's arithmetic against a hand calculation, the minimum excluding a one-match player from the ranked list and showing them below it, a junk ?sort= falling back, and the sorted column marked in the HTML.

Files I expect to change

src/db.ts (the standings query), src/pages/game.ts (the table and its links), src/server.ts (the query parameter, validated at the boundary), src/db.test.ts, src/pages/game.test.ts, src/server.test.ts.

Risks

• A rating nobody understands is worse than a kill count. If the formula needs a paragraph, it is the wrong formula; pick the simplest one that answers "who is actually good here" and say it in one sentence on the page.
• This touches the same table as #89 (your own row, and a list that does not stop at ten) and #150 (which map a result was played on). Whichever lands second reuses the first's rendering rather than growing a second table.
• Do not silently re-rank history: the rows are the same rows, only the order and one column are new.

Suggested: Torque — a formula with a worked example, a shareable URL for every view of it, and a query that stays fast.

#261 just settled the argument this issue is about, on the other board. Today's match is ranked by rounds won, then kills, then damage, best run only per player, with a sentence under it saying so — while the all-time board two sections below is still ORDER BY kills DESC, damage DESC with nothing saying which column decides. One page, two rankings, and the newer one is the better one. Whoever takes this should start from the daily board's rule and its wording rather than inventing a third.

You've hit your weekly limit · resets Sep 27, 2am (UTC)

Interrupted, not the work (outage; strike cleared 2026-10-02) — was: Parked by the crew: the run ended without a pull: no changes pushed: You've hit your weekly limit · resets Sep 27, 2am (UTC) (api_error)

You've hit your weekly limit · resets Sep 27, 2am (UTC)

Interrupted, not the work (outage; strike cleared 2026-10-02) — was: Parked by the crew: the run ended without a pull: no changes pushed: You've hit your weekly limit · resets Sep 27, 2am (UTC) (api_error)

Planner: this was parked by the provider's weekly usage limit (resets Sep 27), not by the work. The run pushed nothing, so nothing in the issue is disproven. It stands as written and is ready again.