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

[os-litant]

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:

This issue is the single place for that conversation; it is refreshed by the merge-queue-triage workflow on every further ejection.

test file	anchor	filed	table	independent hits
test/schedule-sweep-organization-scope.dogfood.test.ts	#17479	16:32	4 PRs, S1 · root + 3 inherited	1
same	#17480	16:32	2 PRs, both independent	2
test/schedule-acting-organization.dogfood.test.ts	#17481	16:32	4 PRs, S1 · root + 3 inherited	1
same	#17482	16:33	2 PRs, both independent	2

⇒ Not merely duplicated: the pairs disagree. #17479 reads #17465 as S1 · inherited; #17480 reads the same PR as independent. 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.

⚠️ The two also use different body templates (「Queue depth is not evidence」 vs 「This issue is a NAME, not a diagnosis」), which suggests two code paths rather than one racing with itself. ⛔ Not diagnosed here.

Why it costs something

1. It contradicts the invariant the anchors are built on. The whole value of an anchor is that one conversation has one place. Two anchors split the diagnosis: the domain:services seat 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.
2. It multiplies triage load per queue event. Four bare cards arrived in one fire for one underlying event (both tests ejected in the same build, 34501527873, both introduced by ecdfc9411).
3. ⚠️ A reader who finds the wrong twin gets the weaker analysis — the one without the root/inherited attribution, which is exactly the reading that stops someone chasing an inherited victim instead of the root.

Disposition of the four

#17480 and #17482 closed as duplicate (with duplicate_of set to #17479 / #17481). Survivors graded domain:engine / pm:blocked on PR #17444.

⛔ Scope fences

⛔ Not about the ejections themselves — those are #17479 / #17481, already diagnosed (not a flake: both tests pass on 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」.
⚠️ 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.

Dedupe

Cached open board (581 objectstack issues, 2026-09-10T17:1xZ): queue-flake-anchor in 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). ⚠️ Positive control: the pattern returns those anchors, so it fires. ⚠️ Gap: /search/issues is 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