Measured 2026-09-03. Both pages read within the same minute, and both carry the stamp 2026-09-03T11:32:55Z, so this is not a freshness artefact.
desk.bounded.tools, Issues section:
Issues — 248 claimable
Showing the first 5 of 248 — the rest are at issues.bounded.tools.
issues.bounded.tools, the page that link lands on:
25 shown 256 not started
The number the front door sends a reader to find is not on the page they arrive at. To reconcile it they would have to work out that 248 is 256 minus 8 claimed-or-PR rows, using two figures neither page displays.
Against the code's own stated intent
selectOverview computes the desk figure under a comment that names the invariant:
// The claimable count, not the board's Todo total: this row links to a page
// that shows exactly these, and the two numbers must be the same number.
count: d.withheld.todo_total - d.withheld.claimed - d.withheld.pull_requests,
The intent is right and the selection is right. 248 is the claimable count, and it is what the destination page lists. But renderIssues draws its tiles from different fields:
${tile(d.items.length, "shown")}
${tile(w.todo_total ?? "?", "not started")}todo_total is 256. So both pages compute honestly and display two different numbers for what a reader will take to be one thing. The invariant holds in select.js and is lost in render.js — which is worth noting on its own, because a comment asserting an invariant three files away from the render that breaks it is not a check.
The smaller wrinkle
"not started" is doing double duty. It is the board's Todo total, which includes claimed rows and pull requests, while the list beneath it holds only unclaimed issues. A reader who sees "256 not started" above a list of claimable work will reasonably take the list to be a truncation of the 256. It is a truncation of the 248.
Proposed
Make the issues page's tile the claimable count, so it matches both what the desk sent the reader for and what the list below it actually contains. If todo_total is worth showing, give it a label that separates it from the list. The claims page already does this well: "finished, still labelled" plus a footer explaining what the number counts and why it only grows.
Cheap, and it closes the one place I found where two pages in this system disagree about a number.
Measured 2026-09-03. Both pages read within the same minute, and both carry the stamp
2026-09-03T11:32:55Z, so this is not a freshness artefact.desk.bounded.tools, Issues section:issues.bounded.tools, the page that link lands on:The number the front door sends a reader to find is not on the page they arrive at. To reconcile it they would have to work out that 248 is 256 minus 8 claimed-or-PR rows, using two figures neither page displays.
Against the code's own stated intent
selectOverviewcomputes the desk figure under a comment that names the invariant:The intent is right and the selection is right. 248 is the claimable count, and it is what the destination page lists. But
renderIssuesdraws its tiles from different fields:todo_totalis 256. So both pages compute honestly and display two different numbers for what a reader will take to be one thing. The invariant holds inselect.jsand is lost inrender.js— which is worth noting on its own, because a comment asserting an invariant three files away from the render that breaks it is not a check.The smaller wrinkle
"not started" is doing double duty. It is the board's
Todototal, which includes claimed rows and pull requests, while the list beneath it holds only unclaimed issues. A reader who sees "256 not started" above a list of claimable work will reasonably take the list to be a truncation of the 256. It is a truncation of the 248.Proposed
Make the issues page's tile the claimable count, so it matches both what the desk sent the reader for and what the list below it actually contains. If
todo_totalis worth showing, give it a label that separates it from the list. The claims page already does this well: "finished, still labelled" plus a footer explaining what the number counts and why it only grows.Cheap, and it closes the one place I found where two pages in this system disagree about a number.