fix(LTX25-DEVICE-SEAM-SIBLING): the third question, and a leakage bucket that is a property rather than a spelling (#659, #660)

[localai-bot]

Rebuild of #671 onto current main, plus the repair of the fresh review of 7502004aa. #671 is CLOSED; this is the branch that carries the work. The original rebuild was needed because four commits carried Assisted-by: AGENT:claude-opus-5[1m] [...], and the brackets belong to the tool slot only, so CI's per-commit walk over PR_BASE..PR_HEAD failed on all four regardless of the tip. A new branch rather than a force update, because no force variant is used here.

Implements the committed spec .agents/specs/ltx25-device-seam-sibling.md.

Issues: #659, #660. Files and does not fix: #828. Campaign: #644.

The review of 7502004aa returned FAIL on a change it found correct and a gate it found honest. Every one of its eight findings was an untestable assertion, a reachability gap, or a record that claimed more than it had — and every one is this row's own thesis pointed back at the row. They are repaired in f0b465029, 0600a7ef1 and 4e7a708ad (the READER ANCHORS re-derivation), each verified on this branch with git merge-base --is-ancestor; see "Review round 4" below, which also corrects two claims this body previously made and the review disproved.

The two defects

#659 — the seam was adopted, its companion guard was not. 11cc1d589 routed
LTX-2.5's device question through the platform seam and asked two of the three
questions its own cited precedent asks. src/vllm/entrypoints/model_loader.cpp:98
also asks plat.supports_model_architecture(architecture), which exists so a
PARTIAL backend can decline by name. src/vllm/platforms/metal.cpp:70 and
src/vllm/platforms/tenstorrent.cpp:55 are the only two overriders and both
declare {"OPTForCausalLM", "Qwen3ForCausalLM"}. On those builds a device = 1
LTX-2.5 load was refused by name and had become a queue bind that dies later
inside a kernel. CUDA is unaffected, which is why it is invisible on the gate box.

#660 — the gate that certified it is a token grep.
scripts/check-device-leakage.py's kcuda bucket is \bkCUDA\b.
src/vllm/multimodal/minimax_h3_video.cpp:225 (pre-change) wrote
static_cast<vt::DeviceType>(device) against kCUDA = 1 and scored zero,
while tests/vllm/models/test_minimax_h3_video_fold.cpp:162 spelled the token
honestly and was counted. The gate read the confession and missed the act.

The load-bearing claim: dev_cast is a property, not a spelling

A bucket that grepped static_cast<vt::DeviceType> would close the one site we
found and be the same defect one spelling later. The bucket is anchored on the
target type, matched over the whole comment-stripped text, and is asserted
RED for ten spellings that are not in the tree, each individually:

Mutant	Spelling planted	Added
M20	C-style (vt::DeviceType)d
M21	functional vt::DeviceType(d)
M22	intermediate int + unqualified static_cast<DeviceType>(raw)
M23	brace vt::DeviceType{d} (unnamed temporary)
M24	cast split across two lines by clang-format
M29	C-style past the parameter-declaration discriminators, with a literal )1, a signed literal )-1 and an identifier operand	review
M30	global-scope static_cast<::vt::DeviceType>(raw)	review
M31	elaborated static_cast<enum vt::DeviceType>(raw)	review
M32	list-init in a declaration, vt::DeviceType dt{raw}	review
M33	pointer punning *reinterpret_cast<vt::DeviceType*>(&raw)	review

Each goes RED with DSR REGRESSION in bucket 'dev_cast': 1 > baseline 0 — except
M29, which appends its three operand kinds to the same false-positive fixture and
so reds at 1 >, then 2 >, then 3 > baseline 0, proving the discriminators
cost none of them.

M22 is the one that separates "anchored on the target type" from "anchored on
the operand": the thing cast is neither a literal nor the parameter, and the
qualifier is dropped.

Negatives, so the bucket stays usable: M25 (static_cast<int>(t) and
static_cast<size_t>(t) — the safe direction, and how the seam indexes its own
registry — do not count), M26 (prose and string literals do not count), M27 (the
platform registry walk is allowlisted at exactly one; a second cast in that
file still fails), M28 (DSR-ALLOW exempts a dev_cast and is printed loudly),
M29 (a parameter declaration is not a cast).

Negative M34 (review): a function definition whose return type is
DeviceType is not a conversion. Not hypothetical — the first cut of M32's
declaration form accepted ( as well as { and produced three false positives
on the real tree, including MiniMaxH3VideoDeviceType and
ResolveExplicitDeviceType. The declarator form takes { only, which costs
nothing real because vt::DeviceType dt(raw) is ill-formed.

Residual blind spots, recorded in the checker's own docstring because a
checker's message is the authority on what it enforces: casts through a type
alias, a macro, or a template parameter; bit_cast/memcpy/union punning
(the pointer-cast spelling is now caught — these three are not, because no
spelling of the target type appears at the site); conversions inside the
unscanned src/vt/ device leg; and the fact that nothing type-checks the
operand, so the bucket flags every cast to DeviceType and relies on
DSR-ALLOW for a legitimate wire-format decode — which is also why a pointer
target counts, since const_cast<DeviceType*>(p) removes const rather than
converting, and buys its exemption the same way.

metal.cpp / tenstorrent.cpp run no diffusion model

Checked before assuming, per spec §5. Searched their own vocabulary over
src/vllm/platforms/{metal,tenstorrent}.cpp and src/vt/{metal,tenstorrent}/
with OPTForCausalLM as a positive control in the same command: the control
hit 3 times, ltx|minimax|h3|diffus|video hit 0. The guard refuses nothing that
works today, so §6's NEEDS_DECISION stop condition is not triggered.

Baseline: every line touched, with its reason

scripts/device-leakage-baseline.json — one added line, no changed value:

+    "dev_cast": 0,

total stays 32 and every other bucket is byte-identical. The key is
required because load_baseline() reads every entry in BUCKETS; the value is
0 because the H3 site is repaired rather than absorbed, and the platform
registry walk is allowlisted with a stated reason rather than counted. No number
in this file goes up. (A peer measured that --write-baseline refuses to raise
the baseline but that hand-editing the JSON higher makes the checker PASS — so
this diff being one line and visible is the only real defence, and the key-by-key
comparison is under "Landing" below.) On the final tree the shipped ratchet reads
kcuda=0, is_cuda=0, dev_cast=0, cuda_inc=0, vt_ifdef=32 -> total 32, and
--report shows the one raw dev_cast hit is platform.cpp's allowlisted
registry-walk inverse.

The one judgement call

supports_model_architecture is asked with the family string (ltx-2.5,
minimax-h3), not an HF architectures[0] class name. The diffusion lanes are
reached through LoadVideoEngine/VideoModelParams::family and never read an
architectures entry, so the family slug is the only stable identifier they
have — and it is the string the user actually typed, which is what the refusal
names. It does mean the seam's key space now mixes HF class names with family
slugs. They cannot collide. Flagged rather than buried.

A disagreement between the dispatch brief and the spec, resolved in the spec's favour

The brief said test_minimax_h3_video_fold.cpp:161-164 @ 62406c30e must stay green
unchanged. The spec's §4.2 enumerates the contract as 0 → kCPU, -1 and
2 throw, and separately requires that on a CPU-only build 1 is refused.
Line 162 asserted MiniMaxH3VideoDeviceType(1) == kCUDA — precisely the cast's
answer — and cannot survive the change. It is now build-conditional and asserts
both arms rather than skipping either: == accelerator where one is
registered, refused-by-name where none is. 161/163/164 are untouched.

The review upheld this and corrected the other half of it — see the review
section below: the build-conditional form was right, but the predicate choosing
between its arms asked two of the three questions and so red on a correct
refusal.

Relatedly, that file's CUDA-load case registered a backend and no
platform — it could, because the cast never asked whether the build had an
accelerator. It supplies both halves now. That is the defect being visible, not
a harness concession: a build with a CUDA backend registered and no CUDA platform
is not a build that runs on CUDA.

Out of scope, held to

• No change to what CUDA does. supports_model_architecture defaults to true,
  so CUDA and CPU selection is byte-unchanged; the existing suite passing
  unchanged on this box is the gate for that.
• No other baseline key touched.
• No change to the H3 video engine's model behaviour — device resolution only.
• src/vllm/multimodal/video_engine.cpp untouched (video_engine.cpp reaches Windows with unguarded POSIX stat — reddens windows-msvc-* on EVERY open PR #664 / PR fix(#664): the video registry's existence probes stop reaching Windows with POSIX stat #677 own it).

Review repair (findings from the review of 094ac9e4)

The review returned FAIL with sound core work: it reproduced every green and
every claimed mutation, verified branch orthogonality, confirmed the baseline
diff by hash, and independently planted three fresh spellings that each went RED.
Four findings, all repaired here.

F1 (High) — the bucket missed the purest form of the defect, and the test that
was supposed to rule that out could not see it.

(vt::DeviceType)d    -> dev_cast 1, RED     (what M29 asserted)
(vt::DeviceType)1    -> dev_cast 0, GREEN   <-- MISSED
(vt::DeviceType)-1   -> dev_cast 0, GREEN   <-- MISSED

The C-style alternative's trailing lookahead admitted only [A-Za-z_(], and 1
is a digit. A C-style cast of an integer literal — the device named by its
raw enum value — is exactly what this bucket exists to police, so the one form it
could not see was the one form it was for.

What makes it High rather than a nit: this PR asserted that the M29
discriminators cost nothing, and they cost this — while M29's own "did not cost
the real thing" assertion used an identifier operand, so the test could not
detect the gap it was written to rule out. A guard that certifies itself is the
exact disease this row exists to fix, reproduced inside the row's own instrument.
M29 now pins the literal first, then the signed literal, then the identifier,
all in the same file as the false-positive fixture.

Re-derived rather than taken on report: over src/vllm + include/vllm, 720
files, with \bDeviceType\b = 162 matches as a positive control in the same
command, admitting 0-9+- adds zero hits and loses none. The only raw match
under either pattern is platform.cpp:85's allowlisted registry-walk inverse.

F3 (Medium) — the docstring under-reported, and three cast keywords were dead.
Four more plain spellings read GREEN in scanned files. Each was compile-checked
as legal C++ before being called a blind spot, and each is now closed (see the
M30–M33 rows above). The pointer target is what makes the keyword list honest:
reinterpret_cast, const_cast and dynamic_cast to a scoped enum are
ill-formed — compile-checked, all three rejected, with static_cast as a live
control that compiles — so before this change those three keywords could only
ever have matched code that does not build. They created an appearance of
coverage the pattern did not have. Matching a pointer target makes them live
rather than dropping them.

F2 (Medium) — the row added a test that FAILS on the build class #659 exists to
serve. test_minimax_h3_video_fold.cpp's have_accelerator asked two of the
three questions (device_type() != kCPU && TryGetBackend() != nullptr). On Metal
or Tenstorrent both are true, so the test took the == accelerator arm while the
source correctly refused, and the refusal surfaced as an uncaught exception.
Proven by mutation, not deduced — a DecliningPlatform registered in the XPU
slot, production code untouched:

	result
before (2-question predicate)	:247 ERROR: CHECK( MiniMaxH3VideoDeviceType(1) == accelerator ) THREW … "DECLINES the architecture 'minimax-h3'" — 6 cases, 5 passed / 1 failed, 137 assertions, FOLD_EXIT=1
after (3-question predicate)	6 cases, 6 passed / 0 failed, 137 assertions, FOLD_EXIT=0

So the row shipped a false RED on precisely the partial-backend build it was
written to protect — invisible on the CPU and CUDA boxes that run the gates,
which is this row's own thesis about #659 turned against its own test. The
predicate is now three-way and asserts which refusal, because a right refusal
for a wrong reason is a wrong diagnosis that reads as a right one.

F4 (Low) — an assertion that only checked absences. The "COMPLETE backend is
not refused" case checked that DECLINES and supports_model_architecture were
absent and never positively asserted that the load reached the missing
checkpoint, so it would pass on any other wrong failure. Mutation (an unrelated
Fail() planted after the capability clause): the two absence checks both
passed and only the new assertion caught it — 4 cases, 3 passed / 1 failed;
24 assertions, 23 passed / 1 failed; the failure at :178 on the /nonexistent/
path. ltx2_video.cpp restored and verified by sha256.

F6 — the decline consequence inverts the cited precedent (recorded in the
spec, no code change). model_loader.cpp:98's capability question lives on the
kAuto path, whose answer to a decline is to fall through to :104 and serve
on CPU; metal.cpp:65-69 states that policy in as many words. Both diffusion
lanes instead throw. That is correct — device = 1 is an explicit
accelerator request, and model_loader.cpp:71-72 already says an explicit
accelerator must fail loudly rather than silently serve on CPU — but this PR
described the change as mirroring the precedent, and it mirrors the question
while inverting the consequence. Both halves are the seam's own, taken from two
different paths of it. Also recorded: vulkan.cpp does not override
supports_model_architecture, so a partial Vulkan build still binds and dies.
Residual, not this row's to fix.

New-branch orthogonality

Each of the five new capabilities REDs its own mutant and no other; the
unmutated suite REDs none. Checker restored and sha256-verified after every one.

Capability removed	RED
digits/sign in the C-style lookahead (F1)	M29
global-scope :: in the qualifier (F3-a)	M30
elaborated enum in the qualifier (F3-b)	M31
the named declarator list-init (F3-c)	M32
the pointer target (F3-d)	M33

M34 is proven the same way in reverse: re-admitting ( to the declarator form
makes it RED at 4 != 0.

Landing: rebuilt onto origin/main, twice, and one keyed record RETIRED rather than reapplied

The branch was rebuilt, not just merged, because four of its commits could never
have landed. 78f401796, b73d4576f, 966e4883f and 79ebbce42 carried
Assisted-by: AGENT:claude-opus-5[1m] [claude-code]. Brackets are the TOOL slot;
scripts/check-commit-trailers.py:20's grammar has no bracket in the model token,
so the strict per-commit walk CI runs over base..head fails on all four no
matter what the tip looks like. Only those four message lines were rewritten. The
pre-merge tree is byte-identical to the previous head bf8bb745b — the same tree
object 6ab028f8c — and the branch topology is unchanged, so this is the same
change with four commit messages repaired.

The conflict was .agents/roadmap_v1.md, and the resolution is to write
NOTHING there. Main's version was taken wholesale, per the keyed-record rule.
Then the scoped edits were not reapplied, and that is the finding rather than an
omission. Both edits lived in the ## Open issues table, and
#840 (POLICY-ISSUE-INTAKE)
moved that whole table out to the new append-only .agents/issue-index.md. Under
that regime a row is appended and never edited; GitHub holds the open and closed
state, so closing #659 and #660 costs the index no edit at all. This branch's
in-place annotation of those two rows is exactly the FIXED IN FLOW shape that
spec retired, and a union driver would have duplicated it rather than merged
it. The evidence it carried is not lost — it is in this row's spec, which is the
surface that owns it.

Proved by comparison rather than by eye:

record	diff vs origin/main
.agents/roadmap_v1.md	0 lines
.agents/issue-index.md	one APPENDED row, #828 (round 4 / F7). No existing row edited, none deleted, and the preamble untouched — which is what makes the merge=union driver safe
scripts/check-issue-index-append-only.py --base origin/main --head HEAD	green in agent-preflight.sh (issue-index append-only) on both the committed range and the staged change
check-agent-record.py	green; UNOWNED_HIGH_WATER is unchanged at 33, because #828 names no owning row but IS listed under the spec's ## Owed, which is exactly the mechanism that keeps the count where it is

LTX25-DEVICE-SEAM-SIBLING has no portfolio row in roadmap_v1.md either —
checked with ENG-WEIGHT-OFFLOAD at 2 hits as a positive control in the same
command — so there is no lifecycle write owed and docs/STATUS.md /
docs/BENCHMARKS.md stay untouched. The spec's ## Now now says all of this,
because it previously claimed a table that no longer exists.

origin/main then moved again, mid-gate. It is a shared ref in a shared
checkout, and a peer session's fetch advanced it from 4a4ab89cb to 62406c30e
while this branch was building. The tell was a git diff origin/main HEAD that
grew from 11 files to 24 and showed this branch deleting
docs/WEIGHT-OFFLOAD.md, which it has never touched. Nothing was wrong with the
branch; the denominator moved. The second merge was conflict-free and the two
record checks above were re-run against the new tip rather than inherited.

Two more merges in round 4, both conflict-free. e8048ef63 first — it
carries 8f49ac3be, the ## Nothing lands dead policy and
.agents/reachability.md that F2 is judged against, and it fixes check-site.py
which this branch had been carrying red. Then 0785cfc4d mid-repair, taken
BEFORE the final anchor sweep rather than after it, because it edits
ltx2_video.cpp and moved four of this row's anchors by 43 lines. Deriving
anchors against a denominator that is about to move is not a derivation.

Diff, measured rather than copied: 15 files, +2104 / -22 against
origin/main at 2f2bce926, which this branch has merged. (The body previously
said 11 / +1733 / -13 against 62406c30e; three merges and the round-4 repair
are in the difference.)

Where the history is. row/LTX25-DEVICE-SEAM-SIBLING-REBUILD, pushed with
plain non-forcing pushes only. This pull request is already based on it, so the
"operator repoints it" note this body used to carry is discharged.

scripts/device-leakage-baseline.json — the keyed record — re-checked at the
final tree, key by key rather than by eye:

top-level keys base=['_comment','buckets','total'] head=['_comment','buckets','total']
_comment identical: True        total base=32 head=32
  cuda_inc   base=0    head=0    SAME
  dev_cast   base=<absent> head=0  CHANGED   <- the one key this row claims
  is_cuda    base=0    head=0    SAME
  kcuda      base=0    head=0    SAME
  vt_ifdef   base=32   head=32   SAME
added=['dev_cast'] removed=[] changed=[]
raw text with the ONE added line removed == base text: True

Note for the reviewer: total is decorative. load_baseline() reads only
data["buckets"], so nothing gates the sum, and "total is still 32" is not
evidence about any bucket. The line-for-line identity above is.

Anchors re-derived at the merged tree, asserted UNIQUE

Superseded by the round-4 repair below. This section's closing sentence
claimed the sweep was complete. It was not: six more citations were stale, all
of them rotted inside this pull request, and the sweep had not counted them.
The corrected method, and the four further anchors that the second merge then
moved by 43 lines, are in "Review round 4". The paragraph is kept because the
five anchors it does record were genuinely repaired.

Every path:NN this row cites was re-resolved by pattern, and each pattern was
required to match exactly once in its file — existence is not enough, because
an anchor that still resolves can resolve to the wrong thing. 31 citations across
the spec and the row's own source comments. Five did not hold, and they split two
ways:

anchor	was	is	whose drift
model_loader.cpp:97 (the capability clause)	:97	:98	main's
model_loader.cpp:71-72 (explicit-accelerator polarity, F6)	:71-72	:72-73	main's
minimax_h3_video.h:63 (the preserved public contract)	:63	:69	already stale at bf8bb745b
ltx2_video.cpp:545-548 (the "refusal to fake it" argument)	:545-548	:562-565	already stale at bf8bb745b
minimax_h3_video.cpp's citation of ltx2_video.cpp:549-580	:549-580	:566-610	already stale at bf8bb745b

Three of the five rotted inside this pull request, shifted by its own later
commits — which is the recorded-anchor failure mode this repository already has a
name for, and nothing but re-derivation notices it. All five are corrected.

The spec's own scanned-file figure was re-derived too, since it carries a SHA
precisely because it rots: 776 files at this merge, controls
\bDeviceType\b = 163 and \bkCUDA\b = 18. kCUDA is unchanged and
DeviceType moved by one — the invariant that section claims — against +11 on the
count, the thing it predicts. Two measurement traps are now written beside the
number because each made a correct recorded figure read as wrong: the controls
are counted over the comment-and-string-stripped text (raw source gives
177 / 82), and the enumeration must be the checker's own rglob, since a
git ls-tree walk filtered by string prefix swallows include/vllm.h and returns
777.

Mutation table — every guarantee neutralised, rebuilt, and re-run

Measured against 7502004aa, before the round-4 repair. The counts moved with
the test file (4 cases / 24 assertions then, 6 / 38 now) and MU1 and MU3
entered at Ltx2VideoEngine::Load rather than LoadVideoEngine. The
round-4 table at the end of this body re-runs the equivalents at the final
tree; MU-D and MU-E are MU1 and MU3 repeated there.

Mutated, not read. Each row records whether it built, because a mutation that
fails to compile reads as a passing test and has produced false verdicts on this
campaign before. Every file was restored and verified by sha256 after each
mutation, and git status --porcelain carried no product-file entry afterwards.

#	guarantee	mutation	built?	verdict
MU1	#659: ltx2_video refuses device = 1 by name when the platform declines the architecture	if (false && !platform.supports_model_architecture(kLtx2VideoFamily))	YES	RED — test_diffusion_device_seam exit 1, 4 cases / 3 passed / 1 failed, 24 assertions / 19 passed / 5 failed
MU2	#660: MiniMaxH3VideoDeviceType resolves through the seam, not by integer cast	the pre-change defect restored verbatim: return static_cast<vt::DeviceType>(device);	YES	RED — test_minimax_h3_video_fold exit 1, 6 cases / 5 passed / 1 failed; FATAL ERROR at test_minimax_h3_video_fold.cpp:232, "device 1 must be refused when this build cannot honour it"
MU3	#659, H3 arm: the sibling lane asks the third question too	if (false && !platform.supports_model_architecture(kMiniMaxH3VideoFamily))	YES	RED — test_diffusion_device_seam exit 1, 4 cases / 3 passed / 1 failed
MU4	F4: the COMPLETE-backend case positively asserts the load reached the missing checkpoint	an unrelated Fail() planted after the capability clause	YES	RED — exit 1, 24 assertions / 23 passed / 1 failed; the single failure is :178, CHECK( msg.find("/nonexistent/ltx2-dit-that-is-never-opened.safetensors") != npos ). Both absence checks passed, exactly as F4 claims
MU5	#660: the dev_cast bucket is what the checker's suite is testing	RE_DEVTYPE_CAST replaced with a pattern matching nothing	n/a (Python)	RED — tests/scripts/test_device_leakage.py: 30 failed, 24 passed
MU6	#660 forward: the shipped gate now sees the act, not only the confession	the original defect restored in product source, checker unmodified	n/a (Python)	RED — dev_cast=1, total 33, ERROR: DSR REGRESSION in bucket 'dev_cast': 1 > baseline 0, exit 1

MU6 is the one that proves the row's thesis rather than its implementation. The
old kcuda token grep scored that exact line zero; the shipped bucket fails
the build on it.

Gate

CPU build, no CUDA, -j6.

cmake -S . -B build -G Ninja -DCMAKE_BUILD_TYPE=Release -DVLLM_CPP_CUDA=OFF
cmake --build build -j6
ctest --test-dir build -j4 --output-on-failure

Two runs, because origin/main moved between them. The first is the clean
one — build/ deleted first, because an incremental green is not a clean green.
The second re-gates the union merge on top of it.

axis	clean, at the 0785cfc4d merge	final, at the 2f2bce926 merge
CONFIGURE_EXIT	0	0
BUILD_EXIT	0	0
edges	1418 / 1418, from a deleted build/	774 (incremental over the clean one)
Building CXX / Linking CXX	931 / 481	294 / 479
: error:	0	0
warning:	0	0
No space left	0	0
BFD assertion	0	0
ctest -N	479	481
CTEST_EXIT	8	0
result	99% tests passed, 1 tests failed out of 479	100% tests passed, 0 tests failed out of 481
box loadavg at ctest	20	44

Two tests did not run in both, Skipped by their own guards and both
pre-existing: test_modelopt_mixed_precision_checkpoint and test_voxtral_e2e.

The clean run's one failure was test_engine_core_proc, charged to load and
measured rather than asserted. It failed under -j4 on CHECK( abort_seen )
(test_engine_core_proc.cpp:481), a timing assertion. Re-run alone, three
times: 14/14, 14/14, 14/14 — and its assertion count moves between runs (113,
118, 118), which is the timing dependence visible in the instrument itself. It is
on the known load-dependent list, and it passed in the final run at a higher
load.

A second failure was real, was this branch's, and is fixed in 4e7a708ad.
An earlier full run also red test_ltx2_video — 0785cfc4d records nine line
numbers in ltx2_video.cpp's READER ANCHORS comment and gates them, and this
branch's capability guard sits ABOVE all nine, so the merge moved every one by
exactly 30. git merge reported no conflict and merge-tree would not have
either, because nothing overlapped textually: one side records line numbers of a
file the other side edits. A clean merge is not a merge that passes. Re-derived
and green: test_ltx2_video 40/40, 827 assertions.

tests/scripts/test_device_leakage.py: 55 tests, OK (was 54; the +1 is M47).

Two tests did not run, both Skipped by their own guards and both pre-existing:
test_modelopt_mixed_precision_checkpoint and test_voxtral_e2e.

scripts/agent-preflight.sh returns 7 red, and every one is demonstrated to
be main's rather than argued to be:

red	proof
check-release-binary-contract, check-release-workflow, check-test-registration, test_check_release_binary_contract, test_release_manifest, test_release_pipeline, test_check_test_registration	the #873 family. All seven read .github/workflows/*, and git diff origin/main HEAD -- .github/ is EMPTY — positive control in the same command: the files that DO differ are the 15 listed above. check-test-registration's own message is check-test-registration is missing from the explicit CI checker step, which names a workflow this branch does not touch
—	check-site.py is no longer red: e8048ef63 fixed it on main and the first merge picked it up
—	test_cpu_x86_llamacpp_floor (#618) went red on the pre-commit run at loadavg 65 with AssertionError: 4 != 2 — exit 4 is NO_QUIET_WINDOW, the harness declining to measure — and green on the staged run. Load-dependent, not a floor that was measured and missed

Green in the same run and worth naming, because they are the ones this change
could have broken: check-agent-record, check-device-leakage,
check-now-current, doc-checkpoint range, doc-checkpoint --staged,
issue-index append-only, audit-live-rows, and the trailer and
commit-style suites.

One caution about the mutation pass, recorded because it produces a false
green. The harness restores the source but does not rebuild, so the binaries
left behind after the last C++ mutant still contain it. The tree was rebuilt
after the pass, and test_diffusion_device_seam (6/6, 38 assertions),
test_minimax_h3_video_fold (6/6, 137) and test_ltx2_video (40/40, 827) were
re-run directly to confirm the restored binaries are the green ones. A stale
binary prints a green status.

Build directory deleted after the run.

GitHub said CONFLICTING while merge-tree said clean, and the difference is
the finding. After the push at 0785cfc4d, git merge-tree --write-tree origin/main HEAD exited 0 and the pull request read CONFLICTING /
DIRTY. Re-running the merge with the union driver disabled names the single
file: .agents/issue-index.md, which carries merge=union in .gitattributes.
GitHub's merge machinery does not apply a .gitattributes merge driver, so an
appended index row conflicts on the forge and resolves locally. Any branch
that appends an index row while main also appends will read the same way; it is
a property of the surface, not of this row.

Merged locally with the driver and then verified rather than trusted, because a
union merge is exactly what turns an EDITED row into a duplicate: the merged
index has one line origin/main does not (#828), zero lines it has and
the merge lacks, and no duplicated issue number.
check-issue-index-append-only.py --base origin/main --head HEAD reports OK.
The final gate above is on that merge.

## Nothing lands dead (8f49ac3be, landed mid-gate)

Half of this section was wrong, and the review proved it by mutation. It
claimed the H3 lane was reached because MiniMaxH3VideoDeviceType has exactly
one production call site and MU1/MU4 red without it. Naming a call site is not
the test the policy asks for. MU1 and MU4 neutralise the LTX guard, not the
H3 call site, and deleting the H3 call site left every suite GREEN. Repaired
below; the corrected claim is in "Review round 4 / F2".

The policy arrived on main while this was gating, so it is answered rather than
ignored. Nothing here lands unreached.

• ltx2_video.cpp's guard sits inside Ltx2VideoEngine::Load, which is what
  LoadVideoEngine and the video C ABI call.
• MiniMaxH3VideoDeviceType has exactly one production call site, in
  MiniMaxH3VideoEngine::Load.
• Both lanes are now ENTERED at LoadVideoEngine by
  test_diffusion_device_seam, and deleting either call site reds it.

Review round 4 (findings against 7502004aa)

F1 (major) — the "refuses BY NAME" assertion could not fail. The LTX case
asserted msg.find(kLtx2VideoFamily). Fail() in ltx2_video.cpp prefixes
every message it throws with "ltx-2.5 video: ", and kLtx2VideoFamily is
the string ltx-2.5 — so the assertion was satisfied by boilerplate on every
refusal the file can produce, including the two the same case asserts it is NOT,
and no defect in the message could make it fail. That assertion is the row's
whole thesis for #659.

Proven by mutation, not deduced: replacing the family name with "<redacted>"
inside the DECLINES Fail BUILT and stayed GREEN on the reviewed head. It is
now RED — see MU-A in the table below. The H3 side escaped only because its
prefix spells the family with an underscore (minimax_h3 video: ) against a
hyphenated family (minimax-h3); that is a coincidence of spelling, not a
property, and it is hardened the same way (MU-B). Both lanes assert the quoted
slot, architecture '<family>', through one QuotedArchitecture() helper that
carries the reason.

F2 (major) — the H3 half violated ## Nothing lands dead. The chain existed
— vllm_video_engine_load → LoadVideoEngine → the minimax_h3 registration →
MiniMaxH3VideoEngine::Load → MiniMaxH3VideoDeviceType — and nothing entered
through it. Replacing the Load-time call with the pre-row defect
params.device == 0 ? kCPU : kCUDA BUILT and left both suites GREEN. The
fold suite's CUDA load creates exactly one queue case does enter through
Load, but its FakeCudaPlatform reports kCUDA, so the seam and the cast
return the same answer and it cannot separate them.

Two H3 cases now enter at LoadVideoEngine against the declining
PartialXpuPlatform, mirroring the two LTX cases — and the two LTX cases moved
from Ltx2VideoEngine::Load to LoadVideoEngine as well, so both lanes are
entered at the same production point and neither skips the registry hop. The
red-before is MU-C, whose two failing cases are exactly the two new ones. The
policy ships no checker (.agents/reachability.md), so there is no exit code
to report; the test is the enforcement.

F3 (major, record) — the anchor sweep that claimed completeness was
incomplete, and this pull request's own edits are what falsified it. Six more
citations were stale, all rotted inside this branch, two of them seven and
fifteen lines (measured at 7502004aa) from section 0(b)'s minimax_h3_video.cpp:221-226 @ 11cc1d589 citation, which SHA-anchors itself with exactly the
reasoning that applies to them.

citation	was	is
check-device-leakage.py:78 (RE_KCUDA)	unanchored	@ 62406c30e (on the branch: :224)
test_minimax_h3_video_fold.cpp:162 (the kCUDA assertion)	unanchored	@ 62406c30e (on the branch: :220, == accelerator)
test_minimax_h3_video_fold.cpp:161-164, twice	unanchored	@ 62406c30e (on the branch: the three untouched at :192-194, the two arms replacing :162 at :218-238)
ltx2_video.cpp:549-562 (the two questions)	unanchored	@ 11cc1d589
ltx2_video.cpp:562-565 (the refusal-to-fake-it argument)	:562-565	:610-613
model_loader.cpp:97 (the capability clause), twice	:97	:98

Four more range citations started or ended on the wrong line and were tightened:
SelectQueueForModel is :60-105 (cited :59-104), its auto arm :76-104
(cited :75-104), the kAuto CPU fall-through :104 (cited :103), and the
LTX device block, which the citation ended four lines short of, cutting the
Fail in half — now :609-657.

Then it rotted a THIRD time, mid-repair. 0785cfc4d
(LTX25-RETIRE-DEAD-ARMS) landed on main and edited ltx2_video.cpp above this
branch's device block, moving all four live anchors by 43 lines. Caught because
the re-derivation was re-run after the merge: a sweep whose denominator moves
afterwards proves nothing. The rule the spec now records is take the merge first,
derive the anchors at the tree that is pushed.

Re-derivation, with a positive control in the same run: each anchor carries a
token that must appear on the cited line and match exactly once in the file,
and one deliberately wrong line number is included that must report STALE.

HOLDS=27  STALE=1  AMBIGUOUS=0
  stale: include/vllm/platforms/interface.h:264 — token is at [263], not 264
POSITIVE CONTROL (a deliberately wrong line) reported STALE: True

The completeness sentence is withdrawn with its reason, and replaced by a
statement of method and of what the method cannot see: the set is every path:NN
on a line this pull request adds, extracted from
git diff -U0 $(git merge-base ...). It deliberately excludes citations this row
inherited and did not write — folding those in is how the last sweep came to
believe it had checked everything.

That paragraph said it had two limits. It had three, and the third is what
round 5 found twice: a bare :NN whose path sits in a NEIGHBOURING token is
never extracted, because the pattern requires path and number to be glued. See
"Review round 5".

F4 (moderate, record) — ## Now pointed at closed PR #671 and the pre-rebuild
branch. Corrected, with the relationship between the two stated rather than the
number silently swapped, because the round-1 to round-3 findings were made
against #671's heads and a reader has to be able to find them.

F5 (minor, checker) — dev_cast over-matches a plain copy-initialisation.
vt::DeviceType d{other} — a local copy, a member default-init, or an init from
a call returning DeviceType — fires alternative (3) while converting nothing.
Measured: 1 hit each; vt::DeviceType d{} scores 0.

It is not narrowed, and that is proven rather than argued.
vt::DeviceType d{raw} is the real conversion M32/M36 pin and is textually
identical, so narrowing to remove the false positive deletes the true positive.
MUT-P1 makes that executable — restricting the declaration form's initialiser
to a digit reds M32, M36 and all four of M47's subtests together.
MUT-P2 shows M47 is not merely along for the ride: dropping the empty-braces
lookahead reds only M46 and M47, the negative controls, and leaves the real
catches green.

The docstring gains a third section, WHAT dev_cast OVER-MATCHES, alongside
DOES SEE and STILL CANNOT SEE — because a gate whose message omits its own false
positives misleads in the other direction, and a reader takes a RED as proof of
leakage. It states the cost: the baseline is a hard 0, so the first such
line written under the scan roots fails the ratchet and needs DSR-ALLOW.
Nothing in the tree writes the form today. M47 pins it in the M46 shape, with
the value-init as the negative control in the same test, so a later change that
closes it goes RED and the message must be corrected in the same commit.

F6 (minor) — four comments still called the video ABI selector CUDA,
including the public vllm_video_model_params.device field and
minimax_h3_video.h:88 nineteen lines below the docstring this row rewrote.
include/vllm/config/device.h:19 repeats the same sentence and is corrected with
them — it is the fifth instance of one claim, not a fifth claim. docs/USAGE.md
gains the paragraph that owes, and check-doc-checkpoint --staged was RED until
it did.

F7 (minor, record) — #828 was named in check-device-leakage.py:58,139,158
and in the spec, and had no row in .agents/issue-index.md.
check-agent-record.py passed only because an absent row is nothing to count.
Appended with no owning row and listed under the spec's new ## Owed, which is
the shape the protocol defines for an issue a row files and does not fix.
UNOWNED_HIGH_WATER is unchanged, because the ## Owed entry is what keeps the
row owned.

F8 (trivial) — an inverted sentence in the test header that read as though
the refusal and the kernel death both happened.

Round-4 mutation table — three facts each

git diff --stat after the substitution is printed because a pattern that does
not match edits nothing, and the suite then prints SUCCESS. Whether it BUILT is
printed because a mutant that fails to compile reads as a passing test. The exit
code is printed because a thrown doctest case prints 0 failed. Every file was
restored and its sha256 compared, and git status --porcelain was empty after
each.

#	what is neutralised	diff	built?	focused gate
MU-A	F1: the LTX refusal stops naming the architecture ("<redacted>")	ltx2_video.cpp | 2 +-	YES, 0 errors	RED — exit 8; 6 cases / 5 passed / 1 failed; 38 assertions / 37 passed / 1 failed
MU-B	F1, H3 side: same substitution	minimax_h3_video.cpp | 2 +-	YES, 0 errors	RED — exit 8; 6 cases / 4 passed / 2 failed; 38 / 36 / 2
MU-C	F2 reachability: the Load-time call site replaced by the pre-row cast	minimax_h3_video.cpp | 3 ++-	YES, 0 errors	RED — exit 8; 6 cases / 4 passed / 2 failed; 38 / 33 / 5. The two failures are the two NEW cases
MU-D	the LTX capability clause itself	ltx2_video.cpp | 2 +-	YES, 0 errors	RED — exit 8; 6 / 5 / 1; 38 / 33 / 5
MU-E	the H3 capability clause itself	minimax_h3_video.cpp | 2 +-	YES, 0 errors	RED — exit 8; 6 / 4 / 2; 34 / 28 / 6
MUT-P1	F5: (3)'s declaration form narrowed to a digit operand	check-device-leakage.py | 2 +-	IMPORTS=True	RED — exit 1, FAILED (failures=6): M32, M36, and M47 ×4
MUT-P2	F5: the empty-braces lookahead dropped	check-device-leakage.py | 2 +-	IMPORTS=True	RED — exit 1, FAILED (failures=2): M46, M47 only

MU-C is the one that matters. Under the reviewed head the same substitution left
test_diffusion_device_seam at 4/4 and test_minimax_h3_video_fold at 6/6.

All seven were run twice: once before the 0785cfc4d merge and once on the tree
being pushed. The numbers above are the second run.

MU-B's first attempt on the second run reported BUILT=False with : error:
count 0 — a build that failed with no compile diagnostic, which is an
instrument failure and not a verdict. It is recorded rather than dropped, because
without FACT 2 the harness would have gone on to a ctest that could not have
been meaningful, and a mutant that fails to build reads as a passing test. Re-run
in isolation it BUILT with 0 errors and went RED (6 cases / 4 passed / 2
failed; 38 assertions / 36 / 2), which is the row in the table. The cause was not
identified and is stated as unexplained; disk was 66 G free at the re-run.

Review round 5 (head bf77c944e) — record only

Every code, test and checker repair passed: both F1 mutations, the F2
reachability mutation that was GREEN before the repair and is now RED, the F5
narrowing proof, and the READER ANCHORS fix. The four findings are all record
defects, and two of them are one defect: an anchor into a file the change is
itself editing is stale by default.

FF1 — RE_KCUDA was recorded at :188 by the very commit that moved it to
:224. f0b465029 carries both the F3 anchor table, which writes :188, and
the F5 WHAT dev_cast OVER-MATCHES docstring section, which inserts 36 lines
above that regular expression. The F5 half falsified the F3 half of the same
commit — it rotted with no merge involved, which is the usual suspect and
here was innocent. Corrected in this body and in the spec.

FF2 — this body contradicted itself two screens apart. Three live claims used
anchors this body's own F3 table already records as corrected: model_loader.cpp:97
twice (now :98) and tenstorrent.cpp:52 (now :55). A fourth, not in the
review's list, was found by re-deriving rather than by transcribing the list: the
F6 paragraph said the kAuto path falls through to :103, which the same body's
F3 prose records as corrected to :104. The was columns keep :97
deliberately. This mattered because squash_merge_commit_message = PR_BODY makes
this text the landed commit message, so it would have entered main's history
disagreeing with itself.

FF3 — this body named a commit that is not in this pull request.
git merge-base --is-ancestor 93736e745 bf77c944e exits 1: that object
exists but is a superseded twin of 0600a7ef1's first half. The three repair
commits actually on the branch are f0b465029, 0600a7ef1 and 4e7a708ad —
and 4e7a708ad, the READER ANCHORS fix, was not named at all. Each is now
verified with --is-ancestor before being written.

FF4 — the :54 self-citation pointed at a blank line, and it is the exemplar
of GOOD anchoring practice. At 7502004aa :54 was section 0(b)'s
minimax_h3_video.cpp:221-226 @ 11cc1d589 citation; the "seven and fifteen
lines" distances resolve against it exactly, which is how it was identified
rather than guessed. f0b465029 then added the anchors F3 asked for, section 0
grew, and :54 went blank. All uses now name it in PROSE, because a line number
pointing into the spec itself is the one citation no re-derivation of the TREE
can check, and this row has rotted it twice.

Re-derivation. Every citation extracted — bare continuations included, which
is the change — and every live repo-local one checked at the pushed tree, with
each needle derived from what the spec claims the span holds rather than read
back out of the cited file, because a validator that reads its expectation from
its target re-derives f(x) == f(x) and cannot fail. A deliberately wrong row
rode in the same run as a positive control.

50 rows FRESH, 0 STALE   |   POSITIVE CONTROL reported STALE: True

Two observations reported and not repaired, because neither is wrong:
ltx2_video.cpp:609-657 opens one line inside the preceding comment separator
rather than on the block head at :614 (round 4's repair was to its tail, which
is correct at :657), and check-device-leakage.py:58,139,158 is a genuine
three-way citation whose needle cannot be unique by construction.

Gate on the pushed tree, merged onto origin/main at fba312c67 first so
the anchors are derived at the tree that is pushed:
CONFIGURE_EXIT=0, BUILD_EXIT=0, : error: count 0, No space left 0,
BFD assertion 0, with Building CXX 933 and Linking CXX 483 as positive
controls that the build actually ran. ctest -N 481, CTEST_EXIT=0,
100% tests passed, 0 tests failed out of 481. All six checkers exit 0:
check-doc-checkpoint, check-commit-trailers, check-commit-style,
check-issue-index-append-only, check-agent-record, test_device_leakage.

FOLLOWING_AGENTS_PROTOCOL

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