You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Cold read of the live front door, 2026-09-03. This is about which rows the overview picks, not how a row is drawn — #61 covers weight and scannability, and the row--routine demotion shipped from it.
ci: adopt pr-claim, so PRs here are checked against a live Front Desk claim
Four of the five are the same sentence. The Claims panel has the same shape: all five rows are .github standing claims (#273, #274, #278, #279, #280).
Why, from the source
selectPrs and selectClaims sort repo-then-number and do not rank — deliberately, per the #10 comment, which I read and agree with for the list pages. selectOverview then takes .slice(0, head) with OVERVIEW_HEAD = 5.
Repo-then-number across 70 rows makes "the first 5" mean "the five alphabetically-earliest repositories". .github, anchored-chain, audit-context, auth, await-approval are not a sample of the org's open work. They are the top of the alphabet, and they will stay the top of the alphabet until those PRs merge. The panel is stable the way a stuck gauge is stable.
The distinction I want to draw
#10's reasoning is that ordering claims by board Status was worse than saying nothing, because Status was wrong on all five live rows it was checked against. That is right, and "say nothing" is a fine answer for a page that shows all 9 claims: the reader sees the whole set, and the order carries no claim.
The overview is a different object. It shows 5 of 70 and prints "Showing the first 5 of 70". Slicing an intentionally-meaningless order converts "this order means nothing" into "these five mean nothing", and nothing on the page says so. #61 put the principle exactly: "the board vouches for a count." The overview vouches for a count and then fills the space with an alphabetical accident.
The Issues panel does not have this problem. It is score-ranked, so its first 5 really are its most important 5, and the desk's thesis holds there. That contrast is what makes the other two panels read as ranked when they are not.
Options
I do not think the answer is obvious, which is why this is a ticket rather than a patch.
Say what the five are. Keep the order, change the sentence: "5 of 70, by repository" costs one line and removes the misreading without touching selection.
Collapse the panel to its count. If no ordering is defensible, "70 open, awaiting a check" plus the link may beat five rows that mislead about what is on top.
(2) is the smallest thing that makes the panel honest. (1) is the one that makes it worth its vertical space. Worth deciding explicitly, because the current behaviour is a default rather than a decision.
Cold read of the live front door, 2026-09-03. This is about which rows the overview picks, not how a row is drawn — #61 covers weight and scannability, and the
row--routinedemotion shipped from it.What the front door showed me
The PRs panel, verbatim, all five rows:
.github#368anchored-chain#16audit-context#15auth#15await-approval#17Four of the five are the same sentence. The Claims panel has the same shape: all five rows are
.githubstanding claims (#273, #274, #278, #279, #280).Why, from the source
selectPrsandselectClaimssort repo-then-number and do not rank — deliberately, per the #10 comment, which I read and agree with for the list pages.selectOverviewthen takes.slice(0, head)withOVERVIEW_HEAD = 5.Repo-then-number across 70 rows makes "the first 5" mean "the five alphabetically-earliest repositories".
.github,anchored-chain,audit-context,auth,await-approvalare not a sample of the org's open work. They are the top of the alphabet, and they will stay the top of the alphabet until those PRs merge. The panel is stable the way a stuck gauge is stable.The distinction I want to draw
#10's reasoning is that ordering claims by board
Statuswas worse than saying nothing, becauseStatuswas wrong on all five live rows it was checked against. That is right, and "say nothing" is a fine answer for a page that shows all 9 claims: the reader sees the whole set, and the order carries no claim.The overview is a different object. It shows 5 of 70 and prints "Showing the first 5 of 70". Slicing an intentionally-meaningless order converts "this order means nothing" into "these five mean nothing", and nothing on the page says so. #61 put the principle exactly: "the board vouches for a count." The overview vouches for a count and then fills the space with an alphabetical accident.
The Issues panel does not have this problem. It is score-ranked, so its first 5 really are its most important 5, and the desk's thesis holds there. That contrast is what makes the other two panels read as ranked when they are not.
Options
I do not think the answer is obvious, which is why this is a ticket rather than a patch.
(2) is the smallest thing that makes the panel honest. (1) is the one that makes it worth its vertical space. Worth deciding explicitly, because the current behaviour is a default rather than a decision.