record(LTX25-DEVICE-RESIDENCY): the span-slack bound's fifth and sixth shapes, both MEASURED and both WITHDRAWN (#1727, #1728)

[localai-bot]

Nothing here touches assertion (1c). tests/vllm/multimodal/test_ltx2_video.cpp is byte-identical to main, #1572, #1576 and #1536 stay open, and the bound still carries the fourth shape's flat 30 ms constant. What lands is the record of two further shapes that were built, measured and withdrawn, so that the next person does not build them again.

That is a reversal of what this pull request set out to do. The reason is in the numbers below.

Four shapes, and what each one is measured to do

shape	denominator	how it fails	measured
4th, on main	a flat 30 ms per leaf record	reds an unmutated tree under load, and cannot resolve artifacts.frames at all	#1576, 171x on one binary
5th	4 x the WORST boundary a 1 kHz sampler saw across the WHOLE case	one scheduling event on the sampler thread multiplies the bound by ~100 and silences a real 20 ms un-named phase	a fresh review: the defect reds 9/9 alone, 0/4 with one 200 ms sampler stall, whole case GREEN 2/4
6th	4 x the worst boundary inside the RECORD'S OWN window	too tight -- the honest span slack's tail exceeds it	5 red in 45 consecutive runs of the unmutated case on that mechanism, loadavg 21.8-61.5 (10 in total; see below)
next	red only when the SAME leaf exceeds it in BOTH renders	untried	recorded, not attempted

The fifth shape: right derivation, wrong estimator

A fresh review confirmed the derivation operation-by-operation against render_phase_log.cpp: Open takes the mutex, stamps, samples and flushes a line; Close takes the same mutex, samples, then stamps and flushes. Head plus tail really is two boundary-sized operations and 2 x ceiling really is what the structure gives.

The estimator is what fails. Read over the whole case, that maximum is drawn from 3,764 to 27,975 draws while the numerator it bounds is a maximum over TWO, and maxima do not compare across sample sizes. Over 24 unmutated runs the sampler's MEDIAN operation measured 18.4-22.9 us -- stable to 1.24x across loadavg 25 to 82 -- and its MAXIMUM 47x to 785x that median.

arm	what it stages	(1c) red	case verdict
C20	a 20 ms un-named phase in decode.audio's head	9 of 9	red 9 of 9
C20D2	the SAME defect + ONE 200 ms descheduling of the sampler thread	0 of 4	GREEN 2 of 4, bound 0.800 s

A real un-named phase, no assertion fires, and the only thing that made it pass is a scheduling event on a sleeping background thread.

The same review found the skip path was a permanent report-only state, which AGENTS.md ## Gates refuses in as many words: span_checked was computed, printed and asserted nowhere, and CI runs ctest --output-on-failure, so on a green run nobody ever sees it. Four CheckCarryingPhase calls reported 1 of 1, 0 of 2, 0 of 1, 0 of 1 while the case exited Status: SUCCESS! with the 20 ms defect present.

The sixth shape: better detection, and it reds an unmutated tree

Each draw stamped with PhaseLog::Elapsed(), and a record's bound reading only the draws inside that record. It is a strict tightening, and it detects better than anything before it:

mutation	30 ms constant	5th shape	6th shape
2 ms un-named head in decode.audio	0 of 4	1 of 4	3 of 3
15 ms un-named head in decode.video	0 of 4	5 of 5	3 of 3
20 ms + a 200 ms sampler stall	--	0 of 4	3 of 3

artifacts.frames -- the leaf #1470 is about, 0.9 to 61 ms, which no previous shape could resolve at all -- came out bounded at 71.9 us.

And then it was validated the way this cluster's own rule demands. 45 consecutive runs of the containment case, one pinned binary (sha256 242c7925...), an unmutated tree, loadavg 21.78 to 61.52, every run's counts recorded:

45 runs   35 green   10 RED

The headline 10 is not the red rate of the shape's final form, and the honest figure is 5. Two mechanisms produced those ten, and the second was identified and repaired while the population was still running -- so its nine reds were measured on a binary that predates its own repair, and that repair was never re-validated. 11%, five reds in 45, is the defensible number, against a measured 1 red in 120 (0.83%) for what is on main. It is 13x, it is decided by the same mechanism at any multiplier, and it is what the withdrawal rests on. The nine are reported rather than dropped, because a population that reports only its surviving mechanism is an argument and not a measurement.

assertion	reds	what happened
span_slack <= span_bound	5	the honest head-and-tail exceeded 4 x the record's own local worst boundary: decode.audio 13.115 ms vs 8.889 ms, decode.video 0.488 ms vs 0.374 ms, artifacts.frames 70.6 us vs 60.6 us
longest_checked	9	a leaf's longest record was not resolvable, most often artifacts.frames at ~1 ms with no draw of a 1 kHz sampler inside it

The second was repaired mid-flight -- a record shorter than the sampler's cadence takes the worst of the draws bracketing it. The first is not repairable by choosing a different denominator, and it is the same mechanism .agents/specs/ltx25-phase-residue.md ## Design 3 records for the withdrawn residue bound: the part of a boundary the instrument cannot measure -- the lock_guard release, the Close return, the Scope destructor and constructor, the call into Open up to its clock read -- dilates faster under contention than the part it can. It sits in the numerator and in no denominator a sampler can build.

Raising the multiplier would be repairing a red gate by widening it, which AGENTS.md ## Changing the rules or a checker refuses in as many words. (#1668 is not cited for that and does not say it; what it says, quoting this file's own comment, is that naming the un-named time would settle it properly -- the repair is an ANCHOR, not a threshold, which points the same way by a different route.) So both shapes are withdrawn.

The next traceable hypothesis, which this row does NOT take

A defect is REPRODUCIBLE within a run and a scheduling event is not. The fixture renders the same three carrying leaves TWICE. A bound that reds only when the SAME leaf exceeds it in BOTH renders would keep every detection measured above -- the injected sleeps run on every pass -- while dropping every red measured here: in all five span-slack reds the failing leaf exceeded the bound in exactly one render.

Its cost is named before anybody builds it: requiring both renders silences any real defect present in only ONE of them -- a first-render lazy allocation, a cold-cache path, anything the second pass warms. On this fixture the three carrying leaves run the same code on both passes, which is why the staged sleeps red 3 of 3, but that is a property of the fixture and not of the assertion.

That is a different assertion with a different failure mode. It owes its own red-first evidence, its own mutation set, its own 45-run validation, and a mutation present in render 1 alone. Attempting a fourth shape in the same session that refuted the second and third is how this cluster got four constants in the first place.

Issues

Closes nothing. #1572, #1576, #1536, #1470 and #1439 all stay open, and #1536's thesis is not refuted here either -- that claim depended on the fifth shape landing.

Filed by the fresh review and left open as constraints on any re-proposal, each owned by this row's spec ## Owed:

• (1c)'s boundary sampler carries three terms and the gate can falsify only one: deleting the flushed write leaves the estimator inside its own noise #1727 -- two of the boundary sampler's three terms are unfalsifiable by a gate (deleting the flushed write leaves the estimator inside its own noise, green 3 of 3), and the estimator is unmeasured under the sanitizers and in the FULL 102-case binary, which is where test_ltx2_video span_slack is a 250us wall-clock bound with no load allowance: measured 171x swing on one binary (not currently red) #1576 measured the 171x swing that started this.
• HYPOTHESIS: on a ROCm runner (1c)'s boundary sampler would call hipMemGetInfo 1000x/s under the process-wide phase mutex #1728 -- a HYPOTHESIS, unmeasured: on a ROCm runner a 1 kHz boundary sampler would drive hipMemGetInfo under the process-wide phase mutex. CudaBackend does not override DeviceMemoryInfo (CudaBackend never overrides DeviceMemoryInfo, and the seam's comment says it does — so Gemma4MoE's device-expert LRU is dead on CUDA #1126); src/vt/rocm/rocm_backend.hip:373 does.

Baseline

Inheritance is read by FAILURE TEXT, not by job name, and the inherited set MOVED while this branch was open. At 019f66c1a main was red on build-test-cpu, both sanitize-cpu arms and both windows-msvc-*. Three of those five are GREEN here now: main landed the tests/vllm/v1/worker/test_runner.cpp:1557 repair (#1602/#1608) and this branch takes it by merge, not by any edit of its own.

agent-record was red here and is not this row's. Its failure text was ERROR: .agents/issue-index.md: issue #1649 listed twice — a merge=union duplicate this branch filed as #1733 rather than repairing, because AGENTS.md says never edit a row and never delete one. main repaired it in 6354755ba (#1742), #1733 is CLOSED, and this branch inherits the repair by merge. That one was worth reading rather than waving through: a records gate failing on a records-only branch is exactly where a real failure would hide behind an inherited one. The record anchors ... -> rot 37 line beside it is the rot budget being MET — check-agent-record.py prints ANCHOR-ROT=37 and exits 0 on main and here alike.

What is left is two jobs, and BOTH are inherited, filed and owned. Each is named by FAILURE TEXT and cited to the issue that MATCHES that text, because "the standing Windows red" is not one stable thing and a records gate turning red on a records-heavy branch is exactly where a real failure would hide behind an inherited one.

agent-record -- an ABSENT INSTRUMENT reading as a code verdict. The text is ERROR: test_rendered_benchmark_index_links_resolve_to_emitted_pages ... FileNotFoundError: [Errno 2] No such file or directory: 'hugo' / FAILED (errors=1). tests/scripts/test_check_site.py invokes hugo through subprocess.run with no shutil.which, no skipTest and no FileNotFoundError handler, and the job never installs it. That is #1722, open since 2026-08-22, with the repair in flight as PR #1726. #1754 is a later DUPLICATE of the same defect -- same file, same missing guard -- filed six hours after #1722 and citing neither it nor #1726; the original is cited here on purpose, because a squash body is the landed commit message and a pointer to a duplicate cannot be repaired afterwards.

It is a LAYERED failure, which is why it looks new: until 6354755ba the same job exited earlier on .agents/issue-index.md: issue #1649 listed twice, so nothing downstream of that line had been reached. The record checkers themselves are FINE -- check-agent-record.py prints ANCHOR-ROT=37 and exits 0 on main and on this branch alike, the rot budget MET rather than exceeded, and audit-live-rows.py passes -- verified locally on the merged tree rather than inferred from a job colour.

windows-msvc-cpu / windows-msvc-vulkan -- #584, and NOT #1649. #1649 is the pre-compilation refusal CMakeLists.txt: MSVC /W4 /WX policy is negated on the C/C++ compile by /w, and PR #1701 rescoped that gate on main at 2f2a70925. The lanes now get PAST Windows portability contract OK and die twenty-eight minutes later at test_openai_api_server.exe exited with status -1073740791 -- 0xC0000409, STATUS_STACK_BUFFER_OVERRUN -- immediately after a decoder prompt (length 40) is longer than the maximum model length of 32 refusal. That is #584, already open, and its history repeats: it was filed when an earlier fix first let that binary run on Windows, #1649 then re-masked it, and #1701 has unmasked it again. A post-#1701 Windows red citing #1649 is a false attribution, so this body does not make one.

Nothing in this change touches src/vllm/entrypoints/, and the length guard in that log is #1675, already present in this branch's merge base. Two branches sharing no diff reproduce the crash byte-identically, so it is attributable to no current row. windows-msvc-* is also SKIPPED on main (#503 -- the jobs are pull-request-only), so inheritance for it cannot be read off a main baseline at all and is established from failure text plus the owning issue instead.

tests/scripts/test_cpu_x86_llamacpp_floor.py refuses locally under box load with NO_QUIET_WINDOW after 30s (busy=105% builders=0 load=60.83) and passes once the box is quiet (Ran 10 tests in 186.719s / OK at loadavg 35). That is the harness's own quiet-window precondition, not a verdict.

This is records-only, and the invariants say so

git diff --stat <merge-base>..HEAD -- src/ include/ tests/ docs/ scripts/ is EMPTY, and the net diff is exactly three .agents/ files. The comparison is against the MERGE BASE rather than against origin/main deliberately: main moved to b508cbce6 while this branch was open, and a diff against the moved tip reports THAT commit's docs/FEATURES.md, docs/models/qwen3-8-27b.md and tests/vt/test_ops_matmul_fp8_block_cuda.cpp changes INVERTED, as though this branch were reverting them. It is not; it is one commit behind, and b508cbce6 touches neither ltx25 spec nor the issue index.

.agents/issue-index.md is +2 with zero removals: #1727 and #1728 each appear exactly once, they are the last two rows, and no pre-existing row is modified -- checked row-by-row against origin/main, not by reading the diffstat.

It composes with #1711, and that was PROVED rather than assumed. Both pull requests edit .agents/specs/ltx25-phase-residue.md and git merge-tree reports CONFLICT -- but the conflict is POSITIONAL, not semantic: #1711 edits rows #1569 and #1571, this one edits #1572 and #1470, and they collide only because #1571 and #1572 are adjacent lines. That table is a KEYED RECORD, so AGENTS.md ## Records forbids resolving it by an automatic three-way merge. The resolution takes the complete target-branch file and re-applies this branch's two row edits by exact unique anchor: all four edits present, and the six untouched rows byte-for-byte identical.

FOLLOWING_AGENTS_PROTOCOL

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