fix(LTX25-PHASE-RESIDUE): 92% of the phase table's un-named time was one region, and two wall-clock ratios were measuring it (#1536) - #1556
Closed
localai-bot wants to merge 22 commits into
Closed
Conversation
…one region, and neither ratio could say so
`test_ltx2_video` is the only failing test on `main` and has been red for days
under a "load-flaky" label that its own measurements refute. Three assertions
fail across two cases, and both are wall-clock ratios: `leaves >= 0.95 * wall`
and `covered >= min_coverage * leaf_seconds`.
Decomposing the emitted table into the gaps between consecutive leaves settles
what four issues had only been able to argue about. **92% of the residue is one
gap**: `Ltx2VideoEngine::Load` from the timeline's origin to `Open("load.dit")`,
17.661 ms of a 19.178 ms residue, which is real work inside no leaf. The 16 gaps
between adjacent named phases together hold 0.108 ms, i.e. 6.8 us per boundary,
which is the instrument and nothing else. The same decomposition refutes #1536's
own first hypothesis: the temporal x2 upsampler runs inside a named leaf and does
not appear in the residue at all.
The coverage miss has the same shape one level down. Three of the four carrying
leaves miss by 7-42 us per sub-record, the instrument's own cost. `denoise` misses
by 49 us per step at nine frames and 343 us per step at 81 — a 7x move with the
latent inside one run, which is work rather than overhead, and which the case's
own comment already names as the sampler's un-anchored post-process and step.
So the repair is the one the failing assertion's own message asks for: name the
un-named time, anchor the un-anchored work, and then replace both ratios with a
bound derived from a quantity the instrument does not currently publish — the
wall it spends inside its own entry points outside every record. The spec argues
why that replacement is five orders of magnitude stricter than `0.95 * wall` at
the 21 B scale the tolerance was originally written for, rather than a widening,
and it names the stop condition that would make the bound indefensible.
Issues: #1536, #1439, #1494, #1470.
FOLLOWING_AGENTS_PROTOCOL
Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: AGENT:claude-opus-5 [claude-code]
…r's step, and bound the residue by the instrument's own cost
`test_ltx2_video` was the only failing test on `main`. Three assertions in two
cases, and both are wall-clock ratios: `leaves >= 0.95 * wall` and
`covered >= min_coverage * leaf_seconds`.
Neither number was the defect. Decomposing `unaccounted_seconds` into the gaps
between consecutive leaves — which nobody had done across four issues and three
months — settles it: **92% of the residue is one gap**, `Ltx2VideoEngine::Load`
from the timeline's origin to `Open("load.dit")`, 17.661 ms of 19.178 ms. The 16
gaps between adjacent named phases hold 6.8 us each, which is the instrument and
nothing else. The sum gate was failing for exactly the reason its own message
gives, and the repair it asks for is a scope.
The coverage miss is the same defect one level down. `denoise` misses by 49 us
per step at nine frames and 343 us per step at 81 — a 7x move with the latent
inside one run of one binary, so it is work rather than overhead. It is the
sampler's post-process and Euler step, which the case's own comment already named
and left un-anchored while tuning the threshold around it. That is also why
`denoise_min_coverage` had to be a parameter.
So this names `load.setup`, `load.dit_config` and `artifacts.mux`, and anchors
the sampler's own work as `denoise.update` with a counter the render maintains.
Both ratios are then replaced rather than retuned, because a share of the render
is the wrong quantity in both directions: 0.95 of wall permits 13.1 ms of
un-named time on this fixture and MINUTES on the 21 B render this instrument
exists for, while the residue itself is a fixed set of gaps that does not scale
with either. `PhaseLog` now measures the wall it spends inside its own entry
points — charged to the innermost live non-span record, or to the table when none
is live — and emits it per record and per table. The gates ask the scale-free
question instead: is the time nobody named larger than the cost of naming the
phases? Measured, the answer sits at 1.08 to 1.41 times the charge across eight
leaves and two geometries, against a bound of 2.
The sampler JOIN had to be charged too, and finding that is why the bound is
stated as "every interval" rather than "every boundary": uncharged, a two-scope
timeline whose gaps contain nothing reported a residue 3.12x its own charge,
which is indistinguishable from a real un-named phase. `WriteJson` also reads the
clock before it copies and sorts its records, so the writer stops being charged
to the render.
Assertion (1b) is strengthened in passing. `denoise` is the first leaf with two
REPEATING parts, which is the hole (1b)'s own comment discloses; where every part
has the same record count the i-th records are now paired instead of the first.
Closes #1536, #1439, #1494, #1470.
FOLLOWING_AGENTS_PROTOCOL
Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: AGENT:claude-opus-5 [claude-code]
…nd the `denoise.update` anchor it left owed `6b48edb2c` (GATE-CI-RED-REPAIR, #1494) landed while this row was building. It stabilised the same `denoise` coverage red by moving `denoise_min_coverage` from 0.95 and 0.90 to 0.75 and adding assertion (1c), the span slack, beside it — and its own comment says in terms that this was a holding action: *"NAMING THE UN-NAMED TIME WOULD SETTLE IT PROPERLY... A `denoise.update` scope over the sampler's per-step update would put the interior residue under a name and make a tight share floor honest again. It stays owed."* This row is that owed work, so the merge takes their change and completes it rather than reverting it. Four conflicts, all in `test_ltx2_video.cpp` and all in prose except two call sites that lost a parameter: * Their **measured population survives verbatim** and is the strongest evidence either side produced: an unchanged `denoise` measures 99.55% down to 88.85% across four boxes, and 85.85% at 81 frames. Eleven points of a leaf were un-anchored WORK, which is why no share floor could separate it from a swallowed phase, and why anchoring it is the repair rather than a third threshold. * Their **assertion (1c), the span slack, is untouched**, constants and all. It bounds the head and the tail alone, which is a different quantity from the total this row bounds, and it carries its own three-lane mutation evidence. * The **share floor they moved to 0.75 is deleted rather than moved again**, and deleting it removes nothing: 0.75 permits a quarter of a leaf to be un-anchored, where `uncovered <= 2 * leaf_instrument` permits twice an instrument charge measured in tens of microseconds. * Their comment's open question — *"A NORMALISED bound would be better, and there is no normaliser"* — is what `PhaseLog::Instrument()` and `Record::instrument_seconds` answer, and it is why their per-configuration 0.25 ms / 3 ms constants are not needed by the bound this row adds: an instrumented build inflates the charge and the residue together. `#1439`'s sum gate is untouched by their change and remains this row's to close. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [claude-code]
…epaired the same red three hours earlier The spec's Outcome now records what the merge decided and why: which of the two changes contributes what, that the 0.75 share floor is deleted rather than moved a third time, that assertion (1c) is kept exactly as it landed, and that `Record::instrument_seconds` is the normaliser that change's own text reports did not exist yet. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [claude-code]
…d under it, rather than clamping it `PhaseLog::Open` reads its clock before it takes the process-wide mutex, so a `Begin` on another thread between those two points moves the origin and the offset comes out negative. Clamping it to zero would charge the whole timeline so far to the instrument, and every bound derived from that number LOOSENS as it grows — so the clamp would turn a race into a gate that passes. The interval is not attributable to this timeline and is dropped. No path in the LTX-2.5 driver reaches it today; it is refused because the failure mode is silent and in the wrong direction. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [claude-code]
… a unit backstop the measurement showed was too tight Two repairs, both found by reading this branch's own CI and its own first green run rather than by argument. **#1565 is not this row's defect and is fixed here because the lane it breaks is the one that reports on this row.** `build-newest-gcc` has failed at the BUILD step on every commit since 5702d8f, so it says nothing about any pull request based on it. The cause is one missing include: `ScratchSafetensors` builds its temporary path from `::getpid()` and older libstdc++ headers pull `<unistd.h>` in transitively where the newest GCC does not. **The unit case's own bound reused `kInstrumentBudget` and should not have.** The argument for reusing it was that a budget which stopped covering a boundary would red in eleven lines rather than in a forty-second render. Running it refuted that: a bare micro-timeline is the WORST-conditioned probe of that ratio, not the tightest, because a render's boundaries carry a `Tick` and a `/proc/self/statm` read inside the instrumented region while eight bare scopes carry neither. Measured 1.21 quiet and 1.87 at load average 98, against 1.06 to 1.42 for the four carrying leaves of a real render on the same runs. A factor of 2 there would have shipped a NEW flake at 7% margin, which is the defect this row exists to remove. It is now an order-of-magnitude backstop with the numbers written beside it. Closes #1565. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [claude-code]
…this row's own that reds 2 runs in 200 A fresh review returned NOT PASS on `ec3e7ac0c` with one blocking finding and four more. All five are repaired here, and one of them is this row failing in its own terms. **F1, blocking. The unit case's ratio assertion was itself load-flaky.** It reddened 2 of 200 consecutive runs at load average 85, and a standalone probe of the same shape reddened 28 of 160 at load 125 and reached 14.1 under `address,undefined`. The mechanism matters more than the numbers, because it refutes what this row's design argued: decomposing the parent's uncovered time shows the UN-instrumented part of a boundary dilating FASTER than the instrumented part when the box slows — gaps of 9-20 us against a 13-22 us charge when fast, 91-105 us against 52-61 us when slow. So a preemption in a gap does NOT inflate both sides together, as §Design.3 claimed. The render's four carrying leaves are far better conditioned (1.02-1.46 over eight measurements) because their boundaries carry a `Tick` and a `/proc/self/statm` read inside the instrumented region, and eight bare scopes carry neither. The ratio is now REPORTED there and not asserted; what that case exists to prove is the attribution, and the mutation that charges everything to the table still reddens four assertions, none of them a ratio. **F6 was one of F1's terms, and fixing it tightens every bound.** `Open`'s flushed progress line runs after the record's start and before any child of it, so it is uncovered time this instrument produces, and it was charged to nobody. It is now charged to the record it is inside. Measured effect on the four carrying leaves: `decode.video` 1.406 to 1.220 and `artifacts.frames` 1.334 to 1.257 on comparable runs. **F3. The claim that (1b') holds the `denoise` pair against a seconds transfer is false, and it is withdrawn rather than defended.** (1b') compares `start_seconds` only. Leaving `denoise.step` open across the post-process and emitting `denoise.update` empty after it preserves the alternation, both counters, containment, non-overlap, exclusivity, (1c) and (2), and moves 100% of the decomposed seconds onto one name. No per-part floor separates it either: the honest share of `denoise.update` runs 0.45% to 11.15% across four boxes and a transfer puts it at ~0%, so a floor would sit inside its own distribution — the defect this row exists to remove. It is recorded under `## Owed`. (1b') also announces itself when it skips, because `equal_counts` is derived from the table it checks. **F2. `WriteJson`'s clock ordering is a reading of the source, not a gated property.** Restoring the old order left the conservation case GREEN 10 of 10, because the copy and sort of a three-record table are nanoseconds. The case is renamed for what it does prove and the claim is recorded as owed, in the shape `phase::Tick`'s own header note already uses for a placement that rests on reading the call site. **F5. "Strictly stricter at every scale" is empirical, not a theorem.** Nothing bounds `leaf_instrument` from above, and moving the DiT `Tick` out of `Evaluate` would charge ~110 flushed writes to `denoise` and buy a budget larger than the floor this row deletes. Recorded as owed with the direction named. **F7.** #1494 was closed by `6b48edb2c` before this branch merged `main`; the spec said this row closed it. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [claude-code]
… and retract the load-flakiness argument the measurement refuted F4 of the fresh review: `## Gates`'s Result column stated what each gate is FOR and `## Outcome` carried no doctest summary, no command, no exit status and no evidence path — which `.agents/verification.md` refuses in terms. `## Outcome` now carries `### The gate report` and `### The mutations`, with the SHA, the command, the environment, the exit status and the evidence path for every run, and with the five mutations attributed to the fresh review that ran them, including the two that are findings rather than passes: mutation E did not red at all, and mutation D reds on one render of two. **And the design's central argument for why the new bound is not load-flaky is retracted rather than defended, in the spec AND at the assertion.** It claimed a preemption inside a gap lands inside an instrument entry point with overwhelming probability, so it inflates both sides together. Measured on a bare micro-timeline, the un-instrumented part dilates FASTER: gaps of 9-20 us against a 13-22 us charge when fast, 91-105 us against 52-61 us when slow. What actually conditions the render-level bounds is that their boundaries carry a `Tick` and a `/proc/self/statm` read inside the instrumented region, so the measured part dominates — and that is an empirical claim scoped to a render, now supported by 20 consecutive runs of the sum bound at 1.021 to 1.464 and eight leaf measurements at 1.02 to 1.46 from two independent measurers, rather than by an argument that turned out to be backwards. `kInstrumentBudget`'s own note now says where the constant may be reached from, because the same review measured 5.55 at load 125 and 14.1 under `address,undefined` at a site whose scopes wrap nothing. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [claude-code]
…n case too, and file the six issues the record owed The fresh review's re-review found F1 surviving one case over. The conservation case still asserted `unaccounted <= kInstrumentBudget * table_charge` on a two-scope micro-timeline — the same worst-conditioned shape the ratio had just been removed from, and for the same reason: two adjacent bare scopes carry no `Tick` and no `/proc/self/statm` read inside the instrumented region, so the un-instrumented remainder of each boundary is a large share and dilates faster than the measured part. Measured at `37f7f9aca`, load average 80: **3 red in 200 consecutive runs**, median 1.525, p90 1.740, max 2.934. That is a HIGHER red rate than the `unit.parent` ratio removed one case up. **And the claim that line made for itself was worth less than it looked.** Its message credited it with catching the uncharged sampler join at a ratio of 3.12, and a 3.12 sits barely outside a distribution whose maximum on an unmutated tree is 2.934 — about 6% of margin, which is a coin flip in both directions rather than a gate. What catches an uncharged interval instead is the table bound over 46 records, where the measured part of each boundary dominates: 20 consecutive runs at 1.021 to 1.464. `kInstrumentBudget` is now reached from those two render-level sites and nowhere else. Two non-ratio assertions replace it and both are new: the table's own charge is positive, so `ChargeLocked`'s `no live leaf` arm is proven to run, and the charge never exceeds the residue it is part of, which is what a charge leaking out of a leaf would break. The six `## Owed` entries are filed: #1567 the res_2s anchor, #1568 the step/update transfer, #1569 the `WriteJson` ordering gate, #1570 a bound on the instrument's own share, #1571 the per-gap decomposition, and #1572, which is NOT this row's — (1c)'s span slack reds intermittently on `main` at 3.4x its bound, from `6b48edb2c`, and this row keeps that assertion's constants exactly as they landed. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [claude-code]
…d review measured red 4 times in 45 A third fresh review measured the replacement bound over 45 consecutive runs of one snapshot binary at load average 88: **4 red, 8.9%**, median 1.132, p90 1.776, **max 4.115**. The 20-run distribution this row recorded, 1.021 to 1.464, is the body of that same distribution and had not run long enough to see its tail. So `residue <= 2 * instrument` was a coin flip at roughly one run in eleven, which is the defect this row exists to remove. It is withdrawn at the last two sites it held, the constant is deleted rather than raised, and this row's stop condition is what says to do that: *"Stop if the measured ratio does not sit near 1, because the bound would then be a constant nobody derived."* **The floors that stay are the tree's own, unedited.** `leaves >= 0.95 * wall` is the line that was red. `denoise_min_coverage` is `6b48edb2c`'s 0.75, and the others are its 0.99, 0.90 and 0.50. Nothing is loosened by this row and nothing is tightened. **They hold because the cause is fixed, which was always the load-bearing half.** 92% of the sum floor's numerator was one un-named region — the load's prologue, 17.661 ms of a 19.178 ms residue — and it does not scale with anything. Named as `load.setup`, `load.dit_config` and `artifacts.mux`, the residue drops by an order of magnitude: **99.961% of wall against a 95% floor**, where the red measured 92.700%. `denoise` coverage moves from **94.221% to 99.939%** because the sampler's per-step update is anchored. **And `wall` in the denominator is better conditioned than `instrument` was**, which is the part this row had backwards. Wall grows with contention exactly when a preemption inflates the residue, so the two move together. The instrument's charge does not: the un-instrumented remainder of a boundary dilates faster than the measured part, which is the mechanism all three reviews found. `instrument_seconds` survives as a REPORTED quantity, emitted per table and per record and printed beside every residue. That is #1439's second option — "bounding `unaccounted_seconds` beside the ratio" — as a number a reader subtracts, rather than as an assertion nobody can keep green. **What this costs is written down rather than glossed.** Mutation D — the `denoise.update` anchor moved off the post-process, 5 of 5 red against the withdrawn bound — is no longer detected, and neither is a future un-named region under 5% of wall. Both are in `## Owed` beside #1570. Three corrections a review asked for are in the same pass: mutation A is labelled a SUBSTITUTE for the promised `## Gates` row rather than that row, its reach is stated with the arithmetic (it would have reddened the OLD floor too at the 0.26271 s baseline wall, and passes it only above 0.447 s), and mutation D's 5-of-5 repeatability is recorded beside its reach. `## Now` is `DONE`, with `build-test-cpu` GREEN on a clean runner at `ec3e7ac0c` and the local `ctest` recorded VOID: test 71 was killed by an external `SIGTERM` at case 26 of 104 with 763 of 763 assertions passing, which is an infrastructure failure presenting as a code verdict and is neither a red nor a green. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [claude-code]
…tion, 30 of 30 green with 13 points of margin The bound this row proposed was withdrawn because 20 runs were not enough to see its tail. Asserting the restored floor on one green run would be the same mistake, so it is measured the same way the withdrawn bound eventually was. Thirty consecutive runs of the SUMS case at load average 89 to 123, every one reporting `cases=1` so the filter cannot be silently empty: **0 red**, `leaves/wall` min **99.6302%**, median 99.9637%, max 99.9901%, against a 95% floor. The worst observation has thirteen points of margin, i.e. the residue would have to grow thirteenfold before it reds, where before this row it sat at 92.700% and under the floor. That margin is the whole difference, and it comes from naming the 17.661 ms region rather than from any number: the floor is the one that was failing, byte for byte. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [claude-code]
…cord defects a review measured **#1439 is not closed by this row and the closing keyword is removed from the pull request body.** Its RED is fixed — the assertion it was filed against passes with 4.5 to 13 points of margin across 76 runs by two measurers — but this branch restores that assertion byte for byte, so its filed complaint is untouched: the budget is a share of `wall`, it decides by box load, and it permits minutes of un-named time at 21 B. The body IS the landed commit message here and closing keywords fire from inside prose, so the claim had to go from both places. What would close it is #1570 plus this row's own negative result. **`### What was rejected` listed the option this row ships.** It rejected "naming the un-named time and keeping the ratio" on the grounds that 95% then leaves 570 ms of headroom and the gate becomes untestable. That used a contended run's 16.2 ms residue on an 11.7 s wall. The residue's measured FLOOR is 0.820 ms, which at the fixture's quiet 0.26271 s wall is 0.31% and leaves 4.69 points of margin, against the original red's 2.30 points OVER. The rejection was wrong. **The `6b48edb2c` reconciliation table was stale in two rows** — the share floor is kept at 0.75 rather than deleted, and the sum gate is restored unedited rather than replaced. **And mutation D's evidence was wrong where its conclusion was right.** "About 94% coverage" was the pre-anchoring quiet-box figure carried across. Measured: under D, `denoise` coverage reads 99.9928% and 99.990%; unmutated on the same head, 99.9963% and 99.980%. The distributions INTERLEAVE — the honest 81-frame render read lower than both mutated runs — which is a stronger basis for "no floor can separate them" than the extrapolation it replaces. The fresh reviewer's own 46-run verification is recorded beside this row's 30: 0 red at load 99-113, min 99.4957%, and the restoration verified byte-exact against the merge base. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [claude-code]
…h factor, which an earlier line fused A fresh review caught "13 points of margin" fusing two different quantities, and it would have landed in git history under a row whose whole subject is a number being quoted until it reads as measured. | | leaves/wall | residue | margin | growth to red | |---|---:|---:|---:|---:| | worst of this row's 30 | 99.6302% | 0.3698% | 4.63 points | 13.5x | | worst of the reviewer's 46 | 99.4957% | 0.5043% | 4.50 points | 9.9x | | the red this row removes | 92.700% | 7.300% | -2.30 points | - | So the worst observation across 76 runs by two measurers is **4.50 points** of margin and a **9.9x** growth in the residue before it reds. Both figures are now in the spec, in `## Owed` and in the pull request body, and neither is stated as the other. Two more things a reader should not have to re-derive are written down. **The gate's SHA is not the head's SHA**: `build-test-cpu` ran at `65e681438` and every commit since touches only this spec file, so the verdict transfers by construction rather than by assertion. And **the `ec3e7ac0c` green is narrower than it looks** — its job succeeded inside a run whose own conclusion is `cancelled`, and that SHA still carried the withdrawn bound, so it covers a different assertion set from the one landing. The local `ctest` row now records that it was STOPPED at 482 of 584 rather than that it merely ended: the box had ~1 GB free with swap full, this target has been kernel-OOM-killed on it three times, and no `ctest` TIMEOUT is configured, so the 796 s kill was external rather than a timeout. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [claude-code]
…e this floor is weakest in Every number this row had for the restored floor came from a box at load 89 to 123, and that is the SAFE side of it. The polarity is the one #1439 recorded: a slower render passes, because `wall` is the denominator. So a contended box flatters this gate, and the regime that decides it is a quiet box with a small wall — which is what CI is, and which nothing here had measured. The box fell to load average 11 for the first time in this row's life. Fifteen consecutive runs there: **0 red**, min `leaves/wall` **99.7947%** — 4.79 points of margin — median 99.9582%, over walls of **0.809 to 4.588 s**. The load-bearing observation is in the residue rather than the ratio: **it does not scale with wall.** 0.896 to 4.221 ms over walls of 0.8 to 4.6 s here, and 0.820 ms at its floor over walls of 10 to 120 s under load. So the share is worst at the smallest wall, and 0.809 s is three times closer to the 0.26271 s baseline than anything measured before. Carried to that baseline a ~1 ms residue is 0.38%, i.e. 99.62% and **4.62 points of margin**, against the 19.178 ms that put the original 2.30 points UNDER the floor. A fresh reviewer's independent verification of the SHA transfer is recorded beside it: `git diff --stat 65e6814 HEAD -- src include tests` is empty, and a rebuild at the head reproduced the gated binary byte for byte, sha256 `579cde5aa0a6…`, with the focused gate matching at 1382 assertions. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [claude-code]
… both sides appended before it `origin/main` moved 32 files under this branch while it was in review. Thirty-one of them merge as a one-side take: every path in the merged tree is byte-for-byte equal to one parent, verified by intersecting `git diff --name-only` against each parent, and the intersection is `.agents/issue-index.md` alone. The row's own C++ -- `src/vllm/multimodal/ltx2_video.cpp`, `src/vllm/multimodal/render_phase_log.cpp`, their headers and `tests/vllm/multimodal/test_ltx2_video.cpp` -- is unchanged from the reviewed head `5851581ad`, so the fresh review at `afe8e7383` and the green CI run 32472406907 both still describe the code that lands. `.agents/issue-index.md` is the one real merge, and `merge=union` resolved it WRONG. Neither side appended at the true end of the file. Both inserted their rows immediately before the same trailing anchor, `#1546`, so the two appends overlapped rather than sitting side by side. The union driver concatenated both conflicting regions, and each region carried that anchor, so the resolved file held `#1546` TWICE -- byte-for-byte identical, at two line numbers. Nothing went red: the file grew by 17 lines where both sides added 8, and no gate counts rows. That is `AGENTS.md`'s rule about keyed records arriving as a measurement. A clean automatic merge of a keyed record is not evidence the record is right, and a duplicated row is worse than a conflict here, because GitHub holds the open and closed state and a row that appears twice has two of them. De-duplicating in place was not enough either, and `check-issue-index-append-only.py` caught the second defect the first fix left. Deleting the later copy leaves `#1546` ahead of `origin/main`'s three new rows instead of behind them, which is a RELOCATION, and a line diff reads a relocation as a removal. The gate was right and the first resolution was wrong. Resolved as the rule states instead: `origin/main`'s file byte-for-byte, then this branch's eight rows appended at its true end. `git diff --numstat origin/main` is `8 0`, additions only, which is what append-only means in a form a gate can read. Both sides' rows survive, every row appears exactly once, 519 rows total, checked against base, main and branch by multiplicity rather than by eye. Appending at the true end is what keeps the union driver correct. Inserting before a trailing anchor is what made two clean appends collide, and this merge does not move either side's rows to say so. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [claude-code]
…bound, and delete the paragraph that still described this row's withdrawn one `origin/main` moved to `f4ccabbb4` and `f38cd69e7` (#1582) rewrote the same region of `tests/vllm/multimodal/test_ltx2_video.cpp` that this branch touched. Only one hunk conflicted and BOTH SIDES OF IT ARE COMMENT LINES, which was asserted programmatically rather than read off the diff: the resolution script refuses if either side carries a non-comment line. **The two sides had already converged on the same assertion.** `65e681438` withdrew this row's `residue <= 2 * instrument` bound after a third review measured it red 4 times in 45, so this branch ends at `covered >= c.min_coverage * leaf_seconds` -- the tree's own share floor, unedited. That is exactly what `main` carries. The conflict was therefore two descriptions of one line, and `main`'s is the one that describes it correctly. **So the whole `(2) COVERAGE` comment is restored to `main`'s bytes.** The paragraph the auto-merge kept was this branch's, and it was stale on this branch's own head: it says the share floor "is DELETED rather than moved again" and that "the line below permits twice an instrument charge", two lines above a `CHECK_MESSAGE` that keeps the floor and a `MESSAGE` that prints the instrument ratio as "REPORTED not asserted". It also contradicted the paragraph directly under it, which `main` had rewritten to say "NOTHING WAS DELETED to get here". That paragraph auto-merged WITHOUT a conflict, so nothing in the merge machinery would have caught it. The PR body already states the correct position -- the bound is withdrawn, the floors are the tree's own -- so this only brings the file into line with the body. **`main`'s span-slack repair is taken whole.** `f38cd69e7` replaced the summed bound and its sanitizer-conditional constant with a per-record 30 ms bound that skips records below its own resolution. That region auto-merged because this branch never changed it. Verified by stripping comments from both files and diffing: every remaining code delta against this branch's head belongs to that repair, and the merge introduces no line neither parent carried. `.agents/issue-index.md` merged as a pure union-append, checked by multiset against both parents: no parent line dropped, altered, or invented. 538 and 539 lines in, 547 out. `test_ltx2_video` is NOT run here. It reaches 30-36 GB of anon-RSS and this box is at load 31, which is the regime its own load-sensitive assertions are weakest in. The CI lane is the gate for this merge. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [claude-code]
Collaborator
Author
The
|
…use TWO other changes landed it first and the merge kept all three `origin/main` reached `13548db8f` and the `::getpid()` defect this branch also repaired is now fixed there **twice**. `d27639e71` (#1498, a Tenstorrent decode fix) added `#include <unistd.h>` to `tests/vllm/models/test_qwen3_dflash2_gguf.cpp`, and `13548db8f` (#1581) routed the call through the `tests/support/process_id.h` seam. Three sessions repaired one defect under two issue numbers, #1565 and #1575. **The merge produced a file with `<unistd.h>` twice and no conflict.** This branch's include sits in a different part of the include block from `main`'s, so git auto-merged both and nothing warned. That is the silent shape: a conflict is visible and a clean automerge of two repairs for one defect is not. So this branch takes `main`'s version of that file **whole**. Its only change to it was `118c8adae`'s include, verified by `git log e2a9e03..HEAD -- <file>` returning that one commit, and the file is now byte-identical to `origin/main` (`git diff origin/main -- <file>` is empty). The bare `<unistd.h>` is exactly the copy-forward idiom the seam exists to centralise, and #1581's review measured the seam repair in the lane's own `gcc:16` container, so the seam is the version that should survive. Nothing is lost: `build-newest-gcc` is repaired on `main` and this branch inherits it. `Closes #1565` is therefore no longer this branch's to claim and comes out of the PR body in the same step. `.agents/issue-index.md` merged as a pure union-append, checked by multiset against both parents: 547 and 547 lines in, 555 out, no parent line dropped, altered or invented. `tests/vllm/multimodal/test_ltx2_video.cpp` is untouched by this merge. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [claude-code]
…he redundant include this branch had also dropped `main` moved twice while this branch was being reconciled. `13548db8f` (#1581) landed the `tests/support/process_id.h` seam and `369a0c2aa` (#1618) then dropped the bare `#include <unistd.h>` that #1498 had added for the same defect, so the file is back to one repair. This branch already held `main`'s version of it whole, and `git diff origin/main -- tests/vllm/models/test_qwen3_dflash2_gguf.cpp` is still empty after this merge. The merge is taken so `check-commit-style` and `check-commit-trailers` can RUN: both refuse a range whose base is not an ancestor of its head, and a moved `origin/main` turns them into SKIPs rather than passes. `.agents/issue-index.md` was the only file both sides touched and merged as a pure union-append, checked by multiset against both parents -- 555 and 549 lines in, 557 out, no parent line dropped, altered or invented. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [claude-code]
Collaborator
Author
Reconciled onto
|
…de false, and one of them says this row closed #1439 These three edits are the records the merges of `origin/main` invalidated, and nothing else. No file under `src/`, `include/` or `tests/` moves. **`ltx25-device-residency.md` recorded #1439 as CLOSED by this row.** It said the row "did BOTH" halves of what the issue asks and that "the ratio is gone rather than retuned". Neither is true. `CHECK(leaves >= 0.95 * wall)` is still the assertion, restored byte-for-byte when `65e681438` withdrew the replacement this row proposed -- `residue <= 2 * instrument` -- after a third fresh review measured it red 4 times in 45 consecutive runs at load 88, median 1.132, max 4.115. That row was written by `d504b2b89` while the bound was still asserted and never caught up. It now says the issue is still owed and points at #1570, which agrees with this row's own spec, with the pull request body, and with `f38cd69e7`'s message: "#1439 stays untouched and is still owed the same thing this bound is: a name on the un-named time." **This row's own spec claimed the gate transferred across the merges.** It said every commit between `65e681438` and the head "touches `.agents/specs/ltx25-phase-residue.md` and nothing else, so no C++ gate reads a byte that moved". The merges brought `f38cd69e7`, which rewrites assertion (1c) in this row's own test file, so the argument no longer reaches. It is withdrawn rather than patched: the head is gated on its own `build-test-cpu`, and what survives is the narrower checkable claim that `git diff 5851581 HEAD -- src/vllm/multimodal include/vllm/multimodal` is empty. **#1619 is filed and recorded.** `.agents/issue-index.md` carries `merge=union`, and that driver is only safe while rows are appended at the TRUE END of the file. Both sides of this row's first merge appended before the same trailing anchor instead, so the driver concatenated two regions that each carried `#1546` and the resolved index held it twice, byte-identical, at 538 lines where the correct union is 537. `git merge-tree` called that merge clean, `check-agent-record.py` passed it, and `check-issue-index-append-only.py` passed it too, because a duplicate is an ADDITION and that checker only collects removals. De-duplicating in place then FAILS the same checker, because moving the anchor back behind the other side's rows is a relocation and a line diff reads a relocation as a removal. So the gate that exists reds a correct repair while the corruption passes it. The driver dropped `#838` on a later re-merge of this same branch, so it recurs rather than being one accident. Not fixed here, because it changes checker semantics, which `AGENTS.md` routes through a row, a spec and a red-before mutation. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [claude-code]
…is row proposed, not the ones it is landing A fresh review proved by mutation that the merge resolution is correct: deleting this row's `denoise.update` Scope reds the gate at `test_ltx2_video.cpp:3714` and `:3738`, and mutating main's `(1c)` constant `kSpanSlackPerRecord` from 0.03 to 1e-5 reds 15 assertions at `:4172`. The two colliding changes compose. What does not compose is the PROSE, which still argues for the bound this row withdrew and for a floor it did not remove. No predicate, constant or call site moves here. **(2)'s population predates the anchor this row landed.** The comment recites 99.28% down to 88.85% at nine frames and 85.85% to 97.09% at 81 "all on an unchanged `denoise`", then concludes that "a 0.95 floor is therefore BELOW half of its own honest distribution". That was true of the leaf as `6b48edb2c` measured it. `denoise.update` is the reason it is not true now: on the merged tree `denoise` carries SIXTEEN sub-scopes rather than eight, and five runs across two sessions read 99.5981% to 99.9915% over both arms -- the worst of them 4.60 points ABOVE the 0.95 the recited distribution straddled. So the paragraph was justifying the 0.75 constant beneath it with numbers this row's own anchor invalidated. The population is kept and marked as the pre-anchor one, because it is what argued the constant down; the current measurement is recorded beside it, and the constant stays at 0.75 with the reason stated rather than implied. **Two of the three paragraphs about the withdrawn share bound said it was gone.** `:4524` said the share floor "is gone rather than moved a third time" and `:4527-4530` said "what (2) asserts now is the leaf's uncovered seconds against the instrument's OWN measured charge". Neither is what the file does. `:4223` is `CHECK_MESSAGE(covered >= c.min_coverage * leaf_seconds, ...)`, the parameter carries 0.75 at three call sites, and the uncovered-over-instrument ratio prints `", REPORTED not asserted)"`. That contradicted the merged block's own `NOTHING WAS DELETED to get here` eleven lines above it -- the merge repaired one twin and its subject says "delete the paragraph", singular. The third claim, that `denoise_min_coverage` "is gone rather than retuned", is false the same way: it is still declared, still forwarded, and what went is the per-geometry TUNING. **The sum case says its own floor was replaced, four lines above the line that still reads it.** `:3289` said "THIS LINE READ `leaves >= 0.95 * wall`" and "Row LTX25-PHASE-RESIDUE replaced it"; `:3306` said "WHAT IS ASSERTED NOW". The CHECK at `:3363` reads exactly that, and `:3333` says so outright. Worse, the replaced-it paragraph argued that a share of `wall` is the wrong quantity while the paragraph at `:3352` records the measured opposite -- `wall` is the better-conditioned denominator, because it grows with contention exactly when a preemption inflates the residue. Both are now stated as what this row PROPOSED and WITHDREW, and what changed is named as the numerator. **`byte-for-byte` overstates the restoration in three records.** The predicate and the 0.95 are restored; the failure MESSAGE is not, because it now reports the instrument's charge beside the two seconds figures. "Restored unchanged -- same predicate, same 0.95, message only" is the exact claim, and it is what `ltx25-device-residency.md`'s #1439 row, this row's spec `## Owed` entry and its withdrawal table now make. Focused gate on this tree, x86_64, empty `CMAKE_BUILD_TYPE`, load average 14: `./build/tests/test_ltx2_video -s -tc='<the four cases this row owns>'` exits 0 with `4 cases | 4 passed | 0 failed` and `1394 assertions | 0 failed`, matching the review's baseline on the pre-repair head exactly. The count is NOT quoted as a stable property: it is constant-dependent, and the rise from 1382 is main's new `REQUIRE(c.min_coverage >= 0.5)` firing 12 times. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [claude-code]
…his row's nine index rows at the file's TRUE end `origin/main` moved TEN commits under this branch while the prose repair above was written, two of them between reading the ref and merging it -- so the merge names the parent it actually took, `c020347a7`, and not the tip a `git log` reported one command earlier. Nothing in the incoming range touches `tests/vllm/multimodal/test_ltx2_video.cpp`, `src/vllm/multimodal` or `include/vllm/multimodal`, so the focused gate this branch just ran still covers the assertions that are landing. **`.agents/issue-index.md` is resolved canonically rather than by the union driver, which is the defect #1619 records and which this branch has now hit twice.** The driver's own output was clean and additions-only, but it left this row's nine appends BEFORE main's three newest, so `#1619` sat at line 558 with `#1613`, `#1614` and `#1502` after it. That is the exact shape that makes the NEXT merge duplicate a row: two branches then append before different trailing anchors and the driver concatenates both regions. So the file is rebuilt as `origin/main`'s copy byte-for-byte with this row's nine rows re-appended at the true end, and the result is checked the way #1619 says to check it: `git diff --numstat origin/main -- .agents/issue-index.md` is `9 0`, and `grep -oP '^\| \[#\d+\]' | sort | uniq -d` is empty over 543 rows. The nine are `#1470`, `#1536`, `#1567` through `#1572`, and `#1619`. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [claude-code]
…his row's nine index rows at the file's TRUE end `origin/main` moved four more commits while this head's own CI ran, and GitHub reported the pull request `CONFLICTING` before it could be merged. Nothing in the incoming range touches `tests/vllm/multimodal`, `src/vllm/multimodal` or `include/vllm/multimodal` -- `git diff c020347 origin/main` over those three paths is empty -- so the focused gate this branch ran at `4ad719b26` still covers every assertion that is landing. `.agents/issue-index.md` is resolved the same way as the previous merge, and for the same reason: the union driver's own output is clean and additions-only, but it leaves this row's appends BEFORE main's newest rows, which is the shape #1619 records as the cause of a silent duplicate on the NEXT merge. The file is rebuilt as `origin/main`'s copy byte-for-byte with this row's nine rows re-appended at the true end. `git diff --numstat origin/main -- .agents/issue-index.md` is `9 0` and `grep -oP '^\| \[#\d+\]' | sort | uniq -d` is empty. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [claude-code]
localai-bot
pushed a commit
that referenced
this pull request
Aug 22, 2026
…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]
Collaborator
Author
|
Closing this. The work was correct and it was overtaken — this is not a rejection on the merits, and nothing here failed a review. What superseded it
Same repair, twice. Why it could not simply be merged
Reworking the body and the 809-line spec around what the change actually is now, on a branch that conflicts in three files, is a fresh row's work with its own red-first tests and its own fresh review. That is what it has been given. What was salvaged, and where it wentThe record landed in full, as #1670: Two things in there were worth more than the anchors and would have been lost:
The implementation is owed under #1668, owned by the So the supersession covers one anchor, not this branch. Three anchors, a ~193-line change to shared instrument semantics and 583 lines of test are still genuinely new. What was dropped
Nothing is lost and nothing is blockedThe reference implementation, the full gate report, the mutation table and the three review threads stay readable at Neither red this branch was filed against reproduces on Four claims in this branch's spec did not survive re-checkingRecorded here because the record PR corrects them and anyone reading this branch later should not re-inherit them:
The Thanks to everyone who reviewed this three times. The measurements are the part that mattered, and they are the part being kept. |
localai-bot
pushed a commit
that referenced
this pull request
Aug 22, 2026
…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]
localai-bot
added a commit
that referenced
this pull request
Aug 22, 2026
… request, and ten open issues had no index row (#1670) 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 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 ``` 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 5539686 3d6a0a4` 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 d25730f b3761b9 -- src include tests examples [empty] git diff --stat d25730f b3761b9 .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] --------- Co-authored-by: Ettore Di Giacinto <mudler@localai.io>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
test_ltx2_videowas the only failing test onmainand had been red for daysunder a "known-flaky" label its own measurements refute. Three assertions failed
across two cases, and both are wall-clock RATIOS:
Neither number is edited here. Both floors land exactly as the tree already
had them. What changes is what they are measuring.
What nobody had measured
unaccounted_secondswas known as an aggregate, and four issues across threemonths argued about whether 0.95 was the right tolerance for it. Splitting it
into the gaps between consecutive leaves took one pass over the table the render
already writes:
<origin>→load.ditload.dit→load.video_vaeload.prompt_embeds→generate.setupartifacts.audio→WriteJson92% of the un-named time is one region:
Ltx2VideoEngine::Loadfrom thetimeline's origin to
Open("load.dit")— the platform probe, the deviceresolution, the recipe and checkpoint-class resolution, and
SafetensorsFile::Open(params.dit_path). The sixteen gaps between adjacent namedphases hold 6.8 us each, which is the instrument and nothing else. That also
refutes the hypothesis #1536 asked to test first:
d995c52f0's temporal x2upsampler runs inside
phase.upsample_latent, a named leaf, and does not appearin the residue at all.
The coverage miss is the same defect one level down.
denoisemisses by 49 usper step at nine frames and 343 us per step at 81 — a 7x move with the latent
inside one run of one binary, so it is work rather than overhead. It is the
sampler's post-process and Euler step, which the case's own comment already named
and left un-anchored while tuning a threshold around it.
What this lands
load.setup,load.dit_configand
artifacts.mux.denoise.update, counted byLtx2ConditioningTrace::sampler_updatesso the containment gate's recordcount still comes from a number the phase table cannot move.
PhaseLogmeasures its own cost and emits it per record and per table, soa reader can subtract instrument overhead before calling a residue a phase
nobody named. That is The LTX-2.5 phase-table SUM gate's 95% floor sits inside its own measurement, and it is RED on main #1439's second option — "bounding
unaccounted_secondsbeside the ratio" — and it is the normaliser
6b48edb2crecords as missing.that
denoiseis the first leaf with two REPEATING parts.Measured on the landing tree, against floors nobody edited:
leaves / walldenoisecoverage, 9 framesdenoisecoverage, 81 framesAnd the sum floor is measured as a distribution rather than as one green run —
30 consecutive runs at load average 89 to 123, 0 red,
leaves/wallmin99.6302%, median 99.9637%, max 99.9901%. The worst of those has 4.63
points of margin, i.e. the residue would have to grow 13.5x before it reds,
where before this branch it sat 2.30 points under the floor. A point margin
and a growth factor are different numbers and are kept apart here.
The bound this branch proposed, and why it is not here
This branch first replaced both ratios with
residue <= 2 * instrument, derivedfrom the instrument's own measured cost so that it would say the same thing at
64x64x9 and at 3840x2160x241. Three fresh reviews measured that and it is
wrong. The un-instrumented remainder of a boundary dilates FASTER than the
instrumented part under contention, so the comparison has a heavy right tail:
unit.parentcase, load 85A 20-run distribution reading 1.021 to 1.464 was the body of the first of those
and saw none of its tail. The bound is withdrawn at all three sites and the
constant is deleted rather than raised — this branch's own stop condition, and
#1466's rule.
wallin the denominator turns out to be the better-conditioneddenominator, because wall grows with contention exactly when a preemption
inflates the residue.
What that costs is recorded, not glossed. Mutation D — the
denoise.updateanchor moved off the post-process, 5 of 5 red against the withdrawn bound — is no
longer detected, and neither is a future un-named region under 5% of wall. Both
are in the spec's
## Owedbeside #1570.Reconciled with
6b48edb2c, which landed mid-flightThat change repairs the same
denoisered by a different route: it moved theshare floor from 0.95 and 0.90 to 0.75 and added assertion (1c). Its own comment
says that was a holding action, in terms:
This branch is that owed work. Assertion (1c) is kept exactly as it landed,
constants and all, and the 0.75 floor is kept too — this branch neither
loosens nor tightens it. Its measured population is kept verbatim: an unchanged
denoisereads 99.55% down to 88.85% across four boxes including the GitHubrunner, so eleven points of a leaf were un-anchored work and no threshold could
have separated that from a swallowed phase.
One repair that was not this row's, and is no longer here at all
build-newest-gcchad failed at the Build step on every commit since5702d8f83—test_qwen3_dflash2_gguf.cppcalls::getpid()with no<unistd.h>— so that lane reported nothing about any pull request based onmain. This branch repaired it because it is the lane that reports on this one,and filed it as #1565.
Two other changes repaired the same defect first, and this branch's copy is
withdrawn.
d27639e71(#1498, a Tenstorrent decode fix) added the bare#include <unistd.h>, and13548db8f(#1581) routed the call through theexisting
tests/support/process_id.hseam under a second issue for the onedefect, #1575. Merging
mainhere produced a file carrying<unistd.h>twicewith no conflict, because this branch's include sits in a different part of
the include block: a clean automerge of two repairs for one defect, which is the
shape nothing warns about.
So this branch takes
main's version of that file whole and is now byte-identicalto it there. #1581's review measured the seam repair in the lane's own
gcc:16container, so the seam is the version that should survive; the bare include is the
copy-forward idiom the seam exists to centralise. #1565 is a duplicate of #1575
and is not this branch's to close.
Evidence
Red before, at base
67823aee2, CI configuration, x86_64:And the fast end is measured, not extrapolated. This floor's polarity is
"a slower render passes", so every number above comes from the safe side of a
contended box. On a quiet box — load average 11 to 26, the regime CI runs in —
15 consecutive runs give 0 red, min
leaves/wall99.7947%, over walls of0.809 to 4.588 s. The residue does not scale with wall (0.896-4.221 ms here,
0.820 ms at its floor over 10-120 s walls), so the share is worst at the smallest
wall; carried to the 0.26271 s baseline that is 0.38%, i.e. 99.62% and 4.62
points of margin, against the 19.178 ms that put the original 2.30 points
under.
The sum floor was also verified independently by a fresh reviewer: 46
consecutive runs at load 99-113, 0 red, min 99.4957%, and a measured
residue FLOOR of 0.820 ms, which at the fixture's quiet 0.26271 s wall is
0.31% and leaves 4.69 points of margin — so it holds at the fast end too.
That reviewer also verified the restoration against the merge base: identical
predicates and constants, only
MESSAGEtext differs. "Byte for byte" was thephrase three records used for that and it overstates it by exactly one string,
so all three now say "restored unchanged — same predicate, same 0.95, message
only".
build-test-cpu— the lane this test was red in, runningctest --test-dir build --output-on-failureover all 584 tests on a cleanrunner — no longer fails on this test.
main's baseline ate2a9e035dbf8fails two,
71 - test_ltx2_videoand280 - test_runner; this branch fails only280 - test_runner, withtest_ltx2_videopassing in 261.12 s.test_runnerisa live
mainred owned elsewhere and filed twice, as #1602 and #1608: theattention-backend selector refuses a non-multiple-of-16 block size before
CheckKvCacheShapecan, so the case asserts a message only a ROCm/FLASH_ATTNbuild produces. Both
sanitize-cpulanes fail on that one test and nothing else,on this branch and on the baseline alike — read per job, because
sanitize-cpuis
continue-on-errorand a run's own conclusion can say success while it is red(#274). The full gate report, the mutations
(including the two that are findings rather than passes) and six
## Owedentries filed as #1567 to #1572 are in
.agents/specs/ltx25-phase-residue.md.The merges composed, and the PROSE around them did not
A fresh review measured the merge resolution rather than reading it, and it
holds. Line numbers in this section are the reviewed head
2322320b1, whichthe prose repair below then moved — cite the symbols, not the anchors. Deleting
this row's own anchor, the
denoise.updateScope atltx2_video.cpp:4516, redsthe gate at
test_ltx2_video.cpp:3714and:3738; mutatingmain's(1c)constant
kSpanSlackPerRecordfrom 0.03 to 1e-5 at:4054reds 15 assertions at:4172. The two changes bound different quantities and both are live. The issue index is clean by the same standard:additions-only against both parents at every merge, zero duplicate ids.
Four comments were still describing the assertions this row PROPOSED. They
are repaired here, and no predicate, constant or call site moves:
denoise.update. The comment recited99.28% down to 88.85% "all on an unchanged
denoise" and concluded that a0.95 floor "is therefore BELOW half of its own honest distribution" — then
used that to justify the 0.75 below it.
denoise.updateis the reason it isno longer true:
denoisenow carries sixteen sub-scopes rather thaneight, and five runs across two sessions read 99.5981% to 99.9915% over
both arms, the worst of them 4.60 points ABOVE the 0.95 that distribution
straddled. The population is kept and marked as the pre-anchor one, the
current measurement is recorded beside it, and the constant stays at 0.75
with the reason stated rather than implied.
gone. They read "the share floor is gone rather than moved a third time"
and "what (2) asserts now is the leaf's uncovered seconds against the
instrument's OWN measured charge". Neither is what the file does: (2) is
CHECK_MESSAGE(covered >= c.min_coverage * leaf_seconds, ...), the ratioprints
", REPORTED not asserted)", and the same block saysNOTHING WAS DELETED to get hereeleven lines above. The merge repaired onetwin — its subject says "delete the paragraph", singular.
denoise_min_coverage"is gone rather than retuned" is false the sameway. It is still declared, still forwarded, and carries 0.75 at three call
sites. What went is the per-geometry TUNING.
line that still reads it — and argued that a share of
wallis the wrongquantity, which the paragraph 60 lines below records as measured backwards.
Both are now stated as what this row proposed and withdrew.
Gate on the merged head, x86_64, empty
CMAKE_BUILD_TYPE, the four casesthis row owns: exit 0,
4 cases | 4 passed | 0 failed,1396 assertions | 0 failed. That count is not quoted as a stable property.It read 1394 on the pre-repair head, 1396 after ten more commits of
main, anda mutation moved it to 1402; the rise from this row's own 1382 is
main's newREQUIRE(c.min_coverage >= 0.5)firing 12 times, and the(1c)rewrite is netzero at 24 against 24.
Re-verified on the merged head, per job
build-test-cpu, job96878999048on4ad719b26: 585 tests, one failure,281 - test_runnerattest_runner.cpp:1557, and71 - test_ltx2_videopassed in 258.96 s. The
mainbaseline at503e45900(job96843011361)fails that same single test at that same line with a byte-identical message, so
it is inherited and it is #1602 / #1608.
Two
mainbaselines four hours apart show the case is still load-decided onmain, which is the point of this row rather than a caveat on it. Ate2a9e035dbf8(job96780519452)test_ltx2_videoFAILED onCHECK( leaves >= 0.95 * wall )withwall=0.739941s unaccounted=0.037592s— a5.08% residue, i.e. the
load.setupprologue this branch names. At503e45900it passed.6b48edb2c's floor is in both. One green run does notclose a gate that decides by box load.
build-newest-gccis green on this head, having been red on both of thosebaselines; #1581's seam repair came in with the merge.
windows-msvc-cpuandwindows-msvc-vulkanfail onERROR: CMakeLists.txt: MSVC /W4 /WX policy is negated on the C/C++ compile by /w— not the0xC0000409signature of #584 — and the same line, byte forbyte, is on both
mainbaselines. Inherited, and a standingmainred in thelanes #503 / #646 / #965 already track.
What this does NOT close, and why the keyword is absent
#1439 stays open. Its RED is fixed — the assertion it was filed against
passes with 4.50 to 4.63 points of margin, equivalently a 9.9x to 13.5x
growth in the residue before it reds, across 76 runs by two measurers — but this
branch restores that assertion unchanged — same predicate, same 0.95, with
only the failure MESSAGE differing, because it now reports the instrument's
charge beside the two seconds figures — so its filed complaint is untouched: the budget is a share of
wall, it decides by box load, and itpermits minutes of un-named time at 21 B. Putting a closing keyword in front of
that number here would close an issue whose subject nobody has repaired — and in
this repository such a keyword fires from inside prose, while the body becomes
the commit message, so it is left out deliberately rather than forgotten. What would close
it is a bound on a quantity the scheduler cannot move — #1570, plus this branch's
own negative result.
Closes #1536. Closes #1470.
FOLLOWING_AGENTS_PROTOCOL
Following-Agents-Protocol: true
AI-Assisted: true
Assisted-by: AGENT:claude-opus-5 [claude-code]