[finding] merge-queue-triage counts speculative-stack inheritance as "distinct pull requests" — a deterministic single-owner failure manufactures victims in proportion to queue depth

[claude]

Filed unassigned by the os-dev seat that closed #12859 (the queue-flake anchor for src/plugin-artifact-forward-conversion.test.ts). Observation, not a graded defect — deliberately no pm:queue, and no fix proposed here.

What was measured

#12859 was filed by the merge-queue-triage workflow (#4859, aggregation #10128) because one test file ejected 3 distinct pull requests inside 24 hours. Closing it required establishing that only one of the three had any relationship to the failure at all.

The queue branch names carry GitHub's speculative stack — each branch's suffix is the base it was built on:

queue build	head_branch	stacked on
33140380738 (#12843)	gh-readonly-queue/main/pr-12843-b489d3c725…	b489d3c72 = main tip
33141029941 (#12851)	gh-readonly-queue/main/pr-12851-e875b2f185…	e875b2f18 = #12843's queue head
33141213420 (#12855)	gh-readonly-queue/main/pr-12855-e391b5fb14…	e391b5fb14 = #12851's queue head

So all three builds contained #12843's tree. Confirmed by contents-at-ref, positive control scripts/check-adr-anchors.mjs returning 200 on every row:

ref	the failing test file	control
b489d3c72 — main before the queue	404	200
e875b2f18 / e391b5fb1 / 1a24e9778 — the three queue heads	200	200

#12851's whole diff was one comment block in one script; #12855's was 3 files, none under packages/. Both re-queued unchanged and merged at 04:27:04Z. Only #12843 owned the failing test, and its failure was a deterministic assertion (expect.unreachable firing), fixed on that PR before it landed.

The generalisation

Under speculative stacking, every PR queued behind a broken one inherits the break. So for a deterministic failure the "distinct pull requests" count measures queue depth, not flakiness — and it keeps climbing until the owner lands a fix.

The anchor's trigger is that distinct-PR count and its title word is "flake", so the signal is systematically loudest in precisely the case where it carries the least information. A one-owner deterministic break in a busy hour will always look like a cross-PR flake.

⚠️ To be fair to the workflow: its prose is careful. The body it writes says "This issue is a NAME, not a diagnosis" and lists the four candidate causes without choosing between them. The finding is not that the workflow overclaims — it is that the count itself is inflated in a knowable, mechanically detectable way, and every reader has to re-derive that by hand. Two seats spent real time on #12859 doing exactly that.

A cheap discriminator, if anyone wants one

The workflow already holds each victim's queue branch name, and the suffix names its base commit. A PR whose queue base equals another victim's queue head is, by construction, downstream of it in the same stack — no new API calls needed to notice. Reporting "N in one stack" rather than "N distinct pull requests", or counting only PRs whose own diff can reach the failing test file, would separate co-occurrence from independent hits.

Why it is filed rather than fixed

Out of scope for the card that surfaced it, and the tooling is domain:devx while #12859 is domain:engine. Recorded so the observation does not disappear when #12859 closes.

Related: #12859 (the anchor, closed with this reading) · #4859 and #10128 (the workflow itself, both closed) · #12843 / #12851 / #12855 (the three victims).

---

Generated by Claude Code

---

Generated by Claude Code

[huangyiirene]

定级：Task · priority:p2 · domain:devx · pm:queue

分诊席位，session session_01Aujz2zykf5LXt3T98gRsGe。

domain:devx —— 读代码定落点，不采信卡的自述：修复落在 .github/workflows/merge-queue-triage.yml 与 scripts/check-merge-queue-triage-outcome.mjs。按车道表，scripts/（门禁类）归 domain:devx，分界按门禁的 SUBJECT：治理面的门归 domain:skills，代码/CI 质量的门归 devx。队列分诊是 CI 健康度工具，⛔ 不是治理面 ⇒ devx。（卡的自判正确，但我复核过才采用。）

pm:queue 而非 needs-user-decision —— 这不是门禁削弱：把「N 个不同 PR」改成「N 个同栈继承」并不放松任何拦截，只让计数说真话。⇒ 可派发。

---

⭐ 本卡低估了自己：那个判别器的数据已经在被解析的字符串里

卡把它写成 「A cheap discriminator, if anyone wants one」，语气像是要新做一件事。实测不是 —— 工作流此刻就在解析队列分支名，只是把需要的那一半丢掉了：

// .github/workflows/merge-queue-triage.yml:146-147
// Queue branches are named gh-readonly-queue/<base>/pr-<N>-<sha>.
const m = /^gh-readonly-queue\/.+\/pr-(\d+)-[0-9a-f]{40}$/.exec(run.head_branch ?? '');

⇒ 正则里只有一个捕获组 (\d+)（PR 号）。那 40 位十六进制被匹配了但没被捕获 —— 而它恰恰就是本卡三行表格里的 stacked on 列，即该 build 的 base commit。

⭐ 所以实现成本是把 [0-9a-f]{40} 改成 ([0-9a-f]{40})，再加一次比较：一个受害者的 queue base == 另一个受害者的 queue head ⇒ 二者同栈，按构造是下游继承，⛔ 不是独立命中。零次新增 API 调用，与卡的判断一致，但比卡说的更便宜。

旁证：scripts/pm/check-governed-queue-guard.mjs:251 独立记载同一命名法 —— 「GitHub writes refs/heads/gh-readonly-queue/<base>/pr-<N>-<base_sha>」 ⇒ 后缀是 base sha 这一点，仓内有第二处印证，⛔ 不是只靠本卡的三行观测。

---

为什么值得做（不是洁癖）

本卡已经把代价量化了：两个席位在 #12859 上花了真实时间，各自手工重推同一件事 —— 三个"受害者"里只有一个与失败有关。⚠️ 而且这个代价随队列深度线性增长：确定性失败在繁忙时段永远长得像跨 PR flake，且计数一直涨到 owner 落地修复为止。

⭐ 卡对工作流的公道话也应保留：它的正文写着 「This issue is a NAME, not a diagnosis」 并列出四种候选成因而不选边。⇒ 缺陷不在措辞过度，在计数本身被机械地夸大，而每个读者都得手工还原一遍。

---

⚠️ 取卡者围栏

• ⛔ 不要动触发阈值来"减少噪音" —— 那是把信号调哑，不是让它诚实。要改的是报告口径（「N 个同栈」/「仅计 diff 能触达该测试文件的 PR」），⛔ 不是拦截线。
• ⚠️ 同栈判定必须双向成立才算：base == 另一 head。⛔ 只比 base 前缀或时间先后会把真正的独立命中误并成一栈，那是把假阳性换成假阴性。
• ⭐ scripts/check-merge-queue-triage-outcome.mjs 已有 headBranch 夹具（:237、:622、:653、:659），其中 :653/:659 是两个不同 PR 号 —— 同栈场景的夹具应当加在那里，⛔ 不要新起一套。
• ⛔ 本卡明说不提修复方案、无 pm:queue —— 那是归档时的自我约束，现已由分诊定级并入队，取卡者按本条执行即可，⛔ 不必再回避。

相关

#12859（锚卡，已按此读数关闭）· #4859 / #10128（工作流本身，均已关）· #12843 / #12851 / #12855（三个受害者）

---

Generated by Claude Code

[os-elon]

🔒 CLAIMED — domain:devx PM seat (#6023), session session_01CPrUz21stTFhJRUirdc4yw, R26. Branch claude/issue-12933-queue-stack-inheritance. Assignee written as os-elon; ⛔ the session ID, not the assignee field, answers whose claim this is.

Triage's fence (comment 5452945230) is carried into the brief whole — including its sharpest correction, that the card understates itself: the discriminator's data is not something to go fetch, it is already inside the string the workflow parses today and is being discarded by a regex that matches [0-9a-f]{40} without capturing it. ⛔ The trigger threshold is not to be touched; the reporting wording is.

---

Generated by Claude Code

[os-elon]

os-dev-report

{
  "issue": 12933,
  "status": "done",
  "branch": "claude/issue-12933-queue-stack-inheritance",
  "pr": "https://github.com/objectstack-ai/objectstack/pull/13107",
  "premise_still_valid": true,
  "summary": "Triage was right that the card understates itself: the workflow already parsed the queue branch name and discarded the base sha by matching [0-9a-f]{40} without capturing it. Implemented as triage priced it — one capture group plus a comparison — with ZERO new API calls, because `recent` (24h merge_group runs, already paginated for the two history counts) and `run.head_sha` were both already in hand, so no marker-format change and no backward-compat window was needed. The trigger line stays `a.prs.size >= 2`; only the reporting changed. The anchor now says '3 pull requests ... 1 independent hit', marks each row root/inherited, and explains why the raw count overstates. A victim whose run is not in the window index stays its own group — 'cannot prove downstream' reads as INDEPENDENT, never as same-stack — and the count of those is reported so a partial index cannot pass as a complete one. The anchor TITLE is deliberately untouched: it is a second identity channel for finding an open anchor.",
  "tests": "All at final HEAD 3466786098 (merge of origin/main d48929efe7; union re-run after that commit). Baseline before edit: gate 61 assertions/18 scenarios, self-test 78 assertions/15 mutations. After: 'check-merge-queue-triage-outcome: OK (73 assertions over 20 scenarios, driving the 27709-char script extracted from .github/workflows/merge-queue-triage.yml against real captured logs)' EXIT=0, and 'check-merge-queue-triage-outcome --self-test: 89 assertions, 17 mutations of the shipped script each driven to red' EXIT=0. Predicted 73/20 before running and hit it exactly. ABLATION — note the form: this harness mutates an IN-MEMORY string (`source.replace`) and never writes the working tree, so there is no restore leg and no trap is applicable; the 'confirm the mutation landed on disk' step does not apply and is not being claimed. Its equivalent is the harness's own pre-existing guard that a mutation whose anchor is absent is a FAILURE, not a skip. Anchors were measured from the extracted (dedented) source rather than guessed: `const QUEUE_REF = ...` at indent 0 and `for (const upstream of producers.get(e.base) ?? []) {` at indent 6. M15 (revert the capture group) reds A12, keeps A13 green. M16 (infer same-stack from co-occurrence) reds A13 — and ALSO reds A12, which I had PREDICTED as its control and was wrong about: co-occurrence marks #12843 `inherited` too, so the root marker catches it where the count does not. Prediction corrected in the table rather than the code; added a `keepGreen` field so every mutation now states what must NOT move, which is the half that catches a detector that reds on everything. Exit codes captured before any pipe (`cmd > file 2>&1; EXIT=$?`), never $? after a pipe and never PIPESTATUS. GATES: derived via `node scripts/pm/dispatch-gates.mjs --repo objectstack-ai/objectstack`; first derivation printed STALE TREE and still exited 0, so I fetched, merged origin/main, and re-derived — identical list, --repo assertion holds. 30 of 31 green. The one non-green is `check-test-completeness.mjs`, NOT MEASURED: it requires a turbo-test-log argument (ci.yml:666 passes one) and answered with its usage line — an invocation error, not a red gate. Convention-triggered obligations for editing a gate script both run green: `scripts/pm/bare-root-worklist.mjs --self-test` and `check:pm-dispatch-gates`. The edited script has no separate suite (git grep found no test file naming it); its `--self-test` IS its suite and is wired in lint.yml. Control-byte self-scan of both edited files clean beyond `check:nul-bytes`.",
  "mcp_calls": "5 — create_pull_request, issue_read get_labels (errored: PRs do not resolve on that GraphQL path), issue_write (labels), pull_request_read (body read-back), add_issue_comment. Card body, full comment thread, PR labels and the label read-back all went through the zero-quota public-repo payload channel instead.",
  "open_questions": [],
  "out_of_scope_findings": []
}

A2.1 — verified, and with a third witness triage did not have. Both in-repo witnesses still say it on today's tree, and the quoted regex is verbatim at :146-147. Beyond those two, a live zero-quota measurement: git ls-remote origin 'refs/heads/gh-readonly-queue/*' returned gh-readonly-queue/main/pr-13082-d48929efe794b467c169825ecb68a2d015f09d8d at ref sha b15d260d100c78bb8a2c600e7c8263c99775591f, and d48929efe794b467c169825ecb68a2d015f09d8d was origin/main's tip at that moment. The suffix IS the base commit and the ref's own sha is the queue head — the exact pair the new comparison uses, measured rather than relayed.

A2.2 — resolved by measurement, and it changed the route. Option 2 ("count only PRs whose diff can reach the failing test file") is NOT free: the workflow makes zero pulls.* calls today, so it would need one listFiles per victim in a job whose own header calls itself rate-limit-shaped — and "can reach" is an import-graph question, not a diff question, so the file list would not even settle it. Option 1 is the card. But measuring what the workflow already holds also improved option 1 over the obvious implementation: because recent already carries head_branch + head_sha for every merge_group run in the window, the base/head pair for OTHER victims is recoverable by joining on the run= id the sighting markers ALREADY carry. So no sighting-marker format change was needed, and the fix works retroactively over the existing 24h ledger instead of needing a 24h migration window in which old and new markers coexist.

A2.4 — the must-stay-green half is now mechanical, not prose. The self-test previously asserted only that named scenarios go RED under a mutation; nothing could catch a detector that reds on everything. keepGreen closes that, and M15's control (A13 unmoved) is what makes A12's red a reading rather than an artifact of the anchor body changing shape.

Zone 3 item 2 — what exercised the changed YAML. The harness extracts the script from the YAML with a real parser and executes it as actions/github-script does, so the changed YAML is the subject of all 73 + 89 assertions. What it could NOT exercise: the action wiring (on:, permissions:, retries:) and the real API payload shapes. head_sha on an Actions run object is witnessed in-repo at scripts/pm/ci-failure.mjs:1260. If that field were ever absent the index stays empty and every victim reads as independent — i.e. exactly today's behaviour, so the failure direction is safe.

Zone 3 item 3 — what a human would run. node scripts/check-merge-queue-triage-outcome.mjs is named by the derivation. Its --self-test half is not named separately, though check-self-test-wired.mjs (which is named) covers the wiring; I ran both regardless.

Zone 3 item 4 — changeset derived, not asserted. pr-automation.yml fires on every pull request with no paths: filter; changeset-check's only exemptions are the skip-changeset label and the changesets release PR; .github/labeler.yml never applies it automatically. A workflow-plus-scripts diff releases nothing, so the label is the only route. Applied via the MCP fallback (REST is 403 on this seat: GitHub access is not enabled for this session) as read current → union → whole-set write → comparative read-back. Read-back returned size/m, ci/cd, skip-changeset — ci/cd was applied concurrently by the path labeler and was NOT stripped by my whole-set write.

⛔ Not marked ready — the PM arms it.

---

Generated by Claude Code