tests/vllm/multimodal/test_ltx2_video.cpp's two schedule-anchor cases — the ti2vid one and the keyframe_interpolation one row LTX25-KEYFRAME-INTERP (#1096) copied from it — return Rendered{t.schedule_tokens, gen.steps} from their render lambda. The comment beside it says the step count is "read back out of them rather than restated below", and gen.steps is the REQUEST, written by the same lambda two lines earlier. It is the request restated, not the render observed.
The guard is WEAKENED, not vacuous, and the distinction is why this is filed rather than repaired in flow. It still catches the mutation it was built for: the lambda pins gen.steps = 3 with a comment saying 2 would make the schedule {1, 0.1, 0} for every token count and leave the anchor unable to reach the trajectory, and the assertions below recompute Ltx2SigmaSchedule at rendered_steps, so lowering that literal reds them by name. What it cannot catch is an engine that ignored the request and ran a different number of steps: the four REQUIRE(x.steps == rendered_steps) lines then compare four copies of one request field and agree trivially.
Ltx2ConditioningTrace already carries the observation. dit_evaluations (include/vllm/multimodal/ltx2_video.h:757-774) is every denoiser call the render made, incremented at one site inside the shared Evaluate lambda, and is steps per phase on the Euler and ancestral arms against 2 * steps + 1 on res_2s. Deriving the step count from it — rather than from gen.steps — would make the four REQUIREs a statement about four renders instead of about four copies of one integer.
Not repaired in the review-repair flow for #1096 because it changes what an existing landed case measures on BOTH pipelines, the res_2s control included, so it needs its own red-first evidence that the derived count reproduces the current literal on every arm the case drives. A repair that quietly re-derives a passing assertion is the shape this protocol asks to be gated rather than slipped in.
Listed under ## Owed in .agents/specs/ltx25-keyframe-interp.md. Found by the fresh review of #1096.
tests/vllm/multimodal/test_ltx2_video.cpp's two schedule-anchor cases — theti2vidone and thekeyframe_interpolationone rowLTX25-KEYFRAME-INTERP(#1096) copied from it — returnRendered{t.schedule_tokens, gen.steps}from their render lambda. The comment beside it says the step count is "read back out of them rather than restated below", andgen.stepsis the REQUEST, written by the same lambda two lines earlier. It is the request restated, not the render observed.The guard is WEAKENED, not vacuous, and the distinction is why this is filed rather than repaired in flow. It still catches the mutation it was built for: the lambda pins
gen.steps = 3with a comment saying 2 would make the schedule{1, 0.1, 0}for every token count and leave the anchor unable to reach the trajectory, and the assertions below recomputeLtx2SigmaScheduleatrendered_steps, so lowering that literal reds them by name. What it cannot catch is an engine that ignored the request and ran a different number of steps: the fourREQUIRE(x.steps == rendered_steps)lines then compare four copies of one request field and agree trivially.Ltx2ConditioningTracealready carries the observation.dit_evaluations(include/vllm/multimodal/ltx2_video.h:757-774) is every denoiser call the render made, incremented at one site inside the sharedEvaluatelambda, and isstepsper phase on the Euler and ancestral arms against2 * steps + 1on res_2s. Deriving the step count from it — rather than fromgen.steps— would make the fourREQUIREs a statement about four renders instead of about four copies of one integer.Not repaired in the review-repair flow for #1096 because it changes what an existing landed case measures on BOTH pipelines, the res_2s control included, so it needs its own red-first evidence that the derived count reproduces the current literal on every arm the case drives. A repair that quietly re-derives a passing assertion is the shape this protocol asks to be gated rather than slipped in.
Listed under
## Owedin.agents/specs/ltx25-keyframe-interp.md. Found by the fresh review of #1096.