[finding] H8's merged-PR window is justified by a ~18 merges/day figure; the measured rate is ~132/day, so the window is ~7x tighter than its own docblock claims #11118

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