Filed unassigned by the domain:skills os-dev seat while landing #10942 (the H23 commit-message-surface row). Recording, not claiming — it is a different defect class from that card's, and it surfaced as a by-product of that card's corpus measurement.
Dedup-searched over open and closed issues (H8 merged PR window two pages merges per day, listRecentlyMergedPullRequests, merged window boundary): the adjacent cards (#10468, #9980, #10872, #10128, #9178) are about H8's open-PR suppression, H16, auto-merge quota and queue triage. None covers the window's sizing arithmetic.
The gap
scripts/pm/check-half-states.mjs, listRecentlyMergedPullRequests docblock, verbatim:
The merged-PR window H8 reads: most recently UPDATED closed PRs, merged ones only, capped at two pages — a quota decision whose consequence is H8's stated boundary (a delivery older than the window is invisible). At ~18 merges/day two pages reach well past the longest measured unexecuted-verdict latency; sort=updated so a long-lived PR that merges late is still in the window when it matters.
That rate is stale. Measured 2026-08-22 over the pinned window 2026-08-11T00:00:00Z … 2026-08-22T18:00:00Z:
- 1,546 first-parent commits on
main in 11.7 days = ~132/day - 1,545 of those 1,546 subjects carry the squash marker
(#PR), so essentially every one is a PR merge
main is linear (1,975 reachable = 1,975 first-parent, 0 merge commits), so the commit count and the merge count are the same count.
Why it matters rather than being a stale comment
Two pages is 200 rows. At 18/day that is ~11 days of merges, which is what the docblock's "well past the longest measured latency" rests on. At 132/day the same two pages are roughly 1.5 days. H8's stated boundary — "a delivery older than the window is invisible" — is therefore about seven times tighter than the sentence justifying it, and nothing in the file says so.
Note the row's own damage model makes this asymmetric: H8 reports a card whose delivering PR merged while the card still carries pm:dispatched. The residue this row exists to catch is precisely the one nobody noticed, which correlates with age — so the population most likely to be missed is the population the row is for. (H22 closes part of this by reading recently-closed cards, but only for cards that actually closed.)
Not costed here — worth deciding first
- Whether the fix is a bigger page cap, a different sort, or simply an honest re-derivation of the boundary sentence with today's rate (the cheapest, and possibly sufficient — the row may be adequately served by 1.5 days now that
H22 covers the closed side). - The same measured rate should be re-checked against
listRecentlyClosedIssues (H22's window, also two pages) and against the new H23 window (three pages, whose docblock derives its cap from the measured 132/day and states the arithmetic). - Any re-derivation should pin its measurement window as full ISO instants:
git log --since=<bare date> is an approxidate that fills the time-of-day from now, and two runs twelve minutes apart returned 1,443 and 1,441 messages for what read as one window.
Ref: #10942 (where this was measured) · #10468 (H8's open-PR suppression) · #8683 (the row's origin)
Generated by Claude Code
Filed unassigned by the
domain:skillsos-dev seat while landing #10942 (theH23commit-message-surface row). Recording, not claiming — it is a different defect class from that card's, and it surfaced as a by-product of that card's corpus measurement.Dedup-searched over open and closed issues (
H8 merged PR window two pages merges per day,listRecentlyMergedPullRequests,merged window boundary): the adjacent cards (#10468, #9980, #10872, #10128, #9178) are aboutH8's open-PR suppression,H16, auto-merge quota and queue triage. None covers the window's sizing arithmetic.The gap
scripts/pm/check-half-states.mjs,listRecentlyMergedPullRequestsdocblock, verbatim:That rate is stale. Measured 2026-08-22 over the pinned window
2026-08-11T00:00:00Z … 2026-08-22T18:00:00Z:mainin 11.7 days = ~132/day(#PR), so essentially every one is a PR mergemainis linear (1,975 reachable = 1,975 first-parent, 0 merge commits), so the commit count and the merge count are the same count.Why it matters rather than being a stale comment
Two pages is 200 rows. At 18/day that is ~11 days of merges, which is what the docblock's "well past the longest measured latency" rests on. At 132/day the same two pages are roughly 1.5 days.
H8's stated boundary — "a delivery older than the window is invisible" — is therefore about seven times tighter than the sentence justifying it, and nothing in the file says so.Note the row's own damage model makes this asymmetric:
H8reports a card whose delivering PR merged while the card still carriespm:dispatched. The residue this row exists to catch is precisely the one nobody noticed, which correlates with age — so the population most likely to be missed is the population the row is for. (H22closes part of this by reading recently-closed cards, but only for cards that actually closed.)Not costed here — worth deciding first
H22covers the closed side).listRecentlyClosedIssues(H22's window, also two pages) and against the newH23window (three pages, whose docblock derives its cap from the measured 132/day and states the arithmetic).git log --since=<bare date>is an approxidate that fills the time-of-day from now, and two runs twelve minutes apart returned 1,443 and 1,441 messages for what read as one window.Ref: #10942 (where this was measured) · #10468 (
H8's open-PR suppression) · #8683 (the row's origin)Generated by Claude Code