.agents/issue-index.md lists issue #995 twice on origin/main, so check-agent-record and test_agent_record are RED there and every branch that merges main inherits it.
Found while merging origin/main into SPEC-MTP-K-GT-1 (#81). Verified, not inferred:
$ git show origin/main:.agents/issue-index.md | grep -c 'issues/995'
2
The two rows were appended independently and describe the same issue:
Neither branch could see the other's line, and the file carries merge=union in .gitattributes, so both survived. scripts/check-agent-record.py says exactly this in its own message: "issue #995 listed twice. Under merge=union a duplicate is what two branches appending the same issue look like".
Why it is not just cosmetic
It is a PRE-FLIGHT gate. It fails before every edit, on every branch, and presents to each author as a red their own diff caused. That is the same shape as #965, #968 and #995 itself, which is a pattern worth naming: the append-only index is exactly as merge-safe as the rule that nobody appends the same issue twice, and two agents filing against the same red will do that reliably.
The repair, and which row to keep
Collapse to one row. Keep the EARLIER row (332aed738) and delete the later one, which is the merge-stable direction rather than the more-accurate-text direction:
- Deleting the earlier line makes it absent from
main while every branch cut from 332aed738 still carries it, so their next union merge RE-ADDS it and the duplicate returns.
- Deleting the later line leaves
main and those branches agreeing on one row, and nothing re-introduces it.
The later row's only extra content is a corrected set of qwen3_5.cpp line anchors at 4496ef196. #995 is closed, so that detail is not load-bearing.
Fixed in flow by SPEC-MTP-K-GT-1.
.agents/issue-index.mdlists issue #995 twice onorigin/main, socheck-agent-recordandtest_agent_recordare RED there and every branch that merges main inherits it.Found while merging
origin/mainintoSPEC-MTP-K-GT-1(#81). Verified, not inferred:The two rows were appended independently and describe the same issue:
332aed738(feat(LTX25-DFR-PIPELINE): the DFR canvas, the slots it invents, and the loop that still does not run (#986) #996) added the row anchored on3005447f8.45b022cdc(docs(ENG-EXPERT-STREAM): the three expert-streaming knobs are a deployment surface, not an allowlist entry (#995) #997) added a second row anchored on4496ef196.Neither branch could see the other's line, and the file carries
merge=unionin.gitattributes, so both survived.scripts/check-agent-record.pysays exactly this in its own message: "issue #995 listed twice. Undermerge=uniona duplicate is what two branches appending the same issue look like".Why it is not just cosmetic
It is a PRE-FLIGHT gate. It fails before every edit, on every branch, and presents to each author as a red their own diff caused. That is the same shape as #965, #968 and #995 itself, which is a pattern worth naming: the append-only index is exactly as merge-safe as the rule that nobody appends the same issue twice, and two agents filing against the same red will do that reliably.
The repair, and which row to keep
Collapse to one row. Keep the EARLIER row (
332aed738) and delete the later one, which is the merge-stable direction rather than the more-accurate-text direction:mainwhile every branch cut from332aed738still carries it, so their next union merge RE-ADDS it and the duplicate returns.mainand those branches agreeing on one row, and nothing re-introduces it.The later row's only extra content is a corrected set of
qwen3_5.cppline anchors at4496ef196. #995 is closed, so that detail is not load-bearing.Fixed in flow by
SPEC-MTP-K-GT-1.