Surfaced by the #948 repair, which found it, declined to silently widen scope, and handed the ownership question up. Confirmed independently before filing.
The drift
At Lightricks/LTX-2 pinned fd4ded7f2d88d3da713abcdd4ad41ecc4a9314ca, packages/ltx-core/src/ltx_core/conditioning/types/latent_cond.py:
36 stop_token = start_token + tokens.shape[1]
37
38 latent_state = latent_state.clone()
39
40 latent_state.clean_latent[:, start_token:stop_token] = tokens
41 latent_state.denoise_mask[:, start_token:stop_token] = 1.0 - self.strength
7 files in this repository cite latent_cond.py:38-39 for the claim that "only clean_latent and denoise_mask are written" (positive control: 9 files cite latent_cond.py at all). Those writes are at :40-41. :38-39 is clone() and a blank line.
Why this is worth an issue rather than a drive-by fix
The claim itself is true — the reading is right, only the line numbers are wrong. So nothing is broken today, and every gate is green. That is exactly what makes it worth tracking: a reader who follows the citation lands on clone(), which is real code that does something else entirely, and is misled rather than alerted. A wrong-but-plausible anchor is worse than a dangling one.
The sites span specs, golden-generator scripts and other rows' tests. They predate the row that found this, and each belongs to a different owner — which is precisely why it was not fixed in flow. AGENTS.md's in-flow rule covers a bug you find in work you are doing; it does not license one row rewriting seven other rows' records.
What it is an instance of
#911 — 4772 line-carrying citations across 315 .agents/specs/*.md that no checker examines. This is that class with seven concrete, confirmed instances and a known-correct replacement, so it is a good first target for whatever #911 produces.
Two things the fix should get right, both learned the hard way this week:
- Derive the needle from the claim, not from the cited span. A validator that reads the expected text out of the file it is checking is circular — one reported 27/27 FRESH while five anchors pointed at unrelated code.
- Cover bare
:NN continuations. A sweep that resets file context at line boundaries misses them, and they have slipped four separate audits. One was resolved against the nearest filename above, landing on a real-but-unrelated line in a different file — the same failure mode as this issue.
Suggested disposition
Either SHA-anchor the seven sites (latent_cond.py:40-41 @ fd4ded7f) or correct them live and add them to whatever sweep #911 lands. Not urgent; no behaviour depends on it.
Related: #911, #930, #948.
FOLLOWING_AGENTS_PROTOCOL
Surfaced by the #948 repair, which found it, declined to silently widen scope, and handed the ownership question up. Confirmed independently before filing.
The drift
At
Lightricks/LTX-2pinnedfd4ded7f2d88d3da713abcdd4ad41ecc4a9314ca,packages/ltx-core/src/ltx_core/conditioning/types/latent_cond.py:7 files in this repository cite
latent_cond.py:38-39for the claim that "onlyclean_latentanddenoise_maskare written" (positive control: 9 files citelatent_cond.pyat all). Those writes are at:40-41.:38-39isclone()and a blank line.Why this is worth an issue rather than a drive-by fix
The claim itself is true — the reading is right, only the line numbers are wrong. So nothing is broken today, and every gate is green. That is exactly what makes it worth tracking: a reader who follows the citation lands on
clone(), which is real code that does something else entirely, and is misled rather than alerted. A wrong-but-plausible anchor is worse than a dangling one.The sites span specs, golden-generator scripts and other rows' tests. They predate the row that found this, and each belongs to a different owner — which is precisely why it was not fixed in flow. AGENTS.md's in-flow rule covers a bug you find in work you are doing; it does not license one row rewriting seven other rows' records.
What it is an instance of
#911 — 4772 line-carrying citations across 315
.agents/specs/*.mdthat no checker examines. This is that class with seven concrete, confirmed instances and a known-correct replacement, so it is a good first target for whatever #911 produces.Two things the fix should get right, both learned the hard way this week:
:NNcontinuations. A sweep that resets file context at line boundaries misses them, and they have slipped four separate audits. One was resolved against the nearest filename above, landing on a real-but-unrelated line in a different file — the same failure mode as this issue.Suggested disposition
Either SHA-anchor the seven sites (
latent_cond.py:40-41 @ fd4ded7f) or correct them live and add them to whatever sweep #911 lands. Not urgent; no behaviour depends on it.Related: #911, #930, #948.
FOLLOWING_AGENTS_PROTOCOL