record(LTX25-PHASE-RESIDUE): the row's measurements outlived its pull request, and ten open issues had no index row by localai-bot · Pull Request #1670 · mudler/vllm.cpp

localai-bot · 2026-08-22T07:30:55Z

PR #1556 is being closed rather than merged, and this lands the record it would otherwise have taken with it.

Why that pull request cannot merge

squash_merge_commit_message = PR_BODY, so its body becomes the permanent commit message. That body argues at length for a load.setup anchor that 519303d15 (#1622, row LTX25-DEVICE-RESIDENCY) had already landed as load.open — same region, same open and close statements, same Scope::Close shape. Merging it writes a materially false narrative onto main irreversibly. That is a defect in the message, not in the code.

Why the code alone was not enough to salvage

Verified on db648fb88 by a tree-wide grep over src/, include/, tests/ and docs/:

symbol	occurrences on `main`
`load.dit_config`	0
`artifacts.mux`	0
`sampler_updates`	0
`Record::instrument_seconds`	0
`denoise.update`	1 — `test_ltx2_video.cpp:4325`, which is `6b48edb2c`'s comment ASKING for it

So the supersession covers ONE anchor, not the branch: three anchors plus a ~193-line change to shared instrument semantics and 583 lines of test remain genuinely new. That is a fresh row's work with its own red-first tests and its own fresh review, on a branch that conflicts in three files — not a small salvage. It is owed under #1668.

What this commit preserves

Ten issues are open on the forge and none of them had a row in .agents/issue-index.md: #1470, #1536, #1567, #1568, #1569, #1570, #1571, #1572, #1619 and #1668. Closing the pull request without this would have left all ten invisible in the record, along with 809 lines of measurement.

Two things in there are worth more than the anchors:

The residue decomposition. 92.09% of the un-named time is ONE region — the load prologue, 17.661 ms of a 19.178 ms residue. The other four gaps are 4.95%, 1.30%, 1.09% and 0.56%, and the sixteen gaps between adjacent named phases hold 6.8 us each, which is the instrument and nothing else. #1536's own first hypothesis, d995c52f0's temporal x2 upsampler, is refuted rather than deprioritised: it runs inside phase.upsample_latent, a named leaf, and is not in the residue at all.

A rejected gate design, with its distributions. residue <= 2 * instrument measured red 4 in 45 at the table bound (load 88, max 4.115), 3 in 200 at the conservation case, 2 in 200 at unit.parent, and 28 in 160 (17.5%, max 5.55) on a standalone probe at load 125. The un-instrumented remainder of a boundary dilates faster than the instrumented part under contention, so the ratio has a heavy right tail — and the 20-run distribution that read 1.021 to 1.464 saw none of it. Three fresh reviews paid for that. ## Design 3 exists so nobody measures it again.

The spec is written to today's position

No ## Gates section, because the row is not runnable and a ## Gates edit moves a row into the runnable population as a side effect. No ## Outcome, because there is no outcome yet. ## Now states plainly that the implementation is not on main, and names refs/pull/1556/head = b45ea3bbb, where the reference implementation, the full gate report, the mutation table and the three review threads stay readable.

Two index rows are corrected before they are appended rather than after. The branch wrote #1470 and #1536 as closed by anchoring the sampler step — true of the branch, never true of the tree. They now say what actually landed instead, and say that an earlier draft claimed otherwise.

Five inherited claims the fresh review falsified, and this record does not repeat

A record pull request whose sentences are wrong is entirely defective, and four of these came verbatim from #1556's spec without being re-verified. Two were landing in append-only rows. Repaired in 2f2fc2dc7.

check-agent-record.py never passed the duplicate. #1556's spec said git merge-tree, check-agent-record.py and check-issue-index-append-only.py all accepted the 538-line union output. Reproduced, and false: that checker returns rc=1 with issue #1546 listed twice, and the refusal has existed since 8dd6508da (2026-08-09) — before the merge in question. Verified twice, restored byte-for-byte both times. The gap is real and narrower: one checker is blind, not two.

"Three months" is arithmetically impossible. #1439, #1470, #1494 and #1536 were filed between 2026-08-20T05:23Z and 2026-08-21T04:40Z — under 24 hours. This repository's first commit is accfae2de, 2026-07-02, so nothing in it can be three months old.

ltx2_res2s.cpp has never existed. git log --all --diff-filter=A finds no such file. Ltx2Res2sDenoisingLoop lives in ltx2_samplers.cpp, declared in ltx2_samplers.h beside Ltx2Res2sHooks, called from ltx2_video.cpp. #1567's forge text names no file, so the wrong anchor was invented by the spec.

The #838 recurrence is withdrawn as unreproducible. Re-running git merge-file --union at every later merge where #838 sat on a side leaves it present in all of them. A union driver cannot drop a line that is an addition on one side. That sentence was what turned a measured one-off into a recurring class.

d27639e71 is not a build-newest-gcc repair. It is BACKEND-TENSTORRENT-HOST-FREE-FORWARD (#1476/#1595) and added the same <unistd.h> in passing; only 13548db8f (#1581) is that lane's fix. And "records that as a holding action, in terms" claimed a quotation the tree does not contain — right in substance, not in those words.

A fifth claim — this one was mine, not inherited

While waiting on CI I re-measured the one assertion in this PR I had taken from the reviewer rather than run myself. It was overstated, and it was landing in an append-only row. Repaired in 72589fe6e.

The #1619 row said check-issue-index-append-only.py reds a correct de-duplication. Measured on a scratch branch off this head, with commits — that checker diffs merge_base..HEAD from Git objects and ignores a working tree:

committed mutation	`check-issue-index-append-only.py`	`check-agent-record.py`
duplicate a row	rc=0 (blind)	rc=1, `listed twice`
then remove the duplicate	rc=0	—
relocate a base-reachable row	rc=1, `removed: ... #168`	—

Add-then-remove nets to nothing against the merge base, so it passes.

And the de-duplication claim needs a condition, which a re-review supplied and which I had not measured. The rows above all use origin/main as the base — a base that predates the duplicate. Run at three pairings:

--base e2a9e035d  --head <real canonical 537>   ->  OK    rc=0
--base e2a9e035d  --head <synthetic 537>        ->  OK    rc=0
--base <committed 538>  --head <537 de-dup>     ->  FAIL  rc=1

So the checker reds a de-duplication only when the duplicate is already reachable from the base — when you are repairing a corruption that already landed. It does not fire on someone who fixes union output before committing it, which is the ordinary case and the shape this branch used. The same range property is what makes relocating a base-reachable row red.

Two lessons recorded rather than absorbed silently. Mine: three earlier probes edited the working tree and read rc=0 from all of them, including one that deleted a base row — that is not evidence about a checker that reads commits. The reviewer's, which it volunteered: it first marked this half confirmed from reading removed = [...], and reading the collector says what it collects, not what the diff range puts in front of it.

Recorded because the method matters: my first three probes edited the working tree and read rc=0 from all of them, including one that deleted a base row. That is not evidence about the checker, it is a restatement of the fact that it reads commits. The check-agent-record.py rc=1 result re-confirms the F1 correction above in the same run.

Evidence

git diff --numstat <merge-base> HEAD
 10      0       .agents/issue-index.md
      .agents/specs/ltx25-phase-residue.md  (new file)

issue-index: 592 rows, 592 unique issue ids, 0 duplicates, additions-only
             this branch's ten rows are 598-607 (#1470 .. #1668); main's
             #1666/#1667 follow at 608-609 and #1131 at 610, so the file
             ends at neither side's append

scripts/agent-preflight.sh   exit=0, All gates green, none skipped

The evidence quotes a merge-base sha, not origin/main — deliberately. main moved three times during this work (db648fb88 → 5539686c7 → 9712ab77f → 3e5d2f370), and the same command against a moved main measures a different thing: git diff --numstat 5539686c7 3d6a0a421 reads 10 1, where the lone deletion is main's own #1131 row that the pre-merge head did not yet have. Against the merge base it reads 10 0. A number derived from a name that resolves differently every few minutes describes whichever main was current when the command ran, not the change. (An earlier revision of this body said that reading was 1 1. It is not reproducible at any pairing, and it is corrected here rather than carried — the index did not move at all between 5539686c7 and 9712ab77f.)

On the row placement, stated rather than glossed: the canonical procedure the #1619 row prescribes is to append at the true end and re-verify. That is not what this head looks like — the union merge placed main's #1131 after this branch's ten. Additions-only and duplicate-free both hold, and no row was lost or edited, so the result is correct; but the ordering is the driver's, not the procedure's, and saying otherwise would repeat exactly the kind of unchecked claim this PR exists to correct.

Zero-duplicate ids is asserted rather than assumed. It is not the detector #1619 was filed about — that was this PR's own earlier position, and the repair overturned it: check-agent-record.py has refused duplicate ids since 8dd6508da. #1619's remaining ask is row multiplicity.

test_cpu_x86_llamacpp_floor red once during this work at loadavg 31.79, NO_QUIET_WINDOW (4) where the case expects GIVING_UP (2). That is #618 verbatim and load-dependent: it passed on a clean tree and then passed again on this tree at lower load. A records-only diff of two Markdown files cannot reach a CPU floor harness.

One scope correction while we are here: "neither red reproduces" means the two floors this row was filed against. It is not a claim that test_ltx2_video is quiet — #1572, one of the rows in this batch, records assertion (1c)'s span slack redding intermittently on main, which this row neither causes nor repairs.

This row has no matrix row and therefore no lifecycle state, so scripts/now.py and audit-live-rows will not surface it. That is deliberate while the implementation is unlanded: creating a row now would put an empty one in the runnable population. #1668 is the forward owner and creates the row with the code.

Nothing is closed here

#1439, #1470, #1536, #1567, #1568, #1569, #1570, #1571, #1572 and #1619 all stay open. #1668 stays open and carries the implementation. This commit records #1668 rather than discharging it.

Why this merged without a complete rollup on its exact SHA

Recorded because a reader six months from now will see a merge on a partially-settled rollup and needs to know it was a judgement, not an oversight.

main moved five times while this branch was in review (db648fb88 → 5539686c7 → 9712ab77f → 3e5d2f370 → d25730fbb → 4ede6bdfd). GitHub does not honour the merge=union driver on .agents/issue-index.md, so each move marked this PR CONFLICTING and forced a real merge commit, which restarts a ~75-minute CI cycle. At ~10 commits/hour into main, that loop has no fixed point.

The gated tree is d25730fbb — a commit on main, carrying main's own CI verdict. This branch's head b3761b976 is that tree plus this change, and the delta cannot reach anything CI compiles or runs:

git diff --stat d25730fbb b3761b976 -- src include tests examples
                                                        [empty]

git diff --stat d25730fbb b3761b976
 .agents/issue-index.md               |  10 ++
 .agents/specs/ltx25-phase-residue.md | 285 +++++++++++++++++++++++++++++++++++
 2 files changed, 295 insertions(+)

Two Markdown files, 295 insertions, zero deletions. The compiled artifacts at this head are byte-identical to d25730fbb's by construction, so d25730fbb's verdict is not "probably still valid" — it is a verdict about the same binaries. Both SHAs are pinned deliberately: origin/main is a moving ref, and diffing it instead of a pinned commit made this same branch appear to delete 768 lines of vocoder1d.cpp, cpu_conv1d_* and three test files, when the deletions were 4ede6bdfd landing between two commands.

What did settle on this branch's own rollups was verified by failure text, not job name, against main's baseline 90e8c3c85: build-test-cpu and sanitize-cpu (address,undefined) each fail one test of 590, test #282, on a byte-identical 335-byte assertion at test_runner.cpp:1557, with zero sanitizer diagnostics on both sides (#1602/#1608); windows-msvc-cpu and -vulkan fail on the /W4 /WX ... negated by /w checker refusal (#1649) that fires before any compilation, with zero error C#### and zero error LNK####. build-newest-gcc — the one job that can never be called inherited, since main-baseline.py's newest row predates #1581 — is green.

Records verified on the merged result rather than against the moving ref: 594 rows, 594 unique issue ids, zero duplicates, and git diff --numstat additions-only for this branch's ten rows.

FOLLOWING_AGENTS_PROTOCOL

Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: AGENT:claude-opus-5 [claude-code]

… request, and ten open issues had no index row PR #1556 is being closed rather than merged. `squash_merge_commit_message = PR_BODY` makes its body the permanent commit message, and that body argues at length for a `load.setup` anchor that `519303d15` (#1622) had already landed as `load.open` -- same region, same open and close statements, same `Scope::Close` shape. Merging it would have written a materially false narrative onto `main` irreversibly. That is a defect in the message, not in the code. So the code goes back to being owed, and the RECORD lands here. Without this commit, closing #1556 would take with it 809 lines of measurement, a rejected gate design that three fresh reviews paid for, and the only index rows ten open issues have -- #1470, #1536, #1567 through #1572, #1619 and #1668 are all open on the forge and NONE of them had a row in `.agents/issue-index.md`. What the record carries that nothing else does: * The residue decomposition. 92.09% of the un-named time is ONE region, the load prologue, 17.661 ms of 19.178 ms. The other four gaps are 4.95%, 1.30%, 1.09% and 0.56%, and #1536's own first hypothesis -- `d995c52f0`'s temporal x2 upsampler -- is refuted rather than deprioritised: it runs inside a named leaf and is not in the residue at all. * A REJECTED design, with its distributions. `residue <= 2 * instrument` measured red 4 in 45, 3 in 200, 2 in 200, and 28 in 160 on a standalone probe at load 125. The un-instrumented remainder of a boundary dilates faster than the instrumented part under contention, so the ratio has a heavy right tail -- and the 20-run distribution that read 1.021 to 1.464 saw none of it. Both wall-clock ratios stay. `## Design` 3 exists so nobody measures that again. The spec is written to the position that is true today, not to the one the branch had. It has no `## Gates` section, because the row is not runnable, and no `## Outcome`, because there is no outcome yet. `## Now` says the implementation is not on `main` and names `refs/pull/1556/head` = `b45ea3bbb`, where the reference implementation, the gate report and the mutation table stay readable. Two index rows are corrected before they are appended rather than after. The branch wrote #1470 and #1536 as closed by anchoring the sampler step, which was true of the branch and was never true of the tree. They say so, and they name what did land instead. Verified: `git diff --numstat origin/main -- .agents/issue-index.md` is `10 0`, appended at the true end; 585 rows, 585 unique issue ids, zero duplicates -- which is the detector #1619 in this same batch was filed about. `scripts/agent-preflight.sh` exits 0, all gates green. Records #1668. No issue is closed by this commit: #1439, #1470, #1536, #1567, #1568, #1569, #1570, #1571, #1572 and #1619 all stay open. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [claude-code]

…h review falsified The merge first, because it is the hazard this branch's own #1619 row documents. `origin/main` moved to `5539686c7` (#1672) during review and it appended a row to `.agents/issue-index.md`. Resolved by the canonical rule rather than by trusting the union driver: 586 rows, 586 unique ids, and `git diff --numstat origin/main -- .agents/issue-index.md` is `10 0`, additions-only against the moved main. Then the part that matters. This is a record pull request, so a false sentence in it is the whole defect and not a blemish -- and four of its claims came verbatim from #1556's spec without being re-verified. A record change that propagates a superseded change's unchecked assertions repeats the failure it exists to prevent, one remove further out. Two of them were landing in append-only rows. **`check-agent-record.py` never passed the duplicate.** #1556's spec said `git merge-tree`, `check-agent-record.py` and `check-issue-index-append-only.py` all accepted the 538-line union output. Reproduced here, and it is false: that checker returns rc=1 with `issue #1546 listed twice`, and the refusal has existed since `8dd6508da` (2026-08-09), before the merge in question. Verified twice -- once by regenerating the driver output at the historic merge, once by duplicating the last row on this head -- and restored byte-for-byte both times. The gap is real and NARROWER: exactly one checker is blind, not two. **"Three months" is arithmetically impossible.** The four issues that argued the tolerance -- #1439, #1470, #1494, #1536 -- were filed between 2026-08-20T05:23Z and 2026-08-21T04:40Z, under 24 hours. This repository's first commit is `accfae2de`, 2026-07-02, so nothing in it can be three months old. **`ltx2_res2s.cpp` has never existed.** `git log --all --diff-filter=A` finds no such file. `Ltx2Res2sDenoisingLoop` lives in `ltx2_samplers.cpp`, is declared in `ltx2_samplers.h` beside `Ltx2Res2sHooks`, and is called from `ltx2_video.cpp`. #1567's own forge text names no file, so the wrong anchor was invented by the spec and would have been copied forward by anyone who read the row. **The `#838` recurrence is withdrawn as unreproducible.** Re-running `git merge-file --union` at every later merge where `#838` sat on a side leaves it present in all of them. A union driver cannot drop a line that is an addition on one side; a wholesale take-ours resolution can, which indicts the resolver. That sentence was what turned a measured one-off into a recurring class, so it carried weight it had not earned. Two smaller ones. `d27639e71` is `BACKEND-TENSTORRENT-HOST-FREE-FORWARD` (#1476/#1595) and added the same `<unistd.h>` in passing; only `13548db8f` (#1581) is the `build-newest-gcc` repair. And "records that as a holding action, in terms" claimed a quotation the tree does not contain -- the substance is right, the words are not, so it now says so. Also stated rather than implied: this row has no matrix row and therefore no lifecycle state, which is deliberate while the implementation is unlanded, and #1668 is the forward owner that creates one. And "neither red reproduces" is scoped to the two floors this row was filed against, because #1572 in this same batch records assertion (1c) redding intermittently on `main`. Preflight exits 0 with all gates green and none skipped. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [claude-code]

`main` moved again while this branch's review findings were being repaired. This is the second such merge, and it is why the evidence in the pull request body quotes a MERGE-BASE sha rather than `origin/main`: that name resolves to a different commit every few minutes here, so a number derived from it describes whichever main happened to be current when the command ran. `.agents/issue-index.md` union-merged with no id collision. Verified against the merge base rather than against the moving name: 586 rows, 586 unique ids, and `git diff --numstat <merge-base> HEAD` is `10 0` on that file. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [claude-code]

…n its own, and the real trigger is relocation Caught by re-measuring a claim this branch had asserted without running it -- the exact failure this pull request exists to correct in #1556's spec, reproduced by me, one remove further out. It was landing in an append-only row. The row said `check-issue-index-append-only.py` reds a correct de-duplication. Measured on a scratch branch off this head, with commits rather than a working tree, because that checker diffs `merge_base..HEAD` from Git objects and ignores uncommitted edits: commit a duplicate row append-only rc=0 check-agent-record rc=1 commit its removal append-only rc=0 relocate a BASE-REACHABLE row append-only rc=1, "removed: ... #168" So add-then-remove nets to nothing against the merge base and passes. What reds the checker is RELOCATION of a row main already has. The gate does fire on a correct repair, but only when the repair also moves a base-reachable row, which is what "moving the anchor back behind the other side's rows" does. The mechanism in the parenthetical was right; the sentence in front of it was not. Three of my own probes before these were invalid and are recorded so the method is not repeated: they edited the working tree and read rc=0 from all of them, including one that deleted a base row. That is not evidence about the checker, it is a restatement of the fact that it reads commits. `check-agent-record.py` catching the duplicate at rc=1 is re-confirmed in the same run, which is the F1 correction this branch already carries. One format repair in the same commit: the replacement text contained a literal pipe inside a table cell and `check-agent-record.py` refused with "table has 6 pipes; expected 5". Rephrased without it. Preflight now exits 0, all gates green, none skipped. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [claude-code]

… being base-reachable My own correction two commits ago was itself over-corrected, and a re-review measured the condition I had asserted without running. It was landing in an append-only row. I had written that `check-issue-index-append-only.py` reds a correct de-duplication, with relocation named as the mechanism. Run at three pairings rather than reasoned about: --base e2a9e03 --head <real canonical 537> OK rc=0 --base e2a9e03 --head <synthetic 537> OK rc=0 --base <committed 538> --head <537 de-dup> FAIL rc=1 The checker diffs `merge-base..HEAD`. When the base PREDATES the duplicate, the addition and the removal cancel and it passes. It reds only when the duplicate is already reachable from the base, which is the case where somebody is repairing a corruption that already landed. `origin/main` is what preflight passes as the base, and it is the shape this branch used, so in the ordinary case the gate does NOT fire on someone who fixes union output before committing it. The substance survives and is unchanged: the checker is blind to the duplicate, confirmed unconditionally against the rebuilt 538-line artifact. What needed the condition is the repair half. Two method notes, because this is the same failure twice at different scales. Mine: three earlier probes edited the WORKING TREE and read rc=0 from all of them, including one that deleted a base row, which says nothing about a checker that reads commits. The reviewer's, volunteered: it first marked this half confirmed from READING `removed = [...]`, and reading the collector says what it collects, never what the diff RANGE puts in front of it. The same commit flattens the #1619 cell in the spec, which my previous edit had left carrying raw newlines inside a Markdown table cell. Preflight exits 0, all gates green, none skipped. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [claude-code]

Third merge of `main` on this branch. `#1677` appended six rows to `.agents/issue-index.md`; this branch's ten are untouched and no id collides. Verified against the merge base rather than against `origin/main`, which has now resolved to four different commits during this branch's review: 592 rows, 592 unique ids, zero duplicates, and `git diff --numstat <merge-base> HEAD` is `10 0` on that file. Row order after the union, stated because this branch's own #1619 row is about exactly this: the file does not end with the last row either side appended. The driver placed `#1131` after `#1667`. Additions-only holds, no row was lost or edited, and every id is unique, so the result is correct -- but the ORDERING is the driver's rather than the canonical append-at-the-true-end procedure, and recording it as the latter would be the unchecked claim this branch keeps catching. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [claude-code]

Fourth merge of `main` on this branch, and the forge reported the pull request `CONFLICTING` before it. That verdict is the union driver again: GitHub does not honour `merge=union` on `.agents/issue-index.md`, so two appends near the tail read as a conflict there while the driver applies cleanly here. It is the same mechanism this branch's #1619 row documents, seen from the other side. Verified on the merged result: 594 rows, 594 unique ids, zero duplicates, and `git diff --numstat origin/main -- .agents/issue-index.md` is `10 0` -- this branch's ten rows, additions only, nothing of main's lost or edited. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [claude-code]

Third merge of `main` on this branch, forced by this session's own #1670 landing ten rows into `.agents/issue-index.md`. GitHub reports `CONFLICTING` on that file because it does not honour the `merge=union` driver; locally the driver applies and the result is clean. Verified on the merged result against the pinned SHA rather than the moving name: 598 rows, 598 unique ids, zero duplicates, and `git diff --numstat 4503083 -- .agents/issue-index.md` is `1 0`, this branch's single #1663 row. This merge adds no content of this branch's own. Against `22ee35d7e`, the head whose CI rollup completed with zero pending, the four files this branch owns -- `scripts/attention-rung-allowlist.txt`, `tests/scripts/test_check_attention_rung_consistency.py`, `.agents/specs/attention-rung-visibility.md` and `.agents/kernel-matrix.md` -- are byte-identical. Everything else in the range is `main`'s own work arriving through two merges. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [claude-code]

…he file it named (#1665) `47a918d8f` (#1579, issue #1545) and `90e8c3c85` (#1557, issue #1549) landed the routing that `scripts/attention-rung-allowlist.txt` was parked for, and left their three stems behind. That is by design: `scripts/check-attention-rung-consistency.py` reports a discharged stem as `STALE (not a failure)` and exits 0, so the removing row never has to edit this file and the deletion falls to whoever runs preflight next. This is that preflight. Closes #1663. ## The window is not free, and that is the finding `## Risks/decisions` D4 of the spec says the deferral is safe because a stale entry is reported and never fatal. True of the exit code, and not the whole story: an allowlisted stem excuses its ENTIRE translation unit, never only the call that earned the entry. Every `VT-ATTN-NAIVE:` marker in a covered file is therefore decorative for as long as the stem sits there. Measured on `db648fb88` by deleting the live marker at `src/vllm/model_executor/models/ltx2.cpp:959`: | allowlist | checker | report | |---|---|---| | the three stems, as `main` has them | **rc=0** | `7 carry a recorded reason, 1 unmarked and excused` | | the stems removed, as here | **rc=1** | `src/vllm/model_executor/models/ltx2.cpp:966` | Both arms restored byte-for-byte against a sha256 taken before the mutation. So the entries were a live hole in the guard #1544 exists to be, open from `90e8c3c85` until here — not untidiness. The deferral D4 designs for is still right, because it genuinely keeps the removing row off a shared file; what is added to the spec is what it costs, so the next row that parks a stem reads it with the cost attached. ## The three earned their green separately, and asymmetrically - `muse_glimmer_vision` names `vt::Attention` **nowhere**: `47a918d8f` routed the perception encoder's sole path to `vt::AttentionDenseFlash`. - `ltx2` and `ltx2_device` still **name** it, at calls that now record their own reason — the host arm, CPU-only by construction, where `kAttention` and `kAttentionDenseFlash` resolve to the same registered function (`src/vt/cpu/cpu_ops.cpp:3750-3761`); and the `VLLM_LTX2_DIT_FLASH_ATTN=0` arm of a same-binary A/B, which exists so both halves of the 47.84 s / 7.680 s measurement run from one build. One assertion covering all three would be false of one of them in either direction, so the new test case asserts them apart. ## The expected set moves in the same change The allowlist's own header requires it: the checker does not fail on a stem set that has drifted, and `tests/scripts/test_check_attention_rung_consistency.py::ShippedTreeTests::test_allowlist_holds_only_the_in_flight_stems` does, on an addition or a deletion alike. An empty expected set is not a weaker assertion. `drift_sites` now excuses nothing, so `test_shipped_tree_is_green` measures the shipped tree on its markers alone, and a silent append still reds this case exactly as before — verified by appending `some_new_tower` and measuring 3 failures, restored after. The new `test_the_formerly_allowlisted_stems_pass_on_their_own_merit` re-states positively what the allowlist used to assert by omission. The header keeps the reason each stem left, so an empty parking lot does not read as an abandoned one. ## Evidence ``` python3 scripts/check-attention-rung-consistency.py OK (attention rung): 8 vt::Attention call site(s) in 8 model source file(s); 8 carry a recorded reason, 0 unmarked and excused by 0 allowlisted in-flight stem(s). rc=0 python3 -m unittest tests.scripts.test_check_attention_rung_consistency Ran 35 tests in 5.297s -- OK scripts/agent-preflight.sh exit=0, All gates green. scripts/agent-preflight.sh --staged exit=0, All gates green. ``` `.agents/specs/attention-rung-visibility.md` `## Now` records the discharge and the measured cost of the window. #1629 and #1631 are separate defects in the same checker and are untouched. ## Fresh review, and the four findings repaired in `f64effeca` The review confirmed the headline mutation independently and found four things. **F1 was the one that mattered**, and it was a regression this branch introduced. The `#1631` owed entry was edited to say the checker comment at `:252-255` "denies an equality that held ... and no longer does" — wrong in the direction that misleads, because if the equality no longer held then the comment denying it would be RIGHT. It still holds, and after this row it holds for a stronger reason: with an empty allowlist any green tree has `sites == marked` and `excused == 0` by construction, so it cannot fail. The same sentence credited the 8/8/0 triple to #1663, when `db648fb88` already read 8 sites and 8 marked — `47a918d8f` and `90e8c3c85` moved that; #1663 moves only the excused count. **F2** — the marker is at `ltx2.cpp:959`, not `:958`, which is `a.causal = false;`. Corrected here and in the index row, which is append-only and could not have been corrected after the merge. **F3** — the `KERNEL-ATTN-DENSE-FLASH` evidence cell read `checker green (9 sites / 6 marked / 3 unmarked and excused by the 3 in-flight allowlisted stems)`. Every number was already false on `db648fb88` and all three would be false again after this row, which is the point: a count of one file stored in another reds on every row that legitimately adds or removes a call. The cell stops quoting the triple rather than restating it, because restating it rebuilds the drift lock AGENTS.md `## Records` forbids — and that is the same defect #1629 names in this checker's own test. **F4** — `test_every_allowlisted_stem_names_a_real_model_source` now iterates over an empty set. Dormant, not dead, and the file now says so: it guards a file that is currently empty and fires on the first thing added to it, measured rather than asserted, since appending one bogus stem reds it together with the pinning case. `test_cpu_x86_llamacpp_floor` red twice during this work, at loadavg 31 with `NO_QUIET_WINDOW` and `busy=161%`. That is #618, and it is not reachable from a diff of three Markdown files and one Python comment: the same suite passed on a clean tree and on this tree at lower load. ## Why this merged without a complete rollup on its exact SHA `main` moved six times while this branch was in review, the last move being this session's own #1670 landing ten rows into `.agents/issue-index.md`. GitHub does not honour the `merge=union` driver on that file, so each move marked this PR `CONFLICTING` and forced a merge commit, restarting a ~75-minute CI cycle against a branch that merges ~10 commits/hour. That loop has no fixed point. **A complete rollup exists, and it covers every byte this branch contributes.** At `22ee35d7e` the rollup settled with **zero pending**. Against that head, the four files this branch owns are byte-identical to what is being merged now: ``` git diff --stat 22ee35d b974837 -- \ scripts/attention-rung-allowlist.txt \ tests/scripts/test_check_attention_rung_consistency.py \ .agents/specs/attention-rung-visibility.md \ .agents/kernel-matrix.md [empty] ``` So the `+41/-1` in the Python test — the one real test change here — was **present and gated** at the head that produced the complete rollup. Everything added to the range since is `main`'s own work arriving through three merges, each commit of which carries `main`'s own verdict. This is not "the delta is small enough to ignore"; it is that the delta contains none of this change. Both SHAs are pinned deliberately. `origin/main` is a moving ref, and diffing it instead of a pinned commit made a sibling branch appear to delete 768 lines of `vocoder1d.cpp`, `cpu_conv1d_*` and three test files, when the deletions were another commit landing between two commands. **Every failure at that gated head was verified inherited by failure text**, not by job name, against `main`'s baseline `90e8c3c85`: | job | evidence | |---|---| | `build-test-cpu` | 1 of 590, test #282, **byte-identical 335-byte** assertion at `test_runner.cpp:1557` | | `sanitize-cpu (address,undefined)` | same assertion, **0** ASan/UBSan diagnostics both sides | | `sanitize-cpu (thread)` | same assertion, **0** TSan diagnostics both sides | | `windows-msvc-cpu` / `-vulkan` | `/W4 /WX ... negated by /w` refusal (#1649), fires before compilation, **0** `error C####`, **0** `error LNK####` | | `build-newest-gcc` | **green** — the one job that can never be called inherited, since `main-baseline.py`'s newest row predates #1581 | The `test_runner.cpp:1557` failure is #1602/#1608: the attention-backend selector refuses a non-multiple-of-16 block size before `CheckKvCacheShape` can, so the case asserts a message only a ROCm/FLASH_ATTN build produces. Nothing outside that characterised set appeared on any run of this branch. Records verified on the merged result: 598 rows, 598 unique issue ids, zero duplicates, `1 0` for this branch's single #1663 row. Local preflight green at the pushed head, no gate skipped. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [claude-code] --------- Co-authored-by: Ettore Di Giacinto <mudler@localai.io>

mudler added 3 commits August 22, 2026 07:30

mudler added 4 commits August 22, 2026 08:40

localai-bot merged commit 4503083 into main Aug 22, 2026
10 of 20 checks passed

localai-bot mentioned this pull request Aug 22, 2026

fix(#1663): a stale attention-rung stem excused a DELETED marker in the file it named #1665

Merged

localai-bot deleted the row/LTX25-PHASE-RESIDUE-RECORD branch August 22, 2026 10:39

Navigation Menu

record(LTX25-PHASE-RESIDUE): the row's measurements outlived its pull request, and ten open issues had no index row - #1670

record(LTX25-PHASE-RESIDUE): the row's measurements outlived its pull request, and ten open issues had no index row#1670
localai-bot merged 7 commits into
mainfrom
row/LTX25-PHASE-RESIDUE-RECORD

localai-bot commented Aug 22, 2026 •

edited

Loading

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

localai-bot commented Aug 22, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Why that pull request cannot merge

Why the code alone was not enough to salvage

What this commit preserves

The spec is written to today's position

Five inherited claims the fresh review falsified, and this record does not repeat

A fifth claim — this one was mine, not inherited

Evidence

Nothing is closed here

Why this merged without a complete rollup on its exact SHA

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

localai-bot commented Aug 22, 2026 •

edited

Loading