test(MUSIC3-DIT-ARM-REACH): gate the engine's own call to the DiT arm selector on a real device (#1131) by localai-bot · Pull Request #1821 · mudler/vllm.cpp

localai-bot · 2026-08-23T21:49:57Z

Closes #1131. Row MUSIC3-DIT-ARM-REACH, lane #672, spec
.agents/specs/music3-dit-arm-reachability.md.

Wave 1 of this row (5539686c7) moved the DiT arm's selection rule out of
Music3SpeechEngine into Music3SelectDitArm, so a CPU gate could drive both
sides of a condition no runner CI owns can satisfy. It left one thing unreached
and said so under ## Owed: the engine's own two-line CALL. Mutation M5 deleted
that call and every suite in the tree stayed green. This change is that residual,
closed on hardware.

The gate

tests/parity/test_minimax_music3_device_arm_real.cpp enters through
include/vllm.h -- vllm_speech_engine_load with device = 1, then
vllm_synthesize. That is a production entry point by AGENTS.md
## Nothing lands dead's own list, and its reach does not depend on any other
surface agreeing with it. It constructs no engine, calls no Music3DenoiseChunks
and builds no arm by hand: the only thing that may select the device arm is the
shipped engine executing the line under test.

It reads three instruments and one absence, because the host and device arms agree
numerically by design and no property of the audio can separate them.
acoustic.dit_staging is emitted from inside Music3SelectDitArm past its CPU
early return, so it is present if and only if the engine's call site ran and took
the device branch -- that is the one that answers the residual. denoise.dit_device
says the loop selected the device branch, and dit.pack lives inside
DitForwardDevice, so it says the forward's body executed and a mislabelled bucket
cannot fake it. Their counts are held to steps x windows and 2 x steps x windows
with both quantities read from counters the run produced, and denoise.dit_host
must be absent, which is what stops the other three from being merely present.

The three are not independent of each other on the call-site mutation, and the
spec says so rather than implying otherwise: denoise.dit_device is emitted under
on_device = device_arm.engaged(), and an arm is engaged only through fields the
selector sets, so deleting the call reds all three at once. acoustic.dit_staging
is the most direct and the other two corroborate. They separate on OTHER defects,
which is why all three are asserted: an arm staged and then dropped by the loop,
and a per-CFG-branch fallback that reads dit.pack 2 against 4 under an unchanged
label.

The entry carries LABELS "gpu;checkpoint;music3", so a gate no runner can execute
is selectable by name (ctest -L gpu) rather than by who remembers it, and it exits
77 without a device or checkpoint so CTest reports Skipped, never Passed.
docs/USAGE.md gains the section saying how to invoke it and where, because a gate
nobody runs is the defect this row is fixing.

Measured on thor:gpu0

rc lease job f63f60e8-957a-4062-92f8-54e5bbb49d92, worker rc-worker-kk96r,
boot id e2112cac, unchanged end to end. NVIDIA Thor sm_110, driver 595.78, nvcc
13.0.88 installed by the job, Release CUDA build for 110, configure_rc=0,
compile_rc=0. Tree cloned inside the worker and asserted equal to
bc61ce5182446475485f54504a742d9e38d1326a before anything was built. The
checkpoint was staged off CIFS onto local disk and verified by bytes rather than by
existence -- SRC_BYTES == DST_BYTES == 28517617303 -- which is what turned a 780 s
cold weight load into 8.1 s.

suite	test cases	assertions	Status
`test_minimax_music3_device_arm_real`	1 / 1 passed	22 / 22 passed	SUCCESS!
`test_minimax_music3_acoustic`	40 / 40 passed	403 / 403 passed	SUCCESS!
`test_minimax_music3_speech`	9 / 9 passed	223 / 223 passed	SUCCESS!
`test_minimax_music3_ar`	37 / 37 passed	649 / 649 passed	SUCCESS!
`test_music3_profile`	7 / 7 passed	50 / 50 passed	SUCCESS!

device 1 resolves to 'cuda' and vllm_speech_engine_device() returned 1, so this
is the granted arm and not a request echoed back. acoustic.dit_staging 1 call,
denoise.dit_device 2 calls (steps 2 x windows 1), dit.pack 4,
denoise.dit_host absent.

The acceptance criterion

Delete the production call site and rerun the focused gate
(.agents/reachability.md). One hunk, mutation_applied=1, and compile_rc=0
reported before any verdict, because a mutation that fails to build reads as a
passing test.

     Music3DitDeviceWeights staged_dit;
-    const Music3DenoiseDeviceArm arm = Music3SelectDitArm(
-        queue_, config_.transformer, acoustic.dit, /*release_host=*/true, &staged_dit);
+    const Music3DenoiseDeviceArm arm;  // MUTATION #1131: the engine's CALL deleted
+    (void)staged_dit;

RED: 1 case / 0 passed / 1 failed, 9 assertions / 8 passed / 1 failed,
Status: FAILURE!, CTest ***Failed 211.54 sec, at
REQUIRE(staging != nullptr). The fresh review reproduced it on thor:gpu0 at
head 718546680, in its own job and its own build directory, and confirmed the
red is that assertion rather than a timeout -- no TIMEOUT property is set, and
vllm_cpp_add_test sets only SKIP_RETURN_CODE 77.

And what the red is made of is the argument itself. The mutated run did not fail,
break, or produce different audio. It produced denoise.dit_host at 196.786 s,
93.43% of the run, where the shipped tree produced denoise.dit_device at
0.527 s in the same bucket position -- on 0.24 seconds of audio, from a
change that alters no number anywhere. Two ratios live in that sentence and they
are named separately: the denoise BUCKET ratio is 196.786 / 0.527 = 373x, and
the CTest WALL ratio for the whole gate is 211.54 s against 17.66 s = 12x,
because the run loads a 28.5 GB checkpoint and synthesises either way. Neither is
a performance claim. Nothing that reads the output can see any of it, and until
this gate existed nothing in the tree could.

Restore: the binary hashes back to the baseline. The job log carries three
sha256 lines for tests/test_minimax_music3_device_arm_real and they hold two
values -- ed268392... after the baseline build, ce8bd1f8... after the mutation
build, ed268392... after the restore build -- together with an empty
git status --porcelain at the same SHA, compile_rc=0, and the gate re-run
1 / 1 and 22 / 22 SUCCESS!. The review reproduced RESTORED == BASELINE
independently at this head with a second SHA and a second build directory.

The review's findings, repaired

A fresh reviewer returned FAIL on six findings. Every one was in the record, and
the first was a measured statement that is false.

F1. An earlier draft of ### Restore said the restored binary does NOT hash
back, and generalised that into "this build links CUDA objects and its link is not
bit-reproducible". It had compared the restored hash against the MUTATED one. The
generalisation is deleted rather than softened, because it is the sentence a later
row would cite to waive a hash restore on any CUDA build and nothing measured it.
The ## Evidence this row owes line it appeared to waive is marked MET on both
legs.

F2. ctest -L gpu prints No tests were found!!! and returns 0 when the
label selects nothing (CMake 3.28.3), so the recipe this row documents fails open,
and ctest_L_gpu_rc=0 is also what a zero-test selection returns. For a row whose
subject is a gate that measures nothing while printing green, shipping its own
discovery mechanism in that state is in scope.
scripts/check-test-registration.py now pins the selection to the exact set
{test_minimax_music3_device_arm_real}, read from ctest --show-only=json-v1 over
a configured tree and compared against a literal in the checker rather than against
CMake text -- a checker that reads its expectation from the file it checks is a
tautology. Renaming the label on the shipped tests/CMakeLists.txt takes the
checker from rc 0 to rc 1 with
ERROR: ctest -L gpu selects 0 test(s) [<none>]; REQUIRED_LABEL_SELECTIONS ... pins 1,
and the restored file hashes back to 9a74e857a5a8b51e23a80d23e3b73f3c3af9f0f1.
LabelSelectionMutationTests carries four mutations -- label renamed,
set_tests_properties deleted, a second test taking the label, the labelled
registration removed -- and the suite's fixed manifest and its production-pinned
digest move with them. The suite goes 52 to 57 cases, OK, 0 skipped.

F3. docs/USAGE.md implied a labelling convention that exists at n = 1. It
now names the one labelled gate, warns that -LE gpu is not the complement, and
names the six sibling checkpoint suites -- test_minimax_music3_{ar,llm,acoustic,quant,e2e}_real
and test_muse_glimmer_real_weights -- which carry no label and, unlike this one,
do not exit 77: they print a SKIP line and CTest reports them Passed.

F4. #1131 named both device-arm twins and this change closes only the DiT one,
which would have orphaned minimax-music3.md §19.7's un-struck depth entry. Filed
as #1839 before merge, retracked in §19.7 and appended to the issue index.
Closes #1131 stands. The depth twin is genuinely ungated: §19.6's "device path
TAKEN" leg rides test_minimax_music3_ar, whose observable
Music3DepthDeviceForwardCount() §19.5 itself records as unreachable from
production, and ar.depth_staging -- the instrument that would answer the call
site -- is emitted at minimax_music3_llm.cpp:582 and read by nothing. It is
closable by exactly this row's method, and this row's own run fired the span once.

F5. A "12x" sat immediately after "196.786 s ... 0.527 s", which is 373x. Both
ratios are now named with the quantity each belongs to.

F6. /v1/audio/speech goes through ApiServer::handle_audio_speech and an
internal synthesizer_ seam, not the C ABI, so calling it a thin client of these
two calls was loose. It is a second production path onto the same engine.
examples/minimax_music3_gen genuinely is a thin client. Reachability is
unaffected: include/vllm.h is independently a listed production entry point.

No device leg was re-run for this repair. The review reproduced the acceptance
criterion on hardware at the reviewed head, no finding disputes a measured value
from the lease job, and a second lease would spend a fleet device to re-derive a
number two jobs already agree on.

Scope

No performance claim is made. The second ## Owed entry -- the selector's
release_host pass-through -- stands as written; this gate asserts routing, not
residency.

Gates on the merged tree

scripts/agent-preflight.sh is 102 gates ok, 0 FAIL, 0 SKIP, rc 0, "All
gates green.", on 815ffd6fa merged onto 0043efb43. check-commit-trailers
and check-commit-style ran over the non-empty 8-commit range and both returned
rc 0; a positive control (--message-file with a bare subject) returns rc 1,
so neither passed vacuously. scripts/check-test-registration.py rc 0;
tests/scripts/test_check_test_registration.py 57 tests, OK, rc 0.

The repair touches no C++ and no CMake, so no test binary changed and the four
Music3 suites are not re-run for it; their thor:gpu0 counts above are unchanged
and remain the evidence.

Known reds not owned here: windows-msvc-* (#1829, filed by this pull request,
plus #584), macos-metal-mlx (#1823, deliberately red on main), agent-record
hugo (#1722), and test_cpu_x86_llamacpp_floor under box load (#618).

FOLLOWING_AGENTS_PROTOCOL

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

…call to the DiT arm selector (#1131) Wave 1 of this row moved the DiT arm's selection rule out of `Music3SpeechEngine` into `Music3SelectDitArm`, so that a CPU gate could drive both sides of a condition no runner CI owns can satisfy. It left one thing unreached and said so: the engine's own two-line CALL. Mutation M5 deleted that call and every suite in the tree stayed green, which is what kept #1131 open. This section states how the residual closes, before any code is written for it. The residual is not closable on a runner -- it needs an accelerator and the 28.5 GB checkpoint -- so the section names the gate, the production entry point it enters through (`include/vllm.h`), the three profile buckets it reads to say WHICH ARM RAN, the absent fourth bucket that makes those counts mean something, the CTest label that makes a device-only gate selectable rather than forgotten, and the evidence the run owes. It also states the acceptance criterion in one line, so that a reader can tell afterwards whether it was met: with the engine's call deleted, the gate reds. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [claude-code]

… selector on a real device (#1131) `test_minimax_music3_device_arm_real` drives `include/vllm.h` -- `vllm_speech_engine_load` with `device = 1`, then `vllm_synthesize` -- and asserts which arm ran from the engine's own profile buckets. It is the gate #1131 asked for, and it is the first thing in the tree that enters through the line the engine actually executes rather than through the function that line calls. It reads three instruments and one absence, because the host and device arms agree numerically by design and no property of the audio can separate them. `acoustic.dit_staging` is emitted from inside `Music3SelectDitArm` past its CPU early return, so it is present if and only if the engine's call site ran and took the device branch; that is the one that answers the residual directly. `denoise.dit_device` says the production denoise loop selected the device branch, and `dit.pack` lives inside `DitForwardDevice`, so it says the device forward's body executed and a mislabelled bucket cannot fake it. Their call counts are checked against `steps x windows` and `2 x steps x windows`, with both quantities read from counters the run itself produced rather than from constants this file could agree with itself about. `denoise.dit_host` must be absent, which is what stops the other three from being merely present. The waveform is checked only for being finite and non-degenerate, and the case says in its own text that this is a control against an arm that threw halfway, not a numerical gate. Correctness against upstream stays where it already is. The entry is labelled `gpu;checkpoint;music3` so that a gate no runner can execute is selectable by name -- `ctest -L gpu` -- rather than depending on who remembers it exists, and it exits 77 without a device or a checkpoint so CTest reports Skipped and never Passed. `docs/USAGE.md` gains the section that says how to invoke it and where, because a gate nobody runs is the defect this row is fixing. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [claude-code]

…esidual, measured (#1131) The gate this row added was run on a real device against the real checkpoint, and the deletion mutation `.agents/reachability.md` prescribes was taken on the same head. `## Owed`'s first entry is struck through and `## Outcome, wave 2` carries what was measured. Job `f63f60e8-957a-4062-92f8-54e5bbb49d92` on `thor:gpu0` inside an `rc` lease, worker `rc-worker-kk96r`, boot id `e2112cac`, unchanged end to end. NVIDIA Thor sm_110, driver 595.78, nvcc 13.0.88 installed by the job. The checkpoint was staged off CIFS onto the worker's own disk and the copy verified by bytes rather than by existence -- `SRC_BYTES == DST_BYTES == 28517617303` -- which turned a 780 s cold weight load into 8.1 s. Green: the gate at 1 / 1 cases and 22 / 22 assertions, and the four adjacent Music3 suites at 40/403, 9/223, 37/649 and 7/50, every one `SUCCESS!` with zero `[SKIP]` lines. Which arm ran is read off `acoustic.dit_staging` (1), `denoise.dit_device` (2 = steps x windows), `dit.pack` (4 = twice that, one bracket spanning both guidance branches) and the absence of `denoise.dit_host`. Red, which is the point: with the engine's call to `Music3SelectDitArm` deleted -- one hunk, `compile_rc=0` reported before any verdict -- the gate fails at `REQUIRE(staging != nullptr)`, `Status: FAILURE!`. The run did not break. It produced `denoise.dit_host` at 196.786 s where the shipped tree produced `denoise.dit_device` at 0.527 s, on 0.24 seconds of audio, with every number unchanged. That is exactly what #1131 said no gate in the tree could see. The restore is proven by an empty `git status --porcelain` at the same SHA plus a green re-run, not by a hash: this build links CUDA objects and does not link bit-reproducibly, so the restored binary hashes differently and a hash comparison would have read a correct restore as a failed one. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [claude-code]

…ote landed, and say whose it is (#1829) Found on this pull request's own `windows-msvc-cpu` job. The diff here is four files and none of them is `dots3_note`, so the break arrived from `main`: `849a7dd73` declared `[[noreturn]] static ForwardLogits ForwardDevice(...)` -- the attribute on a non-void return type -- and MSVC turns that into C4646, which warnings-as-errors makes `error C2220`. The whole `vllm` project then fails to compile on Windows. GCC and Clang accept the declaration silently, which is why every POSIX job on the same commit is green. It landed unseen because the two `windows-msvc-*` jobs are pull-request-only and `main` receives no Windows verdict at all, so the first thing to notice it is whichever branch happens to run next. That is the half worth writing down: every pull request cut from `main` since now inherits a red it did not cause and has to prove that before it can proceed. Filed rather than fixed here, with the owner named. `ForwardDevice` overrides into a registry hook and cannot simply become `void`, so the repair is a semantic choice in a file the `MODEL-MM-dots3-note` row is actively developing, and this branch has no MSVC to verify one against. The index row names that row, which is what `AGENTS.md` requires of an issue not fixed in flow. The row also says plainly that this is not the known #584. That one is the runtime `exit -1073740791` in `test_openai_api_server.exe`; a reader who stops at the job name would wave a real compile break through as the inherited runtime one. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [claude-code]

…the thor evidence still holds (#1131) `main` moved eight commits while this row's device leg was running. The merge is clean, and the two files both sides touched were checked rather than trusted: `.agents/issue-index.md` comes out as main's 660 rows plus this branch's one new row with no duplicate key and nothing lost, and `docs/USAGE.md` and `tests/CMakeLists.txt` keep this row's section and its test entry intact. **The GPU evidence was taken at `bc61ce518` and is not re-run here, because nothing in the range can touch it.** `git diff af320ab..df1ee20` leaves `src/vllm/model_executor/models/minimax_music3_*` and `tests/doctest_main.cpp` untouched. #1812's listener, which is the one arrival that could plausibly reach another suite, lives inside `tests/vt/test_ops_attention_cross.cpp` and is suite-local. Saying which range was read is the point: "still valid" is a claim about a diff, and a reader who cannot see the diff cannot check it. Merged rather than left behind so that this pull request's checks run against the base it would actually land on, including the `macos-metal-mlx` red that #1692 made visible and #1823 owns. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [claude-code]

Routine integration before landing the DiT arm reachability gate. No conflicts. FOLLOWING_AGENTS_PROTOCOL Issue: #1131 Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [Claude Code]

…hat selects the gate gets pinned The fresh review returned FAIL on six findings, and the first one is a measured statement that is false. The row's `### Restore` said the restored CUDA binary does not hash back to the baseline and generalised that into "this build links CUDA objects and its link is not bit-reproducible". The job log holds three sha256 lines for the gate binary and only two values: `ed268392...` baseline, `ce8bd1f8...` mutated, `ed268392...` restored. The row compared restored against MUTATED. The review reproduced the correct answer independently at this head on `thor:gpu0` -- `HASH VERDICT: RESTORED == BASELINE`. The generalisation is deleted rather than softened, because it is the sentence a later row would cite to waive a hash restore on any CUDA build, and nothing measured it. The `## Evidence this row owes` line it appeared to waive is marked MET on both legs. `ctest -L gpu` returns 0 over an empty selection, so the label this row adds -- and documents as the way to invoke a gate no runner can execute -- fails open. For a row whose subject is a gate that measures nothing while printing green, shipping its own discovery mechanism in that state is in scope. `scripts/check-test-registration.py` now pins the selection to the exact set `{test_minimax_music3_device_arm_real}`, read from `ctest --show-only=json-v1` over a configured tree and compared against a literal in the checker rather than against CMake text. Renaming the label on the shipped `tests/CMakeLists.txt` takes it from rc 0 to rc 1; the restored file hashes back to `9a74e857a5a8b51e23a80d23e3b73f3c3af9f0f1`. Four mutations hold it in `LabelSelectionMutationTests`, and the fixed manifest and its pinned digest move with them. `docs/USAGE.md` no longer implies a labelling convention that exists at n = 1: six sibling checkpoint suites carry no label and, unlike this one, report Passed when they skip. The depth twin gets issue #1839 before `Closes #1131` fires, because #1131 named both arms and this row closes only the DiT one. A "12x" that sat beside a 373x pair is named as the CTest wall ratio it actually is, the server's `/v1/audio/speech` route is no longer called a thin client of the C ABI, and the three instruments are no longer claimed independent on the one mutation where they are not. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [claude-code]

Bring the branch up to `origin/main` so the trailer and commit-style gates, which refuse to run when the base is not an ancestor of HEAD, can report on this tree. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [claude-code]

…mutation reds the gate (#1839) The spec's `## Outcome`, filled in from the leased run. `rc` lease on `thor:gpu0`, worker pod `rc-worker-kk96r`, boot id `e2112cac` unchanged end to end and the same pod as PR #1821's job. Release CUDA build for `110`, nvcc 13.0.88, `compile_rc=0` in 248 s, tree cloned inside the worker and asserted equal to the SHA under test. Checkpoint verified by bytes rather than by existence, `SRC_BYTES == DST_BYTES == 28517617303`. The gate is green at 1/1 · 23/23, `ar.depth_staging` 1 call, `ar.depth_device` 56 of 56 appends, `ar.depth_host` absent, and 56 / 7 depth stages = 8 appends each, which is the checkpoint's `num_codebooks` derived from the run. The acceptance criterion holds. Deleting the engine's two-line call reds it — `gate_mutated_rc=8`, 12 assertions / 11 passed / 1 failed, `Status: FAILURE!`, at `REQUIRE( staging != nullptr )` — while `test_minimax_music3_ar` 37/37 · 655/655 and `test_minimax_music3_speech` 9/9 · 223/223 stay green on the same binaries, which is #1839's recorded blindness reproduced at this head. The red is a named assertion and not a clock: neither labelled entry carries a `TIMEOUT` property, dumped from `ctest --show-only=json-v1` in the job. The restored binary hashes back to the BASELINE, not to the mutated one, and the gate re-runs green. That comparison is the one PR #1821 got wrong and corrected; this toolchain's CUDA link does reproduce, measured again here. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: Claude:claude-opus-5 [Claude Code]

… arm selector (#1839) (#1845) Closes #1839. Row `MUSIC3-DEPTH-ARM-REACH`, lane #672, spec `.agents/specs/music3-depth-arm-reachability.md`. The twin of PR #1821. #1131 named BOTH MiniMax-Music3 device-arm twins; row `MUSIC3-DIT-ARM-REACH` took the DiT one on `thor:gpu0` and #1131 went with it, leaving the depth half tracked by nothing until #1839 was filed before that merge. `.agents/specs/minimax-music3.md` §19.5 measured the gap: deleting the engine's two-line call to `Music3SelectDepthArm` leaves `test_minimax_music3_ar` 37/37 and `test_minimax_music3_speech` 9/9 green, because the 0.646B RVQ depth decoder returns to its host reference loops and produces the same song, later. §19.1 measured that stage at 48.4% of a run and a 0.646B model costing 6.3x the 8.6B language model beside it. ## The gate `tests/parity/test_minimax_music3_depth_arm_real.cpp` enters through `include/vllm.h` — `vllm_speech_engine_load` with `device = 1`, then `vllm_synthesize`. That is a production entry point by `AGENTS.md` `## Nothing lands dead`'s own list. It constructs no engine, calls no `Music3DepthStage`, stages nothing and builds no arm by hand: the only thing that may select the device arm is the shipped engine executing the line under test. ## The instrument the issue said did not exist #1839's complaint is precise and it is not only "no CI runner has a GPU". The observable §19.6's "device path TAKEN" leg rides is `Music3DepthDeviceForwardCount()`, which §19.5 itself records as unreachable from production — its only readers are the tests written for it. A counter no production run reads measures a class, not a capability. The instrument that would answer the call site, `ar.depth_staging`, was read by nothing. So `Music3DepthStage`'s append lambda gains `ar.depth_device` and `ar.depth_host`, the depth twin of `denoise.dit_device` / `denoise.dit_host`, and the record that filed #1839 already described the gate as asserting `ar.depth_staging` "with the host bucket absent" — a bucket that did not exist. `profile::Count` writes a `seconds = -1` pure counter, so it joins no leaf sum and cannot make the split's parts exceed its whole; with the instrument off it returns on one predicted branch and reads no clock. | bucket | what it answers | |---|---| | `ar.depth_staging` | the engine CALLED `Music3SelectDepthArm` and the selector took the device branch. **The direct answer to #1839.** | | `ar.depth_device` | the production append lambda SELECTED the device branch, held to `ar.depth_forward`, which brackets every append on both arms | | `ar.depth_host` | **ABSENT** — the control that makes the other two mean something rather than merely be present | **They are not independent of one another on the call-site mutation, and this says so rather than implying otherwise.** `ar.depth_device` is emitted under `device_arm.engaged()`, and an arm is engaged only through fields the selector sets, so deleting the engine's call reds both at once. `ar.depth_staging` is the most direct; `ar.depth_device` corroborates. They separate on OTHER defects, which is why both are asserted: an arm that stages and is then dropped by the loop moves the first and not the second, and a partial fallback moves the third. The body-executed question — `dit.pack`'s role in the DiT twin — is deliberately not asked here. `ar.depth_device` sits in the same branch as the `DepthDecoderAppendDevice` call it labels with nothing between them, and `test_minimax_music3_ar.cpp`'s composed-stage case already holds `Music3DepthDeviceForwardCount()` to an exact `num_codebooks` per frame. That is a class assertion in the place a class assertion belongs. Counts are arithmetic over quantities the run produced — `ar.frames`, `ar.depth_stage`, `ar.depth_forward` — never against constants written in the test. `num_codebooks` is a checkpoint property, so only divisibility is asserted and the quotient is reported. ## Both sides of the branch, from a CPU runner `test_minimax_music3_ar.cpp`'s composed-stage case is the only place in the tree where `Music3DepthStage` runs twice in one process, once with a default-constructed arm and once with an arm staged onto a CPU `vt::Queue`. The two new buckets are asserted there on both sides: `ar.depth_host` `calls == num_codebooks` with `ar.depth_device` absent, then the reverse. ## The label lane The entry carries `LABELS "gpu;checkpoint;music3"` and exits 77 without a device or checkpoint, so CTest reports **Skipped**, never Passed. `scripts/check-test-registration.py` pins `ctest -L gpu` to the exact two-name set, because `ctest -L` prints `No tests were found!!!` and returns **0** over an empty selection. Renaming the label on one of the two shipped entries takes the checker from `rc 0` to `rc 1`: ``` ERROR: ctest -L gpu selects 1 test(s) [test_minimax_music3_device_arm_real]; REQUIRED_LABEL_SELECTIONS in scripts/check-test-registration.py pins 2 [test_minimax_music3_depth_arm_real, test_minimax_music3_device_arm_real] ``` and the restored `tests/CMakeLists.txt` hashes back to `ab66e87cff5d75355096c0ad4a7eb501c5ef5c35`. The mutation suite gains `M48` for that case — a **non-empty** miss, one gate leaving the lane while the other keeps it non-empty, which is only reachable at n > 1 and which a floor cannot see — and `M44`, `M45` and `M47` now mutate both entries so the empty-selection case they exist for is still the case they measure. 57 to 58 cases, `OK`, 0 skipped. ## Local gates, CPU-only Release | suite | test cases | assertions | Status | `[SKIP]` | |---|---|---|---|---| | `test_minimax_music3_ar` | 37 / 37 passed | 655 / 655 passed | SUCCESS! | 0 | | `test_minimax_music3_speech` | 9 / 9 passed | 223 / 223 passed | SUCCESS! | 0 | | `test_music3_profile` | 7 / 7 passed | 50 / 50 passed | SUCCESS! | 0 | | `test_minimax_music3_acoustic` | 40 / 40 passed | 395 / 395 passed | SUCCESS! | 0 | `test_minimax_music3_ar` is 655 against 649 on `origin/main`: the six new assertions, three per side of the branch. `test_minimax_music3_depth_arm_real` exits 77 on this build with the refusal quoted and CTest reports it **Skipped**. `scripts/agent-preflight.sh`: **100 gates `ok`, 0 FAIL, 0 SKIP, rc 0**, "All gates green." `check-commit-style` and `check-commit-trailers` both `rc 0` over the non-empty merge-base range; a detached scratch commit with a trailing-period subject and no body takes both to `rc 1`, so neither passed vacuously. `scripts/check-test-registration.py` `rc 0`. ## Measured on thor:gpu0 Inside an `rc` lease, 2026-08-24 08:38:37Z-08:44:56Z. Worker pod `rc-worker-kk96r`, boot id `e2112cac-660b-434e-911d-33cbd29b9176`, unchanged end to end and the same pod and boot as PR #1821's job, so the box has not rebooted between the twins. NVIDIA Thor `compute_cap 11.0`, driver 595.78, nvcc 13.0.88 installed by the job, Release CUDA build for `110`, `configure_rc=0`, `compile_rc=0` in 248 s. Tree cloned inside the worker and asserted equal to `9649a4c12903547cbe362369c9db7689c01fb3eb` before anything was built (`clean_tree=yes`). The **`rc` job UUID is UNVERIFIED** — the client header scrolled out of a `tail` and `rc ps` lists only live jobs — so the run is identified by device, submitter string, pod, boot id, the UTC window and `/mnt/nas_share/rc/m3depth/out/job.log`. Recorded as missing rather than guessed. The first submission was **refused by its own disk guard** (78 GiB free against `NEED_GB=110`, exit 95, device untouched) and that log is kept beside the run. The checkpoint was read from `/tmp/m3reach-ckpt` on the worker's overlay, which PR #1821's job staged on this same pod; reused is not trusted, and the same hard `SRC_BYTES == DST_BYTES == 28517617303` comparison a fresh copy gets was applied, with `findmnt` printed for the NAS source and for the path actually read. | suite | test cases | assertions | Status | `[SKIP]` | |---|---|---|---|---| | `test_minimax_music3_depth_arm_real` | 1 / 1 passed | 23 / 23 passed | SUCCESS! | 0 | | `test_minimax_music3_device_arm_real` (PR #1821's gate, control) | 1 / 1 passed | 22 / 22 passed | SUCCESS! | 0 | | `test_minimax_music3_acoustic` | 40 / 40 passed | 403 / 403 passed | SUCCESS! | 0 | | `test_minimax_music3_speech` | 9 / 9 passed | 223 / 223 passed | SUCCESS! | 0 | | `test_minimax_music3_ar` | 37 / 37 passed | 655 / 655 passed | SUCCESS! | 0 | | `test_music3_profile` | 7 / 7 passed | 50 / 50 passed | SUCCESS! | 0 | `ctest -N -L gpu` selected exactly `#70` and `#71`, so the pin is the tree's behaviour and not a declaration. `device 1 resolves to 'cuda'` and `vllm_speech_engine_device()` returned 1, so this is the granted arm. `ar.depth_staging` 1 call / 1.149 s, `ar.depth_device` 56, `ar.depth_forward` 56, `ar.depth_host` **absent**; `ar.frames` 6, `ar.depth_stage` 7, and 56 / 7 = 8 appends per stage, the checkpoint's `num_codebooks`, derived from the run rather than written into the test. ## The acceptance criterion Delete the production call site and rerun the focused gate (`.agents/reachability.md`). One hunk, `mutation_applied=1`, `git diff --stat` 1 file / 2 insertions / 2 deletions, and **`compile_rc=0` reported before any verdict**. ```diff Music3DepthDeviceWeights staged_depth; - const Music3DepthDeviceArm depth_arm = Music3SelectDepthArm( - queue_, ar.depth_config, ar.depth, /*release_host=*/true, &staged_depth); + const Music3DepthDeviceArm depth_arm; // MUTATION #1839: the engine's CALL deleted + (void)staged_depth; ``` **RED**: `gate_mutated_rc=8`, 1 case / 0 passed / 1 failed, 12 assertions / 11 passed / 1 failed, `Status: FAILURE!`, CTest `***Failed 19.07 sec`, at `test_minimax_music3_depth_arm_real.cpp:295: REQUIRE( staging != nullptr )`. **The red is a named assertion and not a clock.** Neither labelled entry carries a `TIMEOUT` property — dumped from `ctest --show-only=json-v1` inside the job, `HAS_TIMEOUT=False` for both — and `vllm_cpp_add_test` still sets only `SKIP_RETURN_CODE 77`. The one case-insensitive `timeout` match in the mutated log is CTest's own `Test timeout computed to be: 10000000`, its no-timeout sentinel; the grep was read rather than counted, because a count of 1 would otherwise be indistinguishable from a real timeout. **And what the red is made of is the argument.** The mutated run did not fail, break or produce different audio. `ar.depth_staging` and `ar.depth_device` went absent, `ar.depth_host` appeared at 56, `ar.depth_forward` went 0.327 s to 5.446 s over the same 56 calls and `ar.depth_stage` 0.519 s to 5.591 s, while `acoustic.dit_staging` 1 and `denoise.dit_device` 2 were unchanged — which is what says the mutation is scoped to the depth call site rather than disabling the accelerator. **No performance claim is made** and the ratios are named with the quantity each belongs to: the `ar.depth_forward` bucket is **16.7x**, the `ar.depth_stage` span **10.8x**, and the CTest wall for the whole gate **1.23x** because the run loads 28.5 GB either way. On **0.24 seconds** of audio, from a change that alters no number anywhere. **And the tree stayed green.** Under the identical mutation `test_minimax_music3_ar` is 37/37 · 655/655 `SUCCESS!` and `test_minimax_music3_speech` 9/9 · 223/223 `SUCCESS!` — #1839's recorded blindness, reproduced at this head, on the same binary set that reds the new gate. **Restore: the binary hashes back to the BASELINE.** `git status --porcelain` empty at the same SHA, `compile_rc=0`, `RESTORED_BINARY_SHA256` and `BASELINE_BINARY_SHA256` both `1f8e424f611ab9973fc529798565f5b3649c9ce1ed4d50d06ebbfbc23aeac8e4` against the mutated `9296b268...`, and the gate re-ran 1/1 · 23/23 `SUCCESS!`. The comparison is against the baseline and never against the mutated binary, which is the mistake PR #1821 made and corrected: this toolchain's CUDA link **does** reproduce, measured here on the same box. ## The CPU-side instrument has teeth too Deleting `profile::Count("ar.depth_device", 1)` from the production lambda — `mutation_applied=1`, `hunk_count=1`, `compile_rc=0` before the verdict, mutated binary `0fe1524bad50e28d...` against baseline `58342939c4c72f58...` — takes `test_minimax_music3_ar` to 37 / 36 passed / 1 failed, 635 / 634 / 1, `Status: FAILURE!` at `test_minimax_music3_ar.cpp:1813: REQUIRE( device_bucket != nullptr )`. Restored: porcelain empty, binary back to `58342939c4c72f58...`, suite back to 37/37 · 655/655. ## Scope No performance claim is made. The `release_host` pass-through on the depth selector's device path is `MUSIC3-DEPTH-DEVICE`'s and is unchanged; the DiT arm's own residual is `MUSIC3-DIT-ARM-REACH`'s and is unchanged. Known reds not owned here: `windows-msvc-*` (#584, #1829), `macos-metal-mlx` (#1823), `agent-record` hugo (#1722), `test_cpu_x86_llamacpp_floor` under box load (#618), and `build-test-cpu-arm64-full`'s pre-existing undefined `ApiServer::*` references. FOLLOWING_AGENTS_PROTOCOL Following-Agents-Protocol: true AI-Assisted: true Assisted-by: Claude:claude-opus-5 [Claude Code] --------- Co-authored-by: Ettore Di Giacinto <mudler@localai.io>

mudler added 3 commits August 23, 2026 21:47

localai-bot mentioned this pull request Aug 23, 2026

dots3-note's [[noreturn]] on a non-void ForwardDevice breaks the Windows MSVC build on main (C4646/C2220), and Windows has no main baseline to have caught it #1829

Closed

localai-bot closed this Aug 24, 2026

localai-bot reopened this Aug 24, 2026

mudler added 2 commits August 24, 2026 01:33

merge: origin/main into row/MUSIC3-DIT-ARM-REACH

7185466

Routine integration before landing the DiT arm reachability gate. No conflicts. FOLLOWING_AGENTS_PROTOCOL Issue: #1131 Following-Agents-Protocol: true AI-Assisted: true Assisted-by: AGENT:claude-opus-5 [Claude Code]

localai-bot mentioned this pull request Aug 24, 2026

MiniMax-Music3: the engine's call to Music3SelectDepthArm is reachable but not gated — the depth twin #1131 leaves open (#672) #1839

Closed

mudler added 2 commits August 24, 2026 04:16

localai-bot merged commit 404f0cd into main Aug 24, 2026
3 of 17 checks passed

localai-bot mentioned this pull request Aug 24, 2026

test(MUSIC3-DEPTH-ARM-REACH): gate the engine's own call to the depth arm selector (#1839) #1845

Merged

Navigation Menu

test(MUSIC3-DIT-ARM-REACH): gate the engine's own call to the DiT arm selector on a real device (#1131) - #1821

test(MUSIC3-DIT-ARM-REACH): gate the engine's own call to the DiT arm selector on a real device (#1131)#1821
localai-bot merged 8 commits into
mainfrom
row/MUSIC3-DIT-ARM-REACH

localai-bot commented Aug 23, 2026 •

edited

Loading

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

localai-bot commented Aug 23, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

The gate

Measured on thor:gpu0

The acceptance criterion

The review's findings, repaired

Scope

Gates on the merged tree

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

localai-bot commented Aug 23, 2026 •

edited

Loading