finding: H8 的 merged-PR 窗口按「~18 merges/day」定成两页,实测已达 ~196/day —— 超过约 24 小时的交付对巡查结构性不可见(本轮实测 14 张滞留 4–6 天) #13499

Description

@os-project-manager

scripts/pm/check-half-states.mjs 的 H8(「交付 PR 已合并、卡仍挂 pm:dispatched」)读一个按条数封顶的已合并 PR 窗口。那个条数当初是按一个明确写下的合并速率算的,而速率已经涨了约 11 倍,窗口因此缩到约一天。结果不是漏报个例,是一整段时间之前的交付全部落到视野之外

未认领,只作记录。

机制(读码)

listRecentlyMergedPullRequestsscripts/pm/check-half-states.mjs:4082 附近):

for(letpage=1;page<=2;page++){constbatch=awaitrest(`/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:19Z2026-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 三张卡按热文件串行挂起不派(见 #119255443363161)。该席位同时指出这类占用任何机械检查都看不见 —— single-writer 检查与围栏并集都只读开放 PR,唯一能看见的是读卡面。⇒ 一个已合并未回标的 pm:dispatched,在这套机制里会伪装成一个活的独占写者。

(这 24 张已按各卡上已有的席位判定回标,2026-08-30,维护者指令。)

修法的形状(是建议,不是处方)

把封顶从条数改成时间:一直翻页直到 merged_at 早于 N 天(N 取「未执行判定的最长实测延迟」而不是一个页数),并保留一个页数上限作为配额兜底。这样速率再涨一次,覆盖的时间跨度不变。

⚠️ 两个必须一起做的:

  1. 把那句 ~18 merges/day 换成从数据推导的量,或者至少让它在过期时会响 —— 一个写死在注释里的速率前提,正是这次失效的根。
  2. 两个方向都进自测(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.mjsdomain:skills 的先例),但这一判归分诊。

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

    , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Add copy buttons to all
     blocks\n(function() {\n function addCopyButtons() {\n document.querySelectorAll('pre code').forEach(function(codeBlock) {\n if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;\n codeBlock.parentElement.setAttribute('data-copy-added', 'true');\n \n var btn = document.createElement('button');\n btn.textContent = 'Copy';\n btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';\n btn.onmouseover = function() { this.style.opacity = '1'; };\n btn.onmouseout = function() { this.style.opacity = '0.7'; };\n btn.onclick = function() {\n navigator.clipboard.writeText(codeBlock.textContent).then(function() {\n btn.textContent = 'Copied!';\n setTimeout(function() { btn.textContent = 'Copy'; }, 1500);\n });\n };\n codeBlock.parentElement.style.position = 'relative';\n codeBlock.parentElement.appendChild(btn);\n });\n }\n \n addCopyButtons();\n \n // Re-run on dynamic content\n var observer = new MutationObserver(addCopyButtons);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Add Copy Buttons to Code Blocks");
    }
    } catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
    })();
    (function(){
    try {
    var __m = "github.com";
    var __re = new RegExp('^' + "github\\.com" + '
    
    Skip to content

    finding: H8 的 merged-PR 窗口按「~18 merges/day」定成两页,实测已达 ~196/day —— 超过约 24 小时的交付对巡查结构性不可见(本轮实测 14 张滞留 4–6 天) #13499

    Description

    @os-project-manager

    scripts/pm/check-half-states.mjs 的 H8(「交付 PR 已合并、卡仍挂 pm:dispatched」)读一个按条数封顶的已合并 PR 窗口。那个条数当初是按一个明确写下的合并速率算的,而速率已经涨了约 11 倍,窗口因此缩到约一天。结果不是漏报个例,是一整段时间之前的交付全部落到视野之外

    未认领,只作记录。

    机制(读码)

    listRecentlyMergedPullRequestsscripts/pm/check-half-states.mjs:4082 附近):

    for(letpage=1;page<=2;page++){constbatch=awaitrest(`/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:19Z2026-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 三张卡按热文件串行挂起不派(见 #119255443363161)。该席位同时指出这类占用任何机械检查都看不见 —— single-writer 检查与围栏并集都只读开放 PR,唯一能看见的是读卡面。⇒ 一个已合并未回标的 pm:dispatched,在这套机制里会伪装成一个活的独占写者。

    (这 24 张已按各卡上已有的席位判定回标,2026-08-30,维护者指令。)

    修法的形状(是建议,不是处方)

    把封顶从条数改成时间:一直翻页直到 merged_at 早于 N 天(N 取「未执行判定的最长实测延迟」而不是一个页数),并保留一个页数上限作为配额兜底。这样速率再涨一次,覆盖的时间跨度不变。

    ⚠️ 两个必须一起做的:

    1. 把那句 ~18 merges/day 换成从数据推导的量,或者至少让它在过期时会响 —— 一个写死在注释里的速率前提,正是这次失效的根。
    2. 两个方向都进自测(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.mjsdomain:skills 的先例),但这一判归分诊。

    Metadata

    Metadata

    Assignees

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions

      , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Force GitHub README to respect dark mode\n(function() {\n var style = document.createElement('style');\n style.textContent = '\n .markdown-body {\n color-scheme: dark light;\n }\n .markdown-body pre { background: #161b22 !important; }\n .markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }\n .markdown-body table th, .markdown-body table td { border-color: #30363d !important; }\n .markdown-body img { background: #0d1117; }\n .markdown-body blockquote { border-left-color: #8b949e; }\n .markdown-body hr { border-color: #30363d; }\n ';\n document.head.appendChild(style);\n})();", "GitHub Dark Mode README Fix"); } } catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
      Skip to content

      finding: H8 的 merged-PR 窗口按「~18 merges/day」定成两页,实测已达 ~196/day —— 超过约 24 小时的交付对巡查结构性不可见(本轮实测 14 张滞留 4–6 天) #13499

      Description

      @os-project-manager

      scripts/pm/check-half-states.mjs 的 H8(「交付 PR 已合并、卡仍挂 pm:dispatched」)读一个按条数封顶的已合并 PR 窗口。那个条数当初是按一个明确写下的合并速率算的,而速率已经涨了约 11 倍,窗口因此缩到约一天。结果不是漏报个例,是一整段时间之前的交付全部落到视野之外

      未认领,只作记录。

      机制(读码)

      listRecentlyMergedPullRequestsscripts/pm/check-half-states.mjs:4082 附近):

      for(letpage=1;page<=2;page++){constbatch=awaitrest(`/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:19Z2026-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 三张卡按热文件串行挂起不派(见 #119255443363161)。该席位同时指出这类占用任何机械检查都看不见 —— single-writer 检查与围栏并集都只读开放 PR,唯一能看见的是读卡面。⇒ 一个已合并未回标的 pm:dispatched,在这套机制里会伪装成一个活的独占写者。

      (这 24 张已按各卡上已有的席位判定回标,2026-08-30,维护者指令。)

      修法的形状(是建议,不是处方)

      把封顶从条数改成时间:一直翻页直到 merged_at 早于 N 天(N 取「未执行判定的最长实测延迟」而不是一个页数),并保留一个页数上限作为配额兜底。这样速率再涨一次,覆盖的时间跨度不变。

      ⚠️ 两个必须一起做的:

      1. 把那句 ~18 merges/day 换成从数据推导的量,或者至少让它在过期时会响 —— 一个写死在注释里的速率前提,正是这次失效的根。
      2. 两个方向都进自测(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.mjsdomain:skills 的先例),但这一判归分诊。

      Metadata

      Metadata

      Assignees

      Type

      No type

      Projects

      No projects

        Milestone

        No milestone

        Relationships

        None yet

        Development

        No branches or pull requests

        Issue actions

        , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Highlight search terms from Google/DuckDuckGo/Bing referrer\n(function() {\n var ref = document.referrer;\n var terms = [];\n \n if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {\n var url = new URL(ref);\n var q = url.searchParams.get('q') || url.searchParams.get('p');\n if (q) {\n terms = q.split(/\\s+/).filter(function(t) { return t.length > 2; });\n }\n }\n \n if (terms.length === 0) return;\n \n var style = document.createElement('style');\n style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';\n document.head.appendChild(style);\n \n function highlight(node) {\n if (node.nodeType === 3) { // text node\n var text = node.textContent;\n var found = false;\n terms.forEach(function(term) {\n var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\\]\\\\]/g, '\\\\') + ')', 'gi');\n if (regex.test(text)) {\n found = true;\n var frag = document.createDocumentFragment();\n var parts = text.split(regex);\n parts.forEach(function(part, i) {\n if (i % 2 === 0) {\n frag.appendChild(document.createTextNode(part));\n } else {\n var span = document.createElement('span');\n span.className = 'userscript-highlight';\n span.textContent = part;\n frag.appendChild(span);\n }\n });\n node.parentNode.replaceChild(frag, node);\n }\n });\n } else if (node.nodeType === 1 && node.childNodes) { // element\n var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];\n if (!skipTags.includes(node.tagName)) {\n Array.from(node.childNodes).forEach(highlight);\n }\n }\n }\n \n highlight(document.body);\n \n // Re-highlight on dynamic content\n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1 || node.nodeType === 3) highlight(node);\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Highlight Search Terms"); } } catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
        Skip to content

        finding: H8 的 merged-PR 窗口按「~18 merges/day」定成两页,实测已达 ~196/day —— 超过约 24 小时的交付对巡查结构性不可见(本轮实测 14 张滞留 4–6 天) #13499

        Description

        @os-project-manager

        scripts/pm/check-half-states.mjs 的 H8(「交付 PR 已合并、卡仍挂 pm:dispatched」)读一个按条数封顶的已合并 PR 窗口。那个条数当初是按一个明确写下的合并速率算的,而速率已经涨了约 11 倍,窗口因此缩到约一天。结果不是漏报个例,是一整段时间之前的交付全部落到视野之外

        未认领,只作记录。

        机制(读码)

        listRecentlyMergedPullRequestsscripts/pm/check-half-states.mjs:4082 附近):

        for(letpage=1;page<=2;page++){constbatch=awaitrest(`/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:19Z2026-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 三张卡按热文件串行挂起不派(见 #119255443363161)。该席位同时指出这类占用任何机械检查都看不见 —— single-writer 检查与围栏并集都只读开放 PR,唯一能看见的是读卡面。⇒ 一个已合并未回标的 pm:dispatched,在这套机制里会伪装成一个活的独占写者。

        (这 24 张已按各卡上已有的席位判定回标,2026-08-30,维护者指令。)

        修法的形状(是建议,不是处方)

        把封顶从条数改成时间:一直翻页直到 merged_at 早于 N 天(N 取「未执行判定的最长实测延迟」而不是一个页数),并保留一个页数上限作为配额兜底。这样速率再涨一次,覆盖的时间跨度不变。

        ⚠️ 两个必须一起做的:

        1. 把那句 ~18 merges/day 换成从数据推导的量,或者至少让它在过期时会响 —— 一个写死在注释里的速率前提,正是这次失效的根。
        2. 两个方向都进自测(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.mjsdomain:skills 的先例),但这一判归分诊。

        Metadata

        Metadata

        Assignees

        Type

        No type

        Projects

        No projects

          Milestone

          No milestone

          Relationships

          None yet

          Development

          No branches or pull requests

          Issue actions

          , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Strip utm_, fbclid, gclid, etc. from all links on page\n(function() {\n var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',\n 'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',\n 'ref', 'ref_src', 'source', 'medium', 'campaign'];\n \n function cleanUrl(url) {\n try {\n var u = new URL(url, window.location.origin);\n var changed = false;\n trackingParams.forEach(function(p) {\n if (u.searchParams.has(p)) {\n u.searchParams.delete(p);\n changed = true;\n }\n });\n return changed ? u.toString() : url;\n } catch (e) {\n return url;\n }\n }\n \n function cleanLinks() {\n document.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n \n cleanLinks();\n \n var observer = new MutationObserver(function(mutations) {\n mutations.forEach(function(m) {\n m.addedNodes.forEach(function(node) {\n if (node.nodeType === 1) {\n if (node.tagName === 'A') cleanLinks();\n node.querySelectorAll('a[href]').forEach(function(a) {\n var clean = cleanUrl(a.href);\n if (clean !== a.href) a.href = clean;\n });\n }\n });\n });\n });\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "Remove Tracking Parameters from Links"); } } catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); } })(); (function(){ try { var __m = "youtube.com"; var __re = new RegExp('^' + "youtube\\.com" + '
          Skip to content

          finding: H8 的 merged-PR 窗口按「~18 merges/day」定成两页,实测已达 ~196/day —— 超过约 24 小时的交付对巡查结构性不可见(本轮实测 14 张滞留 4–6 天) #13499

          Description

          @os-project-manager

          scripts/pm/check-half-states.mjs 的 H8(「交付 PR 已合并、卡仍挂 pm:dispatched」)读一个按条数封顶的已合并 PR 窗口。那个条数当初是按一个明确写下的合并速率算的,而速率已经涨了约 11 倍,窗口因此缩到约一天。结果不是漏报个例,是一整段时间之前的交付全部落到视野之外

          未认领,只作记录。

          机制(读码)

          listRecentlyMergedPullRequestsscripts/pm/check-half-states.mjs:4082 附近):

          for(letpage=1;page<=2;page++){constbatch=awaitrest(`/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:19Z2026-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 三张卡按热文件串行挂起不派(见 #119255443363161)。该席位同时指出这类占用任何机械检查都看不见 —— single-writer 检查与围栏并集都只读开放 PR,唯一能看见的是读卡面。⇒ 一个已合并未回标的 pm:dispatched,在这套机制里会伪装成一个活的独占写者。

          (这 24 张已按各卡上已有的席位判定回标,2026-08-30,维护者指令。)

          修法的形状(是建议,不是处方)

          把封顶从条数改成时间:一直翻页直到 merged_at 早于 N 天(N 取「未执行判定的最长实测延迟」而不是一个页数),并保留一个页数上限作为配额兜底。这样速率再涨一次,覆盖的时间跨度不变。

          ⚠️ 两个必须一起做的:

          1. 把那句 ~18 merges/day 换成从数据推导的量,或者至少让它在过期时会响 —— 一个写死在注释里的速率前提,正是这次失效的根。
          2. 两个方向都进自测(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.mjsdomain:skills 的先例),但这一判归分诊。

          Metadata

          Metadata

          Assignees

          Type

          No type

          Projects

          No projects

            Milestone

            No milestone

            Relationships

            None yet

            Development

            No branches or pull requests

            Issue actions

            , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Auto-enable theater mode on YouTube\n(function() {\n function tryTheater() {\n var btn = document.querySelector('button[aria-label=\"Theater mode\"], ytd-player #player button[title=\"Theater mode\"]');\n if (btn && !btn.classList.contains('activated')) {\n btn.click();\n }\n }\n \n // Try immediately\n tryTheater();\n \n // Try after navigation (SPA)\n var lastUrl = location.href;\n setInterval(function() {\n if (location.href !== lastUrl) {\n lastUrl = location.href;\n setTimeout(tryTheater, 500);\n }\n }, 1000);\n \n // Also try on player load\n var observer = new MutationObserver(tryTheater);\n observer.observe(document.body, { childList: true, subtree: true });\n})();", "YouTube Theater Mode Default"); } } catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
            Skip to content

            finding: H8 的 merged-PR 窗口按「~18 merges/day」定成两页,实测已达 ~196/day —— 超过约 24 小时的交付对巡查结构性不可见(本轮实测 14 张滞留 4–6 天) #13499

            Description

            @os-project-manager

            scripts/pm/check-half-states.mjs 的 H8(「交付 PR 已合并、卡仍挂 pm:dispatched」)读一个按条数封顶的已合并 PR 窗口。那个条数当初是按一个明确写下的合并速率算的,而速率已经涨了约 11 倍,窗口因此缩到约一天。结果不是漏报个例,是一整段时间之前的交付全部落到视野之外

            未认领,只作记录。

            机制(读码)

            listRecentlyMergedPullRequestsscripts/pm/check-half-states.mjs:4082 附近):

            for(letpage=1;page<=2;page++){constbatch=awaitrest(`/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:19Z2026-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 三张卡按热文件串行挂起不派(见 #119255443363161)。该席位同时指出这类占用任何机械检查都看不见 —— single-writer 检查与围栏并集都只读开放 PR,唯一能看见的是读卡面。⇒ 一个已合并未回标的 pm:dispatched,在这套机制里会伪装成一个活的独占写者。

            (这 24 张已按各卡上已有的席位判定回标,2026-08-30,维护者指令。)

            修法的形状(是建议,不是处方)

            把封顶从条数改成时间:一直翻页直到 merged_at 早于 N 天(N 取「未执行判定的最长实测延迟」而不是一个页数),并保留一个页数上限作为配额兜底。这样速率再涨一次,覆盖的时间跨度不变。

            ⚠️ 两个必须一起做的:

            1. 把那句 ~18 merges/day 换成从数据推导的量,或者至少让它在过期时会响 —— 一个写死在注释里的速率前提,正是这次失效的根。
            2. 两个方向都进自测(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.mjsdomain:skills 的先例),但这一判归分诊。

            Metadata

            Metadata

            Assignees

            Type

            No type

            Projects

            No projects

              Milestone

              No milestone

              Relationships

              None yet

              Development

              No branches or pull requests

              Issue actions

              , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Remove or un-stick sticky/fixed headers that block content\n(function() {\n function unstick() {\n document.querySelectorAll('header, nav, [role=\"banner\"], .header, .navbar, .sticky, .fixed-top, [style*=\"position: fixed\"], [style*=\"position:sticky\"]').forEach(function(el) {\n if (el.style.position === 'fixed' || el.style.position === 'sticky' || \n getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {\n el.style.position = 'static';\n el.style.top = 'auto';\n el.style.zIndex = 'auto';\n }\n });\n }\n \n unstick();\n \n var observer = new MutationObserver(unstick);\n observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });\n})();", "Kill Sticky Headers"); } } catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); } })(); (function(){ try { var __m = "*"; var __re = new RegExp('^' + ".*" + '
              Skip to content

              finding: H8 的 merged-PR 窗口按「~18 merges/day」定成两页,实测已达 ~196/day —— 超过约 24 小时的交付对巡查结构性不可见(本轮实测 14 张滞留 4–6 天) #13499

              Description

              @os-project-manager

              scripts/pm/check-half-states.mjs 的 H8(「交付 PR 已合并、卡仍挂 pm:dispatched」)读一个按条数封顶的已合并 PR 窗口。那个条数当初是按一个明确写下的合并速率算的,而速率已经涨了约 11 倍,窗口因此缩到约一天。结果不是漏报个例,是一整段时间之前的交付全部落到视野之外

              未认领,只作记录。

              机制(读码)

              listRecentlyMergedPullRequestsscripts/pm/check-half-states.mjs:4082 附近):

              for(letpage=1;page<=2;page++){constbatch=awaitrest(`/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:19Z2026-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 三张卡按热文件串行挂起不派(见 #119255443363161)。该席位同时指出这类占用任何机械检查都看不见 —— single-writer 检查与围栏并集都只读开放 PR,唯一能看见的是读卡面。⇒ 一个已合并未回标的 pm:dispatched,在这套机制里会伪装成一个活的独占写者。

              (这 24 张已按各卡上已有的席位判定回标,2026-08-30,维护者指令。)

              修法的形状(是建议,不是处方)

              把封顶从条数改成时间:一直翻页直到 merged_at 早于 N 天(N 取「未执行判定的最长实测延迟」而不是一个页数),并保留一个页数上限作为配额兜底。这样速率再涨一次,覆盖的时间跨度不变。

              ⚠️ 两个必须一起做的:

              1. 把那句 ~18 merges/day 换成从数据推导的量,或者至少让它在过期时会响 —— 一个写死在注释里的速率前提,正是这次失效的根。
              2. 两个方向都进自测(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.mjsdomain:skills 的先例),但这一判归分诊。

              Metadata

              Metadata

              Assignees

              Type

              No type

              Projects

              No projects

                Milestone

                No milestone

                Relationships

                None yet

                Development

                No branches or pull requests

                Issue actions

                , 'i'); if (__m === '*' || __re.test(location.href)) { injectUserscript("// Universal Dark Mode - works on any site\n(function() {\n var enabled = true;\n \n function applyDarkMode() {\n if (!enabled) return;\n \n // Create style element if it doesn't exist\n var style = document.getElementById('universal-dark-mode-style');\n if (!style) {\n style = document.createElement('style');\n style.id = 'universal-dark-mode-style';\n document.head.appendChild(style);\n }\n \n // Dark mode CSS - inverts colors but preserves images/video\n style.textContent = '\n /* Invert everything except media */\n html {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #1a1a2e !important;\n }\n \n /* Restore images, videos, iframes, canvas */\n img, video, iframe, canvas, svg, picture, [style*=\"background-image\"] {\n filter: invert(1) hue-rotate(180deg) !important;\n }\n \n /* Preserve specific elements that should not be inverted */\n .no-dark-mode, .no-dark-mode *,\n [data-theme=\"light\"], [data-theme=\"light\"],\n .ace_editor, .ace_editor *,\n .CodeMirror, .CodeMirror *,\n .monaco-editor, .monaco-editor *,\n .markdown-body pre, .markdown-body pre *,\n .highlight, .highlight *,\n pre code, pre code * {\n filter: none !important;\n }\n \n /* Fix common UI elements */\n .modal, .popup, .dropdown-menu, .tooltip, .popover {\n filter: invert(1) hue-rotate(180deg) !important;\n background: #2d2d44 !important;\n border-color: #444 !important;\n }\n \n /* Scrollbars */\n ::-webkit-scrollbar { background: #1a1a2e !important; }\n ::-webkit-scrollbar-thumb { background: #444 !important; }\n ::-webkit-scrollbar-thumb:hover { background: #555 !important; }\n \n /* Selection */\n ::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }\n ';\n }\n \n function removeDarkMode() {\n var style = document.getElementById('universal-dark-mode-style');\n if (style) style.remove();\n }\n \n // Toggle with Alt+Shift+D\n document.addEventListener('keydown', function(e) {\n if (e.altKey && e.shiftKey && e.key === 'D') {\n e.preventDefault();\n enabled = !enabled;\n if (enabled) {\n applyDarkMode();\n console.log('[Universal Dark Mode] Enabled');\n } else {\n removeDarkMode();\n console.log('[Universal Dark Mode] Disabled');\n }\n }\n });\n \n // Apply on load\n applyDarkMode();\n \n // Re-apply on dynamic content\n var observer = new MutationObserver(function(mutations) {\n if (enabled && !document.getElementById('universal-dark-mode-style')) {\n applyDarkMode();\n }\n });\n observer.observe(document.head, { childList: true });\n \n console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');\n})();", "Universal Dark Mode"); } } catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); } })(); })();
                Skip to content

                finding: H8 的 merged-PR 窗口按「~18 merges/day」定成两页,实测已达 ~196/day —— 超过约 24 小时的交付对巡查结构性不可见(本轮实测 14 张滞留 4–6 天) #13499

                Description

                @os-project-manager

                scripts/pm/check-half-states.mjs 的 H8(「交付 PR 已合并、卡仍挂 pm:dispatched」)读一个按条数封顶的已合并 PR 窗口。那个条数当初是按一个明确写下的合并速率算的,而速率已经涨了约 11 倍,窗口因此缩到约一天。结果不是漏报个例,是一整段时间之前的交付全部落到视野之外

                未认领,只作记录。

                机制(读码)

                listRecentlyMergedPullRequestsscripts/pm/check-half-states.mjs:4082 附近):

                for(letpage=1;page<=2;page++){constbatch=awaitrest(`/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:19Z2026-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 三张卡按热文件串行挂起不派(见 #119255443363161)。该席位同时指出这类占用任何机械检查都看不见 —— single-writer 检查与围栏并集都只读开放 PR,唯一能看见的是读卡面。⇒ 一个已合并未回标的 pm:dispatched,在这套机制里会伪装成一个活的独占写者。

                (这 24 张已按各卡上已有的席位判定回标,2026-08-30,维护者指令。)

                修法的形状(是建议,不是处方)

                把封顶从条数改成时间:一直翻页直到 merged_at 早于 N 天(N 取「未执行判定的最长实测延迟」而不是一个页数),并保留一个页数上限作为配额兜底。这样速率再涨一次,覆盖的时间跨度不变。

                ⚠️ 两个必须一起做的:

                1. 把那句 ~18 merges/day 换成从数据推导的量,或者至少让它在过期时会响 —— 一个写死在注释里的速率前提,正是这次失效的根。
                2. 两个方向都进自测(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.mjsdomain:skills 的先例),但这一判归分诊。

                Metadata

                Metadata

                Assignees

                Type

                No type

                Projects

                No projects

                  Milestone

                  No milestone

                  Relationships

                  None yet

                  Development

                  No branches or pull requests

                  Issue actions