scripts/pm/check-half-states.mjs 的 H8（「交付 PR 已合并、卡仍挂 pm:dispatched」）读一个按条数封顶的已合并 PR 窗口。那个条数当初是按一个明确写下的合并速率算的，而速率已经涨了约 11 倍，窗口因此缩到约一天。结果不是漏报个例，是一整段时间之前的交付全部落到视野之外。
未认领，只作记录。
机制（读码）
listRecentlyMergedPullRequests（scripts/pm/check-half-states.mjs:4082 附近）：
for (let page = 1; page <= 2; page++) {
const batch = await rest(
`/repos/${OWNER_REPO}/pulls?state=closed&sort=updated&direction=desc&per_page=100&page=${page}`,
);
out.push(...batch.filter((p) => p.merged_at));
if (batch.length < 100) break;
}页数的依据写在它自己的文档注释里（:4078）：
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
⚠️ 同一个文件里另外三处窗口都是 10 页（:3980 / :4066 / :4105），只有这一处是 2 页。
实测：前提已经过期约 11 倍
2026-08-30 取 state=closed&sort=updated&direction=desc&per_page=100 第一页，时间跨度：
| 读数 |
值 |
| 100 条 closed PR 覆盖 |
2026-08-30T02:47:19Z → 2026-08-30T14:44:30Z |
| 即 |
11.95 小时 |
| 折算 |
约 196 merges/day（注释前提：~18） |
| ⇒ 两页 200 条实际覆盖 |
约 24 小时 |
后果，本轮直接测到
对两仓所有仍挂 pm:dispatched 的开放卡，按分支前缀 head:claude/issue-<n>- 反查交付，再用 is:closed is:unmerged 反查确认合并状态：
- 52 张在飞卡中，24 张（46%）的交付 PR 已合并而卡未回标；
- 其中 14 张的交付合并于 2026-08-24 ~ 08-26，即滞留 4.6–6.0 天；
- 这 14 张全部落在 H8 约 24 小时的窗口之外 ⇒ 不是没人处置，是仪表已经看不见它们了；
- 最久的一张 objectui#5174 挂了 6.0 天，其席位早在 ACCEPT 里写明了终态（
Card returns to pm:queue）却没落成标签。
⚠️ 而滞留是有连带成本的，不只是账面难看：objectstack#11925 的 pm:dispatched 在交付合并后又挂了 5 天，期间 domain:cli 席位据此把 #12104 / #12034 / #12181 三张卡按热文件串行挂起不派（见 #11925 的 5443363161）。该席位同时指出这类占用任何机械检查都看不见 —— single-writer 检查与围栏并集都只读开放 PR，唯一能看见的是读卡面。⇒ 一个已合并未回标的 pm:dispatched，在这套机制里会伪装成一个活的独占写者。
（这 24 张已按各卡上已有的席位判定回标，2026-08-30，维护者指令。）
修法的形状（是建议，不是处方）
把封顶从条数改成时间：一直翻页直到 merged_at 早于 N 天（N 取「未执行判定的最长实测延迟」而不是一个页数），并保留一个页数上限作为配额兜底。这样速率再涨一次，覆盖的时间跨度不变。
⚠️ 两个必须一起做的：
- 把那句
~18 merges/day 换成从数据推导的量，或者至少让它在过期时会响 —— 一个写死在注释里的速率前提，正是这次失效的根。
- 两个方向都进自测（H8 用例在
:4963 附近）：窗口内命中要报；窗口外、但按新的时间判据仍应在内的交付也要报。
相邻但不是同一个缺陷
#11036（2026-08-22 立，仍是未分诊 finding）：H8 认交付只看 PR 正文的 Part of #N / closing keyword，不读分支名，写 Refs #N 就静默漏报。⚠️ 两个缺陷会叠加 —— 一笔用 Refs 拼法、又落在窗口之外的交付，H8 有两层看不见它。建议两张一起排。
没测的
域标签
刻意留空 —— domain:* 只由分诊席产出。与 #11036 同理，我的读法是它的 SUBJECT 是派发协议自身的门禁（比照 scripts/pm/check-governed-merges.mjs 归 domain:skills 的先例），但这一判归分诊。
scripts/pm/check-half-states.mjs的 H8（「交付 PR 已合并、卡仍挂pm:dispatched」）读一个按条数封顶的已合并 PR 窗口。那个条数当初是按一个明确写下的合并速率算的，而速率已经涨了约 11 倍，窗口因此缩到约一天。结果不是漏报个例，是一整段时间之前的交付全部落到视野之外。未认领，只作记录。
机制（读码）
listRecentlyMergedPullRequests（scripts/pm/check-half-states.mjs:4082附近）：页数的依据写在它自己的文档注释里（
:4078）：:3980/:4066/:4105），只有这一处是 2 页。实测：前提已经过期约 11 倍
2026-08-30 取
state=closed&sort=updated&direction=desc&per_page=100第一页，时间跨度：2026-08-30T02:47:19Z→2026-08-30T14:44:30Z后果，本轮直接测到
对两仓所有仍挂
pm:dispatched的开放卡，按分支前缀head:claude/issue-<n>-反查交付，再用is:closed is:unmerged反查确认合并状态：Card returns to pm:queue）却没落成标签。pm:dispatched在交付合并后又挂了 5 天，期间domain:cli席位据此把 #12104 / #12034 / #12181 三张卡按热文件串行挂起不派（见 #11925 的5443363161）。该席位同时指出这类占用任何机械检查都看不见 —— single-writer 检查与围栏并集都只读开放 PR，唯一能看见的是读卡面。⇒ 一个已合并未回标的pm:dispatched，在这套机制里会伪装成一个活的独占写者。（这 24 张已按各卡上已有的席位判定回标，2026-08-30，维护者指令。）
修法的形状（是建议，不是处方）
把封顶从条数改成时间：一直翻页直到
merged_at早于 N 天（N 取「未执行判定的最长实测延迟」而不是一个页数），并保留一个页数上限作为配额兜底。这样速率再涨一次，覆盖的时间跨度不变。~18 merges/day换成从数据推导的量，或者至少让它在过期时会响 —— 一个写死在注释里的速率前提，正是这次失效的根。:4963附近）：窗口内命中要报；窗口外、但按新的时间判据仍应在内的交付也要报。相邻但不是同一个缺陷
#11036（2026-08-22 立，仍是未分诊⚠️ 两个缺陷会叠加 —— 一笔用
finding）：H8 认交付只看 PR 正文的Part of #N/ closing keyword，不读分支名，写Refs #N就静默漏报。Refs拼法、又落在窗口之外的交付，H8 有两层看不见它。建议两张一起排。没测的
pm:dispatchedleaves the patrol's view forever; 129 have #10688 已记），那类本来就在它视野外。域标签
刻意留空 ——
domain:*只由分诊席产出。与 #11036 同理，我的读法是它的 SUBJECT 是派发协议自身的门禁（比照scripts/pm/check-governed-merges.mjs归domain:skills的先例），但这一判归分诊。