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

[localai-bot]

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

Issues: #659, #660. Campaign: #644.

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:97
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:52 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 two lines and visible is the only real defence, and it is stated
here for the reviewer to check by md5 against the base for every other key.)

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 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:97's capability question lives on the
kAuto path, whose answer to a decline is to fall through to :103 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: re-merged onto origin/main

The PR was CONFLICTING and 16 commits behind origin/main (7b8919da).
Sole conflict: .agents/roadmap_v1.md. It is a keyed record, so main's
version was taken wholesale and this row's two scoped edits — the #659 and
#660 rows — reapplied by key. Verified afterwards that the file differs from
origin/main on exactly two lines, both owned keys, with the line count
unchanged. Main had inserted a row above them (branch line 197 → main line 198),
which is precisely the drift that makes an automatic three-way unsafe here.
docs/USAGE.md and tests/CMakeLists.txt auto-merged and were checked to carry
both sides.

Gate (re-run after the merge — a clean merge is not a merge that builds)

CPU build, no CUDA. CFG_EXIT=0, BUILD_EXIT=0, zero No space left /
BFD assertion in any build log.

ctest -N = 456 (was 445 on the stale base — the drift is main's, 16 commits of it).

Full ctest -j4: 454/456 passed, 2 skipped, 2 failed, CTEST_EXIT=8. Neither
failure is mine, and neither is asserted — both are demonstrated:

• test_serve_low_tools — not on the known-red list, so it was checked rather
  than assumed. Passes serially: 1/1 Passed, 53.22 sec, exit 0. A ctest -j4
  starvation artifact. This diff touches zero serve/tool paths.
• test_op_parity — main red: test_op_parity throws on the MiniMax-Music3 golden manifest — null where a string is required #737, reproduces serially with
  [json.exception.type_error.302] type must be string, but is null at
  tests/parity/test_op_parity.cpp:1989. It prints assertions: 70 | 70 passed | 0 failed while the case threw, so the exit code is the authority, not the
  summary. This diff touches no parity golden.

Focused, before → after:

Suite	cases	assertions
test_ltx2_video	30 → 31	502 → 513	main's, not mine: fc903b8dd (#674) added one TEST_CASE, and that commit's own message records 31 cases / 513 assertions. The test file is byte-identical to origin/main on this branch
test_minimax_h3_video_fold	6	137	unchanged
test_diffusion_device_seam	4	23 → 24	+1 = the F4 assertion, exactly
tests/scripts/test_device_leakage.py	37 → 42		+5 = M30–M34

RED-first for the repair: against the checker at 094ac9e4, the new suite fails
5 times (M29 strengthened, M30–M33). M34 is green both before and after by
construction — it guards a false positive the change could have introduced, not
one it fixes.

check-device-leakage on the real tree: dev_cast=0, total 32 == baseline
32. scripts/device-leakage-baseline.json is untouched by the repair
commit.

Not mine, proven rather than asserted

• audit-live-rows / test_audit_live_rows — the stale ACTIVE
  MODEL-MUSIC-minimax-music3 row. This diff touches zero music3 paths
  (positive control: the six files it does touch are listed in the commit).
  Filed: main red: audit-live-rows reports the Music3 ACTIVE row abandoned, so preflight is red on a clean main #731, audit-live-rows is RED on main: MODEL-MUSIC-minimax-music3 is an abandoned ACTIVE row #733.
• test_op_parity — main red: test_op_parity throws on the MiniMax-Music3 golden manifest — null where a string is required #737, a null in the Music3 golden; prints
  70 passed | 0 failed while the case throws, so the exit code is the authority.

Build directory deleted after the run.

[localai-bot]

F5 repaired, re-merged onto 33f570ea9, anchors re-derived

Head moves from 074ef1420. Three commits: the checker repair, the merge, the anchor/record round.

F5 — the docstring named the target type, the pattern named one sigil

The review's finding was one spelling. Deriving it from the property rather than from the example turned up nine, all of which write the target type at the conversion site — the very thing the docstring said the bucket is anchored on — and all of which scored 0:

spelling	why it slipped	before	after
reinterpret_cast<vt::DeviceType&>(raw)	reference target; the standard defines it as M33's pointer pun	0	1
static_cast<vt::DeviceType const>(d)	east const	0	1
static_cast<vt::DeviceType const&>(t)	east const + reference — compiles with no warning, so it survives -Werror where the prvalue form trips -Wignored-qualifiers	0	1
(vt::DeviceType const)d	east const, C-style	0	1
(vt::DeviceType)*cursor	trailing class admitted a sign, not a dereference — and this is the wire-decode spelling the docstring itself names as the expected DSR-ALLOW case	0	1
(vt::DeviceType)~mask	same hole	0	1
(vt::DeviceType)!flag	same hole	0	1
reinterpret_cast<vt::DeviceType**>(p)	\*? is one star	0	1
std::bit_cast<vt::DeviceType>(raw)	the docstring's own reason ("no spelling of the target type appears at the conversion site") is false for it	0	1

Every one is compile-verified legal — g++ -std=c++20 -Wall -Wextra -fsyntax-only, exit 0, individually — because a "miss" that does not compile is not a miss.

Three edits: the named-cast target takes cv-qualifiers on either side of the name and a run of */&; the C-style trailing class admits *~!; bit_cast joins the cast keywords.

What stays blind, and why the docstring now says so per-entry

& is deliberately not admitted after a C-style ): ) & and ) && are ref-qualifiers on a member declarator, which is exactly the false positive the trailing guard exists to reject, and it cannot tell void note (vt::DeviceType*) & from a pun. So the C-style pointer pun *(vt::DeviceType*)&x remains blind and is now named as blind with the reason true of it. The old blind-spot list gave one shared reason to three entries and that reason was false for one of them; each entry now carries its own.

Measured, with the positive control in the same command

Over 760 files in src/vllm + include/vllm on the merged tree, \bDeviceType\b = 162 matches as the positive control:

files examined                 : 760
POSITIVE CONTROL \bDeviceType\b: 162 matches over the same file set
dev_cast raw hits  SHIPPED     : 1
dev_cast raw hits  REPAIRED    : 1
NEW  (repaired - shipped)      : 0
LOST (shipped - repaired)      : 0
    = src/vllm/platforms/platform.cpp:85: static_cast<DeviceType>

dev_cast stays 0, total stays 32, device-leakage-baseline.json untouched this round.

M35-M40, each sub-spelling asserted individually

RED-before is real rather than narrated: with the pattern reverted in-process to its pre-repair value, M35-M39 all go RED while M20, M33 and M40 stay GREEN — so a blanket failure cannot pass for five findings.

M35  reverted-pattern verdict = RED    expected RED    -> ok
M36  reverted-pattern verdict = RED    expected RED    -> ok
M37  reverted-pattern verdict = RED    expected RED    -> ok
M38  reverted-pattern verdict = RED    expected RED    -> ok
M39  reverted-pattern verdict = RED    expected RED    -> ok
M20  reverted-pattern verdict = GREEN  expected GREEN  -> ok
M33  reverted-pattern verdict = GREEN  expected GREEN  -> ok
M40  reverted-pattern verdict = GREEN  expected GREEN  -> ok

M40 is the negative the widening could have cost: pointer- and reference-returning declarations, ref- and rvalue-ref-qualified members with a space before the paren, volatile members, std::vector<vt::DeviceType*> — all still 0.

Re-merge

29 behind, merge-tree conflicted. One conflict, tests/CMakeLists.txt: main added test_ltx2_image_cond at the same insertion point this row added test_diffusion_device_seam. Both pure additions, both kept, main's block byte-for-byte first. git diff 33f570ea9 -- tests/CMakeLists.txt is exactly this row's seven lines.

Keyed records were not taken on the auto-merge's word. .agents/roadmap_v1.md: 264 keys on both sides, 0 added, 0 removed, exactly #659 and #660 changed, 0 differing non-table lines. docs/USAGE.md differs by exactly this row's one paragraph. FEATURES.md / STATUS.md / BENCHMARKS.md untouched, so #769's duplicated Safetensors direct load key is neither fixed nor multiplied.

Anchors

9f2b9bb9a moved tenstorrent.cpp's supports_model_architecture :52 → :55. All four citations corrected, re-derived on the merged tree. metal.cpp:70, interface.h:263, model_loader.cpp:97 re-derived and still hold. All 103 distinct path:NN anchors in this row's files resolved mechanically; the only non-resolving ones are upstream Python paths and the two examples/*/main.cpp citations that carry @ fc636c76 and are provenance rather than drift. #794 is not widened here. minimax_h3_video.cpp:221-226 — the line this row removes — is now anchored on the spec's base SHA 11cc1d589, where git show resolves it to the exact static_cast.