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

.agents/issue-index.md

@@ -595,6 +595,7 @@ rather than merged. `scripts/check-agent-record.py` gates both.
 | [#1659](https://github.com/mudler/vllm.cpp/issues/1659) | `SPEC-DFLASH2` | **The speed harness asserts `--attention-backend` and never passes it to `LLM()`, so the declared denominator is unreachable by any path.** Measured on `dgx:gpu0` 2026-08-22 at `bed3feae6`. `capture()` built `LLM(...)` with no backend kwarg while `attention_backend_reasons` requires `resolved == declared`, and the arm log under a declared `TRITON_ATTN` reads `Using FLASH_ATTN attention backend out of potential backends: ['FLASH_ATTN','FLASHINFER','TRITON_ATTN','FLEX_ATTENTION']`. So repairing [#1658](https://github.com/mudler/vllm.cpp/issues/1658) ALONE would make the arm resolve `FLASH_ATTN`, compare it against the declared `TRITON_ATTN` and refuse on the mismatch: a working gate needs this, the probe entry and [#1657](https://github.com/mudler/vllm.cpp/issues/1657), not any one of them. This reproduces W6's recorded failure at a later head -- [#1456](https://github.com/mudler/vllm.cpp/issues/1456) measured vLLM's vendored flash-attention unable to target sm_12x, which is why `TRITON_ATTN` is the declared oracle backend on this box at all. FIXED IN FLOW: the declared backend is passed over the spellings `ATTENTION_BACKEND_KWARGS` names -- `attention_config` carrying a `backend` key first, because the measured read-back walk is `vllm_config.attention_config.backend`, then a bare `attention_backend`. The spelling is UNVERIFIED at the beyond-pin head, on the same footing `BACKEND_PROBES` was on: a wheel REJECTS a kwarg it does not declare with a `TypeError` raised while `EngineArgs` is built and therefore before anything loads, so trying both costs no lease time; a wheel that takes NEITHER is a loud refusal naming both; a spelling that is accepted and IGNORED is caught by the read-back, which is this refusal; and `--attention-backend-kwarg` pins the answer once known, with no code change. Owned by [`dflash2-spec-decode.md`](specs/dflash2-spec-decode.md) `## Owed` O28 | bug |
 | [#1660](https://github.com/mudler/vllm.cpp/issues/1660) | `SPEC-DFLASH2` | **A DFlash2 lease needs `cuda-libraries-dev-13-0` and `python3-dev`, and `RC_LEASE_ID` does not exist on this fleet.** Measured on `dgx:gpu0` 2026-08-22 over leases `52ac5673` and `a03f34e4`. DFlash2's `compute_candidates` -> `_topk` -> `flashinfer.topk` JIT-compiles `topk.cu`, which includes `<curand.h>`; the `cuda-toolkit-13-0` metapackage does NOT install that header, and leg B died on it INSIDE `profile_run` **after a 12-minute model load**, presenting as a model failure rather than a missing header. Leg C installed `cuda-libraries-dev-13-0` and got past it. `python3-dev` is likewise required or Triton driver JIT compilation fails, and that failure surfaces as `Model architectures ['Qwen3_5ForConditionalGeneration'] failed to be inspected` -- which names the model, not the toolchain. Separately, the leased worker carries `RC_DEVICE`, `RC_JOB_ID` and `RC_TOKEN` and no `RC_LEASE_ID`, so the gate's `--lease-id` default read empty and the `## Owed` O26 recipe run VERBATIM refused with `no lease id. Claim the device with rc run/rc hold first; never ssh to a fleet box`. The refusal is correct on a missing lease; the defect is that the committed procedure could not satisfy its own gate. FIXED IN FLOW: the default takes `RC_JOB_ID` first and falls back to `RC_LEASE_ID` -- the measured variable first, the documented-but-absent one for a controller that does export it -- both packages are recorded in [`environment.md`](environment.md) beside the existing note that no CUDA toolkit is preinstalled, and the O26 recipe now names them. Owned by [`dflash2-spec-decode.md`](specs/dflash2-spec-decode.md) `## Owed` O28 | bug |
 | [#1543](https://github.com/mudler/vllm.cpp/issues/1543) | `ENG-RECORD-CONFLICT-SURFACES` | `check-public-doc-tables.py` gates the projection documents for size and shape only, never for key uniqueness, so `docs/STATUS.md`, `docs/BENCHMARKS.md` and `docs/FEATURES.md` can each carry two contradictory rows for one key with nothing indicating which is current. MEASURED on [PR #1081](https://github.com/mudler/vllm.cpp/pull/1081): `docs/BENCHMARKS.md` carried the key `**NemotronH paged forward** (MODEL-NEMOTRON-H-ABI-A2P, #810)` TWICE and the two rows contradict -- one says the GB10 read was 4/24 with the sm_121a re-run pending a lease, the other says the same gate PASSES 96/96 -- and the checker returned rc=0 on that file. Counted directly, the key appears once on `origin/main` and twice on the PR head. The blindness is PROVED BY MUTATION rather than inferred from reading: a reviewer reinserted a duplicate key with contradictory content and `benchmarks_errors()` still returned `[]`, and the checker holds no uniqueness or duplicate-key logic at all (positive control: 14 `errors.append` calls in the same file, so the grep pattern finds what is there). No checker asserts uniqueness ON A PROJECTION DOCUMENT, and that is the whole gap -- duplicate-key checks themselves are neither scarce nor novel here, and the closest is prior art the fixing row should mirror rather than reinvent. `scripts/check-agent-record.py::check_matrices` already refuses a `duplicate ID` over the matrix inventories, keyed on the row ID and reported against the file and line that repeats it, and `scripts/check-agent-record.py::check_issue_index` refuses `issue #N listed twice` -- the refusal this very row had to be checked against before it was appended. That same file READS `docs/BENCHMARKS.md`, through `scripts/check-agent-record.py::markdown_files`, but never for key uniqueness. The remaining duplicate-key checks are structural rather than record-keyed and transfer nothing: a duplicate YAML key in `check-release-workflow.py`, a duplicate JSON key in `ready-for-helper.py`, a duplicated oracle-pin key in `check-oracle-pins.py`. The cause is that two record surfaces carry OPPOSITE disciplines and nothing tells an author which one is open: `.agents/issue-index.md` is an append-only log where appending is correct, and `docs/BENCHMARKS.md` is a keyed projection where appending is the defect. Two review passes and one operator verification missed it for one reason worth recording -- each checked that both sides' hunks survived the merge, which proves the merge was faithful and says nothing about whether the RESULT is key-unique. SCOPE for the fixing row, so it does not over-promise: assert uniqueness on the first table cell and scope it PER TABLE, because two tables may legitimately share a key and because `audit-live-rows --check` already reports three IDs live in two matrices (BACKEND-CPU, BACKEND-CUDA-SM121, BACKEND-VULKAN), so a naive global check reds `main` on day one -- the failure this repository already suffered twice in one week in [#1464](https://github.com/mudler/vllm.cpp/issues/1464) and [#1468](https://github.com/mudler/vllm.cpp/issues/1468). The red-before is available and is not hypothetical: PR #1081's own pre-repair head contains a real duplicate. NOT fixed in flow, and this index row does not fix it -- a checker-semantics change owes its own row, spec, red-before test or mutation, and green-after evidence, and #1081's separate repair collapses its two rows into one WITHOUT closing this, because the next append reproduces it. Owned here because this row is the standing owner of public-document projection-gate semantics ([#460](https://github.com/mudler/vllm.cpp/issues/460), [#495](https://github.com/mudler/vllm.cpp/issues/495), [#498](https://github.com/mudler/vllm.cpp/issues/498), [#507](https://github.com/mudler/vllm.cpp/issues/507), [#1055](https://github.com/mudler/vllm.cpp/issues/1055)) -- named at that width deliberately, because the five do NOT all sit in one script: #460's `check_links` and #498's retired `MAX_README_CHARS` live in `check-agent-record.py` and `check-readme-structure.py`, so calling the group `check-public-doc-tables.py` semantics would be false of two of them. The row is `READY` rather than `DONE`, and its spec already names `tests/scripts/test_check_public_doc_tables.py` as a red-before suite, so the owner is a live row whose declared test surface is the checker this issue indicts; the fixing row still owes the spec and the red-before, which ownership records rather than replaces | bug |
+| [#1663](https://github.com/mudler/vllm.cpp/issues/1663) | `KERNEL-ATTN-DENSE-FLASH` | **Three stems outlived their removing rows on `scripts/attention-rung-allowlist.txt`, and while a stem sits there it excuses its WHOLE translation unit -- including a marker somebody deletes.** `47a918d8f` ([#1579](https://github.com/mudler/vllm.cpp/pull/1579), issue [#1545](https://github.com/mudler/vllm.cpp/issues/1545)) routed `muse_glimmer_vision`'s perception encoder to `vt::AttentionDenseFlash`, and `90e8c3c85` ([#1557](https://github.com/mudler/vllm.cpp/pull/1557), issue [#1549](https://github.com/mudler/vllm.cpp/issues/1549)) swapped the LTX-2.5 DiT device forward to the same op; after both, `muse_glimmer_vision` names `vt::Attention` nowhere, and `ltx2`/`ltx2_device` name it only at calls that now carry their own `VT-ATTN-NAIVE:` reason (the host CPU-only arm, where `kAttention` and `kAttentionDenseFlash` are the same registered function, and the `VLLM_LTX2_DIT_FLASH_ATTN=0` arm of a same-binary A/B). `scripts/check-attention-rung-consistency.py` reported all three `STALE (not a failure)` and exited 0, which is the header's design -- the removing row is not forced to edit this file and the deletion falls to the next preflight -- so the entries were owed rather than wrong. **The hole is MEASURED, not inferred.** On `db648fb88`, deleting the `// VT-ATTN-NAIVE:` marker at `src/vllm/model_executor/models/ltx2.cpp:959` leaves the checker at **rc=0** (`7 carry a recorded reason, 1 unmarked and excused`) with the three stems listed, and at **rc=1** naming `ltx2.cpp:966` with them removed; both arms restored byte-for-byte against a pre-taken sha256. The window was open from `90e8c3c85` until this fix. FIXED IN FLOW: the stems are deleted and `tests/scripts/test_check_attention_rung_consistency.py::ShippedTreeTests::test_allowlist_holds_only_the_in_flight_stems` moves to the empty set in the same change, as the allowlist header requires. The empty set is not a weaker assertion -- `drift_sites` now excuses nothing, so `test_shipped_tree_is_green` measures the tree on its markers alone -- and a new case asserts the three stems positively and ASYMMETRICALLY, `ltx2`/`ltx2_device` present-and-marked against `muse_glimmer_vision` absent, because one assertion covering all three is false of one of them in either direction. Distinct from [#1629](https://github.com/mudler/vllm.cpp/issues/1629), which is the population floor in the same checker and is untouched here. Spec [`attention-rung-visibility.md`](specs/attention-rung-visibility.md), parent [#1544](https://github.com/mudler/vllm.cpp/issues/1544) | bug |
 | [#1470](https://github.com/mudler/vllm.cpp/issues/1470) | `LTX25-PHASE-RESIDUE` | **`test_ltx2_video` false-redded once on `main` under load and the failing case's identity was never captured.** The prediction it records (F12 of #1441's fifth review) was that a coverage floor whose per-boundary sampling cost is fixed while the leaf shrinks is a false-RED risk and never a false pass. Measured by `LTX25-PHASE-RESIDUE`: the prediction is right about the polarity and WRONG about the term. The `denoise` coverage miss is not sampling cost, it is the sampler's post-process and Euler step, which no anchor wrapped and which scale with the latent -- 49 us per step at nine frames against 343 us at 81, in ONE run of one binary, and instrument cost does not move 7x with the latent. **STILL OPEN, and the correction above is the whole of what this row establishes.** The row's branch anchored that work as `denoise.update` and [#1556](https://github.com/mudler/vllm.cpp/issues/1556) is CLOSED rather than merged, so nothing anchors it on `main` today; the anchor is owed under [#1668](https://github.com/mudler/vllm.cpp/issues/1668). An earlier draft of this row said the issue was closed by anchoring, which was true of the branch and never of the tree. Spec [`ltx25-phase-residue.md`](specs/ltx25-phase-residue.md) | bug |
 | [#1536](https://github.com/mudler/vllm.cpp/issues/1536) | `LTX25-PHASE-RESIDUE` | **`test_ltx2_video` was persistently red rather than load-flaky, and it was the only failing test on `main`.** The issue asks for the residue to be DECOMPOSED rather than re-argued, and names `d995c52f0` (the temporal x2 upsampler) as the first hypothesis to test. The decomposition REFUTES that hypothesis and settles the cause: **92% of the un-named time is one region**, `Ltx2VideoEngine::Load` from the timeline's origin to `Open("load.dit")` -- 17.661 ms of a 19.178 ms residue -- while the upsampler's own work sits inside `phase.upsample_latent`, a named leaf that does not appear in the residue at all. The remaining 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. **The RED is gone and the issue is NOT.** `519303d15` ([#1622](https://github.com/mudler/vllm.cpp/pull/1622), row `LTX25-DEVICE-RESIDENCY`) names that same 92% region `load.open` -- same open point, same close point, same `Scope::Close` shape as this row's `load.setup` -- so the sum floor is repaired on `main` by another row, and the coverage floor is repaired by `6b48edb2c` moving it to 0.75, which that change's own comment describes as a holding action in substance, though not in those words. What is owed is the naming that would make a tight floor honest again, under [#1668](https://github.com/mudler/vllm.cpp/issues/1668). Spec [`ltx25-phase-residue.md`](specs/ltx25-phase-residue.md) | bug |
 | [#1567](https://github.com/mudler/vllm.cpp/issues/1567) | `LTX25-PHASE-RESIDUE` | the res_2s sampler arm has no `denoise.update` anchor, so its denoise would be decomposed on one arm only. Filed by `LTX25-PHASE-RESIDUE` and deliberately NOT landed with it, because no gate in this tree renders on that arm and an anchor no gate runs is dead code. `Ltx2Res2sDenoisingLoop` runs its own post-process and step behind `Ltx2Res2sHooks`, so the anchor needs a hook rather than a statement. It lives in `ltx2_samplers.cpp`, is declared in `ltx2_samplers.h` beside the hooks struct, and is called from `ltx2_video.cpp`. **NOT `ltx2_res2s.cpp`**: #1556's spec named that file and it has never existed here, which `git log --all --diff-filter=A` confirms; #1567's forge text names no file at all, so the wrong anchor came from the spec rather than from the issue. Doubly owed while [#1668](https://github.com/mudler/vllm.cpp/issues/1668) is open, since the first-order arm has no anchor either. Listed under `## Owed` in [`ltx25-phase-residue.md`](specs/ltx25-phase-residue.md) | bug |