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

[localai-bot]

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.

     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]