Found by the agent merging #996, which flagged it and handed it up rather than filing silently or fixing outside its dispatch. I verified all three at origin/main before filing.
The three
.agents/specs/ltx25-retake.md:63 -> ltx2_video.cpp:1566 for an emptiness test
actual :1566 = context_tokens = encoded.seq;
the test is at :1420 / :1681
.agents/specs/ltx25-retake.md:251 -> ltx2_video.cpp:1995 for
`video.mask.assign(video.tokens, 1.0F)`
occurrences of that string on main: 0. It exists in NO tree checked
(the row head, origin/main, or the merge).
.agents/specs/ltx25-dfr-pipeline.md:307 -> ltx2_video.cpp:1379-1380 for the
stale-refusal tally
actual :1379 = a comment fragment; the tally is at :1626
None was caused by the merge. Measured at three trees — the row head, origin/main, and the merged tree — the retake pair was already wrong when retake landed, and the DFR one was stale pre-merge (it sits in §8 Risks, authored before implementation, which is exactly when a line number is least knowable).
A fourth citation, ltx25-dfr-pipeline.md:61 → docs/USAGE.md:791, is correct and should not be touched: §1 is explicitly headed measured at 0e1bee42f, so it is a dated historical claim, not a live one. That is the pattern the others should follow.
Why this is worth an issue rather than a quiet fix
The second one is the interesting case. A citation whose text exists in no tree cannot be repaired by re-deriving a line number — someone has to decide what the sentence meant. That is a job for whoever owns the row, not for a passing merge.
And the first two sit in a landed spec belonging to a different row. AGENTS.md's fix-in-flow rule covers a defect you find in work you are doing; it does not license one row rewriting another row's records. The merging agent said exactly that and declined — correctly, and it is the reason this issue exists at all.
Disposition
This is a fourth instance of #911 (line-carrying citations no checker examines) and a sibling of #959 (seven files citing latent_cond.py:38-39 for writes at :40-41). The remedy is the one this repo already uses and #911 will need to enforce:
- SHA-anchor a historical claim (
path:NN @ <sha>), as ltx25-dfr-pipeline.md:61 does correctly by dating its whole section;
- re-derive a live one with the needle taken from the claim, never by reading the span out of the cited file — that check is circular and once reported 27/27 FRESH while five anchors pointed at unrelated code;
- and cover bare
:NN continuations, the class that has now slipped seven separate audits.
No behaviour depends on any of this. The cost is that a reader who follows a citation lands on real code doing something else and is misled rather than alerted.
Related: #911, #959, #924, #986.
FOLLOWING_AGENTS_PROTOCOL
Found by the agent merging #996, which flagged it and handed it up rather than filing silently or fixing outside its dispatch. I verified all three at
origin/mainbefore filing.The three
None was caused by the merge. Measured at three trees — the row head,
origin/main, and the merged tree — the retake pair was already wrong when retake landed, and the DFR one was stale pre-merge (it sits in §8 Risks, authored before implementation, which is exactly when a line number is least knowable).A fourth citation,
ltx25-dfr-pipeline.md:61→docs/USAGE.md:791, is correct and should not be touched: §1 is explicitly headed measured at0e1bee42f, so it is a dated historical claim, not a live one. That is the pattern the others should follow.Why this is worth an issue rather than a quiet fix
The second one is the interesting case. A citation whose text exists in no tree cannot be repaired by re-deriving a line number — someone has to decide what the sentence meant. That is a job for whoever owns the row, not for a passing merge.
And the first two sit in a landed spec belonging to a different row. AGENTS.md's fix-in-flow rule covers a defect you find in work you are doing; it does not license one row rewriting another row's records. The merging agent said exactly that and declined — correctly, and it is the reason this issue exists at all.
Disposition
This is a fourth instance of #911 (line-carrying citations no checker examines) and a sibling of #959 (seven files citing
latent_cond.py:38-39for writes at:40-41). The remedy is the one this repo already uses and #911 will need to enforce:path:NN @ <sha>), asltx25-dfr-pipeline.md:61does correctly by dating its whole section;:NNcontinuations, the class that has now slipped seven separate audits.No behaviour depends on any of this. The cost is that a reader who follows a citation lands on real code doing something else and is misled rather than alerted.
Related: #911, #959, #924, #986.
FOLLOWING_AGENTS_PROTOCOL