scripts/check-agent-record.py keys .agents/issue-index.md uniqueness on the issue number alone. Filing an issue and fixing it normally happen on different branches, merge=union combines two appends silently, and the file is append-only — so the second row is the only way a hand-off can reach the index at all. The checker calls that a duplicate and reds main, where every later pull request inherits it.
This is not hypothetical, and it is not a one-off
#1731 was the first instance: #1649 at :592 under ENG-HF-MODEL-DOWNLOAD (the lane that FILED it) and :632 under GATE-WINDOWS-PORTABILITY-TARGET-SCOPE (the lane that FIXED it). It was resolved by #1742, which deleted one row as an argued append-only exception.
It recurred immediately. On row/GATE-ISSUE-INDEX-OWNER-KEY, #1731 itself now sits on two rows — :644 under the lane that filed it and :646 under the lane that fixed it — and it is the only issue number appearing on more than one row there. So the deletion cured the instance and the class produced a new one inside a few hours, on the very branch addressing it.
Three lanes converged on the first instance (#1731, #1733 closed as its duplicate, and two branches), which is itself a cost of a red that blocks every branch.
Why deletion is the wrong steady state
Each deletion needs its own argued exception against the append-only rule, and the rule is load-bearing: AGENTS.md ## Records says "A gate often creates the lock. If a checker requires every change to edit one shared file, the checker is defective. Move the obligation to a per-row surface. Do not delete the obligation."
A per-instance exception also has to be re-argued by whoever hits it next, without the context of why the last one was granted.
The narrowing, and what it must not lose
Key on the pair (issue number, owning row ID). A repeat of one issue under the SAME owner is what one row appended twice looks like, and must still red — that is the corruption #1619 measured, where the merge=union driver duplicated a row BYTE-IDENTICALLY at two lines, git merge-tree called it clean, and check-issue-index-append-only.py passed because a duplicate is an addition. A duplicated line carries its owner with it, so the pair still collides.
Notes for whoever picks this up
scripts/check-issue-index-append-only.py:50-51 diffs merge-base(origin/main, HEAD)..HEAD, so it reads commits: an UNCOMMITTED deletion is invisible to it and returns rc 0 with an empty git diff --numstat, while committing the byte-identical deletion turns it rc 1. #1733's claim that the repair was "NOT blocked" came from measuring the working tree.
Refs #1731, #1733, #1619, #1649.
scripts/check-agent-record.pykeys.agents/issue-index.mduniqueness on the issue number alone. Filing an issue and fixing it normally happen on different branches,merge=unioncombines two appends silently, and the file is append-only — so the second row is the only way a hand-off can reach the index at all. The checker calls that a duplicate and redsmain, where every later pull request inherits it.This is not hypothetical, and it is not a one-off
#1731 was the first instance:
#1649at:592underENG-HF-MODEL-DOWNLOAD(the lane that FILED it) and:632underGATE-WINDOWS-PORTABILITY-TARGET-SCOPE(the lane that FIXED it). It was resolved by #1742, which deleted one row as an argued append-only exception.It recurred immediately. On
row/GATE-ISSUE-INDEX-OWNER-KEY,#1731itself now sits on two rows —:644under the lane that filed it and:646under the lane that fixed it — and it is the only issue number appearing on more than one row there. So the deletion cured the instance and the class produced a new one inside a few hours, on the very branch addressing it.Three lanes converged on the first instance (#1731, #1733 closed as its duplicate, and two branches), which is itself a cost of a red that blocks every branch.
Why deletion is the wrong steady state
Each deletion needs its own argued exception against the append-only rule, and the rule is load-bearing:
AGENTS.md## Recordssays "A gate often creates the lock. If a checker requires every change to edit one shared file, the checker is defective. Move the obligation to a per-row surface. Do not delete the obligation."A per-instance exception also has to be re-argued by whoever hits it next, without the context of why the last one was granted.
The narrowing, and what it must not lose
Key on the pair (issue number, owning row ID). A repeat of one issue under the SAME owner is what one row appended twice looks like, and must still red — that is the corruption #1619 measured, where the
merge=uniondriver duplicated a row BYTE-IDENTICALLY at two lines,git merge-treecalled it clean, andcheck-issue-index-append-only.pypassed because a duplicate is an addition. A duplicated line carries its owner with it, so the pair still collides.Notes for whoever picks this up
scripts/check-issue-index-append-only.py:50-51diffsmerge-base(origin/main, HEAD)..HEAD, so it reads commits: an UNCOMMITTED deletion is invisible to it and returns rc 0 with an emptygit diff --numstat, while committing the byte-identical deletion turns it rc 1. #1733's claim that the repair was "NOT blocked" came from measuring the working tree.Refs #1731, #1733, #1619, #1649.