feat(LTX25-PHASE-LORA): the adapter set belongs to a phase, and the DiT moves between them (#1118)

.agents/issue-index.md

@@ -333,3 +333,4 @@ rather than merged. `scripts/check-agent-record.py` gates both.
 | [#1134](https://github.com/mudler/vllm.cpp/issues/1134) | `BACKEND-ROCM` | The `VT_ATTN_DECODE_D128=1` ctest registration added by #767 cannot show the ROCm `d=128` decode arm REACHED the new kernel, and is empty off ROCm. `RegisteredDevices()` (`tests/vt/test_backend_cross_device.cpp:84-96`) enumerates `{kCUDA, kMETAL, kVULKAN, kXPU, kROCM}` and excludes `kCPU`, so on a CPU-only runner — which is what CI has — the new "Qwen3 geometry (bf16, GQA 2, head_dim 128)" case reports 1 test case, 0 assertions, exit 0, for BOTH registrations. On ROCm hardware the case's only backend assertion is `OpProviderStats::declines == 0`, and `OpProviderStats` counts at PROVIDER granularity, so it is identical with the flag set and unset; the NMSE bound passes on either kernel because the arm is correctness-complete. The two compose: there is no machine in this project on which the flag-ON registration distinguishes itself from the flag-OFF one. Disclosed in [`specs/rocm-decode-attn-d128.md`](specs/rocm-decode-attn-d128.md) §4, its `## Owed` section and its result banner, and §9 stop condition 2 is left OPEN rather than claimed discharged. Closing it needs a kernel-selection counter in `src/vt/rocm/rocm_paged_attn.hip` asserted to DIFFER between the two registrations; the CPU-runner half wants `kCPU` in `RegisteredDevices()` or a non-zero-assertion floor per [#463](https://github.com/mudler/vllm.cpp/issues/463). Not a duplicate of #463 (that is the unset-weights-env-var shape and does not describe the `declines` granularity half), #785 (a kernel that never LAUNCHES behind a dead `#if`, a code defect not a coverage one) or #900 (same family, LTX-2.5 subject) | bug |
 | [#1146](https://github.com/mudler/vllm.cpp/issues/1146) | `ENV-LEASE-RUNTIME-STAGING` | #1129 is closed and its recorded cause is FALSIFIED by the worker image: it says a leased worker "cannot start Python" and lists `python3`, `pip`, `gcc`, `curl` and `git` as ABSENT, measured in one `dgx:gpu0` probe (job `ff28ada1-0cd3-4867-bf9b-f67050d0608b`). Measured 2026-08-17 on `thor:gpu0` through five `rc run` jobs (`6f4bdb03`, `9c0ebeac`, `8beba132`, `f60d945f`, `63c60a90`), that worker runs as `uid=0(root)` with `/usr/bin/gcc`, `/usr/bin/python3` and a working `apt-get`, and a relocated CUDA runtime staged on `/workspace` imports torch 2.13.0+cu130, reports `cuda available = True` on `NVIDIA Thor` capability (11,0), runs a bf16 matmul, and compiles and executes a Triton kernel (`TRITON_JIT_OK = 4096.0 PASS`, `PROBE5_RC=0`). So the image is provisionable per job, which is none of the three fleet-side fixes #1129 names as the only ways forward. Four walls stand between a staged runtime and a running one: the `pip --target` must run FROM the worker because the submitting host is `x86_64` and the workers are `aarch64`. `Python.h` is absent until `apt-get install python3-dev`. The NAS mount presents `file_mode=0664` so Triton cannot execute its own `ptxas-blackwell`, and `TRITON_PTXAS_PATH` does NOT fix it because it redirects only the plain `ptxas`. So `PYTHONPATH` is ORDERED, `/tmp/tp` before the NAS tree. SCOPE, and it is the point of the row: this is `thor:gpu0` at capability (11,0) ONLY, the GB10 is `sm_121a` and UNMEASURED, only `torch`, `triton` and `numpy` are staged so the pinned vLLM oracle is still NOT shown to run and #1129's consequence for the oracle-dependent rows is NARROWED rather than closed, the `+cu130` versus `release 12.8, V12.8.93` skew is recorded as observed and not adjudicated, and a prebuilt wheel does NOT shorten the route because an aarch64 vLLM wheel exists in general while our pin is neither among the wheels published for the one nightly commit nor on PyPI (the per-commit 404s prove nothing, because that URL scheme was never confirmed against a known-good case). Recipe, job IDs and staged-script sha256 values in [`lease-runtime-staging.md`](specs/lease-runtime-staging.md) | verification |
 | [#1033](https://github.com/mudler/vllm.cpp/issues/1033) | `GATE-ISSUE-INDEX-TABLE-SHAPE` | `check_table_shapes` (`scripts/check-agent-record.py:1292`) never ran on `.agents/issue-index.md`, so a malformed row there was invisible to every gate. The function already counted unescaped pipes per table line with exactly the right regex; its call site (`:1527-1530`) passed `roadmap_v1.md`, `coordination.md`, `*MATRIX_PATHS` and `*spec_paths`, and simply did not pass this path. Nothing else in the tree counts this file's cells, which made the index the ONLY markdown table in the record set with no shape gate. It is also the one record surface every change must write, with rows long enough to hide a stray pipe in a code span. Arming it reds exactly one row on `origin/main` at `100026481`: a pipe histogram over the index's 289 table lines reads `{5: 288, 9: 1}`, and the outlier is line 279, the [#1003](https://github.com/mudler/vllm.cpp/issues/1003) `ORACLE-LLAMACPP-REPIN-STOCK` row that arrived with `283c7e492` ([#1051](https://github.com/mudler/vllm.cpp/pull/1051)), carrying four unescaped pipes inside code spans at columns 2705, 3106, 3115 and 3338. FIXED IN FLOW: the path is added, the four pipes are escaped, and three cases in `tests/scripts/test_agent_record.py` hold it — one capturing the paths `main()` really hands the gate, one running it on the shipped file, one mutating a copy so the instrument is proven to fire. Repairing the row EDITS an append-only file, so `check-issue-index-append-only.py` is red on the branch and the exception is argued in the commit body, as `ff264cb82` ([#1025](https://github.com/mudler/vllm.cpp/pull/1025)) argued the same one: appending a corrected copy would leave the broken row in place and add a duplicate key, so the file only becomes well-formed by editing it where it sits. TWO PREMISES OF THE REPORT MEASURED FALSE and are recorded in the spec rather than quietly dropped: the checker does NOT stop at the first finding (one `errors` list, three findings in one run, exit 1 once), and the four pipes are NOT in a `git diff` piped into `grep` — that span does not exist in the row. Spec [`gate-issue-index-table-shape.md`](specs/gate-issue-index-table-shape.md) | bug |
+| [#1144](https://github.com/mudler/vllm.cpp/issues/1144) | — | `Res2sTwoStageRecipe` is this tree's port of `TI2VidTwoStagesHQPipeline` (`ti2vid_two_stages_hq.py:59` @ `fd4ded7f`), the one in-scope pipeline that runs the SAME adapter on BOTH stages at DIFFERENT strengths: it builds `distilled_lora_stage_1` and `distilled_lora_stage_2` from one path (`:92-101`) and hands one to each `DiffusionStage.from_checkpoint` (`:154`, `:165`), CLI-defaulted 0.25 and 0.5 (`utils/args.py:1174-1184`). Here neither phase sets `Ltx2PhaseRecipe::loras`, so both take the `kAllAdapters` default, and the engine carries ONE strength for the whole load (`lora_strength` absent is 1.0, `include/vllm/multimodal/ltx2_video.h:214-218`) — so both stages run at 1.0. Nothing refuses and nothing changes shape; only a render against upstream on the same checkpoint, take and seed sees it. A NEW FIELD ON `Ltx2PhaseRecipe` DOES NOT CLOSE IT: `Ltx2RebindDitLoras` early-returns on `currently_fused == fuse` where `currently_fused` is `checkpoint.lora_fused_tensors > 0`, a BOOLEAN, so it detects "already fused" and never "already fused AT THIS STRENGTH" — and HQ has both stages fused, so the no-op its own header advertises would swallow the transition and stage 2 would render at stage 1's strength. Closing it needs `bool fuse` to become a type carrying a strength AND `Ltx2DitCheckpoint` to record WHICH adapter state is applied, plus a `--distilled-lora-strength-stage-1`/`-stage-2` request pair, since one `lora_strength` extra cannot spell two values. The re-materialize-and-write-back mechanism #1118 landed is untouched by that change. Filed because [#921](https://github.com/mudler/vllm.cpp/issues/921), which owned the per-phase strength in [`ltx25-phase-lora.md`](specs/ltx25-phase-lora.md), was CLOSED as completed on 2026-08-17 by `LTX25-RES2S-LOOP` (`4d7748646`, PR [#1125](https://github.com/mudler/vllm.cpp/pull/1125)); that row named the distilled LoRA per stage as out of scope and correct to leave, but did not list it under its own `## Owed`, so the debt outlived its issue with no open owner. Found during the review repair of PR [#1140](https://github.com/mudler/vllm.cpp/pull/1140). Listed under `## Owed` in [`ltx25-phase-lora.md`](specs/ltx25-phase-lora.md) | bug |

.agents/specs/ltx25-a2vid-recipe.md

@@ -439,9 +439,14 @@ Report `NEEDS_DECISION` rather than narrowing silently if:
 ## Owed
 
 - **[#1118](https://github.com/mudler/vllm.cpp/issues/1118) — the per-phase
-  adapter.** §4.4. Owned by this row. It also bounds
-  [#1093](https://github.com/mudler/vllm.cpp/issues/1093) and
-  [#921](https://github.com/mudler/vllm.cpp/issues/921).
+  adapter.** §4.4. Filed by this row and CLOSED by row `LTX25-PHASE-LORA`
+  ([`ltx25-phase-lora.md`](ltx25-phase-lora.md)), which puts the distilled
+  adapter on stage 2 alone and makes `A2VidTwoStageRecipe`'s stage 1 run the
+  base weights, as `a2vid_two_stage.py:107` does against `:114`. That row also
+  unbounds [#1093](https://github.com/mudler/vllm.cpp/issues/1093) and
+  [#921](https://github.com/mudler/vllm.cpp/issues/921) on this seam; both
+  remain blocked on their own checkpoints and, for #921, on a per-phase adapter
+  STRENGTH that the seam deliberately does not carry.
 - **A real-checkpoint A2V render.** Gated on fixtures only. The artifacts exist
   now — `/usr/local/nas_share/checkpoints/ltx-2.5/lightricks-ltx-2.5/` holds the
   NVFP4 DiT, both video VAEs, the audio VAE, both upscalers and