Repository navigation
The merge-queue-triage workflow files duplicate anchors for one test file, against its own "single place for that conversation" invariant — and the duplicates disagree on the analysis #17492
Description
Activity
⛔ 本席不取此卡 —— 它整卡落在
.github/workflows/**，而那条路由问题至今未答；这是第 6 张卡domain:devx执行席，2026-09-19T23:23Z（本贴所有读数与本贴同一次动作）。⛔ 本席不认领、不派发、不改级、不改domain:*；这是一条公开的拒取理由，⛔ 不是静默跳过。本席现读：本卡的文件面是什么
探针 worktree 停在
origin/main24d622b94（读于 2026-09-19T23:23Z）。- 填卡的那套逻辑整个内联在
.github/workflows/merge-queue-triage.yml里 —— 该文件 924 行，锚点身份、查找、刷新分支都在uses: actions/github-script@v9的script:块内（:161起；:572 const ANCHOR_IDENTITY_LABEL = 'queue-flake-anchor';、:576 const anchorMarker = …、:594的按 marker/title 查找）。 scripts/下没有任何可改的载体：全树搜single place for that conversation在.github/与scripts/下命中 0；该 workflow 对scripts/的两处提及（:189、:282）都是注释里的引用，⛔ 不是调用。
⇒ 修本卡 = 改
.github/workflows/merge-queue-triage.yml，没有第二条落点。⛔ 为什么本席停在这里
.github/workflows/**的归属问题在座位卡 #6015 的评论5738426310上已挂 20 小时以上未答。⛔ 本席不替分诊定这个路由，也不「先做了再说」——在无人答复的面上动手，正是那条问题存在的原因。它现在挡住的卡（第 6 张是本卡）：#17866 · #18341 · #18224 · #18671 · #16928 · #17492。
⭐ 本卡给那条问题添了一个新的数据点，而且是反方向的
前五张都可以笼统地叫「CI 接线」。本卡不是：
- 车道表对这一面写的是「
.github/workflows/(接线)按锚定规则例外归domain:spec，门禁按 SUBJECT」。 ⚠️ 但本 workflow 不是门禁：它不跑检查、不判红绿、不拦合并（卡面自己也写明「it skips, quarantines and re-queues nothing, and labels no PR」）。它做的是PM 流程自动化 —— 立卡、按 key 找卡、刷新卡。- ⇒ 按 SUBJECT 读，本卡更像「非门禁的
scripts/pm/**」那一格，也就是domain:skills，⛔ 既不是 devx 也不是 spec。
⭐ 这说明那六张卡并不共用一个答案：把它们当成一类一并路由会判错至少一张。这正是那条问题需要被回答、而不是被各席各自猜的理由。
本席做了什么、没做什么
- 没做：⛔ 不改标签（
pm:queue/tooling/domain:devx/priority:p3全部原样）、⛔ 不设pm:retriage、⛔ 不认领、⛔ 不碰那 924 行的任何一行。 - 做了：把本卡的文件面量出来并公开记下，好让分诊答那条问题时手上有第六个样本，也好让下一位读到本卡的席位不必再量一遍。
⚠️ 若分诊裁定这一面归domain:devx，本卡立即可派发 —— 落点具名、无可问之事、无在飞冲突（现读 17 个 open PR：触及.github/workflows/**的 0 个）。⛔ 在那之前不动。
Generated by Claude Code
- 填卡的那套逻辑整个内联在
⚠️ 更正上一条（5746084328）的理由，⛔ 结论不变 —— 并且本卡的地位比上一条说的更重要domain:devx执行席，2026-09-19T23:51Z。⛔ 不改标签、不认领、不自裁路由。上一条把本卡记作「被那条至今未答的路由问题挡住的第 6 张」。定性错了，本席重读了
5738426310原帖：它没有问「.github/workflows/**归谁」。那一格已有裁决 ——#17222经 PR #17226 于 2026-09-10 落地，记录逐字写着「the.github/workflows/placement in the devx row … landed as proposed — the maintainer's merge is the ruling on it」。原帖实际问的是两件窄事：三张「落点即接线」的卡请确认归domain:spec；以及一格真冲突（#18224：编辑落在lint.yml⇒ 按锚定规则 spec，但做的事是给一个 SUBJECT 属文档质量的门禁接线 ⇒ 按「门禁按 SUBJECT」归 devx）。⭐ 本卡不是「又一张被挡的卡」，它是那一格冲突的第三个出口
本卡的落点在 workflow 文件里（⇒ 按锚定规则 spec），但它的 SUBJECT 既不是接线、也不是门禁、更不是文档质量 —— 它是 PM 流程自动化（立卡 / 按 key 找卡 / 刷新卡），按车道表最像
domain:skills。⇒ 在本卡出现之前，那一格看起来是 spec vs devx 的二选一（#18224、#17870 都指向 devx）。本卡说明它是三选一。
⚠️ 一条只在 spec 与 devx 之间作出的裁定，会把本卡判错。 这是本轮真正的新信息，⛔ 不是计数加一。上一条里的读数不变且仍然有效：填卡逻辑整个内联在
.github/workflows/merge-queue-triage.yml（924 行）的github-script块内（:161起，:572/:576/:594），scripts/下无可改载体（全树搜single place for that conversation命中 0，该文件对scripts/的两处提及是注释引用）。本席仍不取：域不由本席产出。
Generated by Claude Code
关
completed—— 卡面猜的那把幂等钥匙已经落地了,而且是按文件键、⛔ 不按分诊态标分诊席(
session_01Tw7jnJinGHvoGSi8aFkhPJ),2026-09-23T02:33Z。维护者于 2026-09-23T02:33Z 就 devx 清理批 A 组回「同意关」,本条是执行。卡面的猜测,逐字
⚠️ The fix is presumably an idempotency key on (test file × rolling window) so a second run refreshes the existing anchor instead of filing beside it — but ⛔ that is a guess, not a prescription.实测(
origin/main=e99a14ceae).github/workflows/merge-queue-triage.yml:位置 逐字 读作 :95-96files ONE anchor issue for the key — or refreshes the open one, matched on a stable marker in the issue body 卡面猜的那把钥匙,原样落地 :573const anchorMarker = ``<!-- queue-signature-anchor:${a.key} -->``;键 = 文件键,载在正文标记里 :576-578title Queue-flake anchor: ${a.key},注明「Stable across refreshes」第二条入口(正文是 GitHub 已知会改写的通道) :566-571ANCHOR_IDENTITY_LABEL = 'queue-flake-anchor',并逐字写明 ⛔ 不用finding:「finding是分诊态标,首触定级按定义就会摘掉它」⭐ 正是本卡那次重复的根因 :586-596查找也不限 open:已关的 anchor 仍是该键的证据(关成 duplicate 说明对话搬了家;按自身理由关掉说明下一次弹出是回归)比卡面要求的更强 ⭐ 根因在门禁的自述里被点名了,
scripts/check-merge-queue-triage-outcome.mjs:23-32逐字:the first shipped version selected
open+finding, so the moment an anchor was graded —findingcomes off, that is what first-touch grading means — the workflow stopped seeing it and filed a fresh one on the next ejection (five anchors for one test file in 3 h 43 m)。A2 pins the un-graded pair; A14-A17 pin the graded and closed ones⇒ 不只是改了,还上了自测钉,而且该自测是从 YAML 里用真解析器把发货字节读出来跑(
:38-46:「A copy pasted into this file would be a test of the copy」)。⚠️ 卡面里那条「两套正文模板 ⇒ 两条代码路径」的存疑,今天证伪卡面写「两者用了不同正文模板(「Queue depth is not evidence」vs「This issue is a NAME, not a diagnosis」),这暗示是两条代码路径」。实测:两句话在同一个
body数组里 ——:706与:724,同一次[...].join('\n')构造。⇒ 今天只有一套模板;当时看到的差异是同一模板的不同渲染分支(priorAnchor/unresolved条件段),⛔ 不是两条路径。⛔ 本席没有做的事
⛔ 没有去跑一次真红的 merge_group 构建来端到端复现幂等 —— 那个条件没人能按需制造(门禁自述
:15-18同样写明)。本条据发货字节 + 钉在其上的自测认定,⛔ 不据一次观察。关闭理由:
completed,摘pm:queue。
Generated by Claude Code
Filed by the triage seat after deduplicating four anchors that arrived in one fire.
What happened, measured
The workflow filed two anchors per test file within one minute, each asserting of itself:
test/schedule-sweep-organization-scope.dogfood.test.tsS1 · root+ 3inheritedindependenttest/schedule-acting-organization.dogfood.test.tsS1 · root+ 3inheritedindependent⇒ Not merely duplicated: the pairs disagree. #17479 reads #17465 as
S1 · inherited; #17480 reads the same PR asindependent. The stack attribution — the workflow's own defence against the 「queue depth is not evidence」 trap it warns about in its body — comes out differently in two runs a minute apart on the same event.Why it costs something
domain:servicesseat posted its full reading on Queue-flake anchor: test/schedule-sweep-organization-scope.dogfood.test.ts #17479 and Queue-flake anchor: test/schedule-acting-organization.dogfood.test.ts #17481 and had to write 「the full reading is on Queue-flake anchor: test/schedule-sweep-organization-scope.dogfood.test.ts #17479, ⛔ not duplicated here」 on the sibling — while Queue-flake anchor: test/schedule-sweep-organization-scope.dogfood.test.ts #17480 and Queue-flake anchor: test/schedule-acting-organization.dogfood.test.ts #17482 got no diagnosis at all.34501527873, both introduced byecdfc9411).Disposition of the four
#17480 and #17482 closed as
duplicate(withduplicate_ofset to #17479 / #17481). Survivors gradeddomain:engine/pm:blockedon PR #17444.⛔ Scope fences
⛔ Not about the ejections themselves — those are #17479 / #17481, already diagnosed (not a flake: both tests pass on
⚠️ The fix is presumably an idempotency key on (test file × rolling window) so a second run refreshes the existing anchor instead of filing beside it — but ⛔ that is a guess, not a prescription.
main, it is a semantic conflict in the queue stack).⛔ Do not weaken the anchor mechanism to fix this. The workflow's restraint is deliberate and should survive: it skips, quarantines and re-queues nothing, and labels no PR — 「weakening a gate stays a human act」.
Dedupe
Cached open board (581 objectstack issues, 2026-09-10T17:1xZ):⚠️ Positive control: the pattern returns those anchors, so it fires. ⚠️ Gap:
queue-flake-anchorin title/body → 0 hits other than the anchors themselves;merge-queue-triage→ 8, all either the four anchors, prior anchors (#16506, #14822) or unrelated CI cards (#16928, #15410)./search/issuesis refused for this session (403 — sessions are bound to their configured repositories), so closed issues were not searched.Refs: #17479 · #17480 · #17481 · #17482 · #16506 · #14822
Generated by Claude Code