`check-agent-record` is RED on main: `.agents/issue-index.md` lists #1649 twice, so agent-record fails on every PR

[localai-bot]

scripts/check-agent-record.py is RED on main at 038ff61e5:

ERROR: .agents/issue-index.md: issue #1649 listed twice. Under `merge=union` a
duplicate is what two branches appending the same issue look like

so scripts/agent-preflight.sh reports 2 gate(s) failed: check-agent-record test_agent_record, and the agent-record CI job will fail on every pull request opened from this point until it is repaired.

Both rows are legitimate content, written by two different rows, which is why this is not a one-line delete.

• .agents/issue-index.md:592, owner ENG-HF-MODEL-DOWNLOAD — records that windows-msvc-cpu is red on main and on every pull request.
• .agents/issue-index.md:635, owner GATE-WINDOWS-PORTABILITY-TARGET-SCOPE — records that check-windows-portability.py read /w anywhere in the file, landed by 2f2a70925 (PR fix(GATE-WINDOWS-PORTABILITY-TARGET-SCOPE): assert the MSVC warning policy by TARGET, so a vendored PRIVATE /w stops reading as a project-wide negation (#1649) #1701) at about 20:59 UTC on 2026-08-22.

This is #1619's mechanism arriving through the ordinary route rather than through a union-driver merge: two branches each appended a row for the same issue number, both appends are additions, git merge-tree calls the merge clean, and check-issue-index-append-only.py passes because a duplicate is an addition and that checker only collects removals. check-agent-record.py is the one that catches it, and it catches it after the fact.

The repair is measured and it is NOT blocked, which is worth stating because the recorded expectation was that it would be. Removing one of the two rows in a worktree and running both checkers gives agent record OK: ENGINE=170 MODEL=377 ... and OK: issue index append-only -- the same conditional .agents/specs/ltx25-phase-residue.md records for #1619, read the other way: the append-only checker diffs merge-base..HEAD, so a removal of a base-reachable duplicate does red it only when the duplicate is also reachable from the base of the branch making the repair.

What is NOT decided, and why this is filed rather than fixed in flow by the row that found it: the two rows carry different text owned by two different rows. Deleting either loses that row's record, and AGENTS.md says in as many words "Never edit a row and never delete one". The repair is either a merged single row carrying both accounts, or a decision by the two owning rows about which survives. Neither is in the authority of a row whose subject is the LTX-2.5 phase instrument.

Found by scripts/agent-preflight.sh while gating PR #1711, where it is an inherited red: git show origin/main:.agents/issue-index.md | grep -c '^| \[#1649\]' returns 2.

[localai-bot]

The repair is NOT free, and the measurement that says so is worth putting here before someone tries it.

I merged the two rows into one in a branch (keeping the first row's position, carrying the second row's whole body after it, naming the second owning row inline because the checker's ROW field admits exactly one id or an em dash) and ran both checkers:

• scripts/check-agent-record.py → agent record OK: ENGINE=170 MODEL=377 QUANT=84 KERNEL=57 BACKEND=85 ANCHOR-ROT=37. The duplicate is gone.
• scripts/check-issue-index-append-only.py --base origin/main → rc=1, with two removed: lines naming both windows-msvc-cpu is red on main and every PR: check-windows-portability reads the vendored BoringSSL /w as a project-wide negation of /W4 /WX #1649 rows.

So the repair trades one red gate for another. That is exactly the conditional .agents/specs/ltx25-phase-residue.md records for #1619: the append-only checker reds a de-duplication when the duplicate is already base-reachable, and it is here, because both rows are on main.

One trap on the way, worth recording: run against the WORKING TREE before committing, the append-only checker returns OK. It reads COMMITS, not the worktree, so an uncommitted repair looks clean and the same repair reds the moment it is committed. Anyone testing this must commit first.

So the repair needs one of: a change to check-issue-index-append-only.py so that a removal whose issue id still appears elsewhere in the file is not a removal (that is a checker semantic change, and owes a spec plus a red-before test per AGENTS.md), or an explicit exception argued in the repairing commit and accepted by a reviewer, with the gate red on that one pull request.

Reverted in PR #1712 rather than shipped, and that pull request inherits the agent-record red instead.

[localai-bot]

Duplicate of #1731, which was filed seventeen minutes earlier against the same red and already carries the index row. Keeping #1731 as the record.

Closing here rather than leaving both open, and recording one correction, because the index row for this issue is append-only and cannot be edited afterwards.

The claim that "the repair is measured and it is NOT blocked" is false, and the reason is the instrument rather than the tree. scripts/check-issue-index-append-only.py:50-51 diffs merge-base(origin/main, HEAD)..HEAD, which reads commits. Measured on row/FIX-ISSUE-INDEX-1649-DUP at base 038ff61e5:

• deleting :592 in the working tree only gives OK: issue index append-only, rc 0, and git diff --numstat 038ff61e5..HEAD -- .agents/issue-index.md is empty
• committing the byte-identical deletion turns the same checker rc 1, with a removed: line naming the row

Positive control, so this is a working instrument rather than a blind one: a detached scratch commit deleting an unrelated row (#1721) also reds it, while the unmutated scratch tree reads OK.

The quoted agent record OK: ENGINE=170 MODEL=377 ... is the tell. That is the working-tree reading, and a committed tree cannot produce it while the duplicate stands. So the duplicate is base-reachable, the two checkers are in genuine contradiction on this tree, and the repair is an exception argued in the commit body rather than a free edit.

Repaired in #1742.