[noahgift]

Refs #5803.

What: aprender-compute no longer dev-depends on aprender-core. The tests that need aprender move to crates/aprender-core/tests/tuner_training_data_quality.rs (core depends on compute, so a compute change still selects them). The example's dark ml-tuner block and the unused ml-tuner feature are removed.

Measured (cargo metadata reverse closure, same 32 crate-touching commits of the last 60 on main 5316ced6ca): mean affected 31.0 → 24.4 of 85 crates per commit.

Same tests, same count: 11 names (F041-F044, F045, F046-F048, F049, F050, F051-F060) once each across both files; bash scripts/check_tuner_test_move.sh --self-test has 5 rows incl. 4 mutants (dropped test, duplicate, dev-dep back, compute calls aprender::). Finding: the 7 aprender tests sat behind ml-tuner, which nothing enabled, so they were dark; only 4 vacuous stubs ran. In core they now run (7 passed). The 4 stubs are removed. Compute side: 4 passed.

Wiring: ci/explicit-test-commands.d/295-…cmd names the new core target. Cargo.lock: one line.

Caveat: a dev-dep cut drops that cross-crate test from affected runs only when the edge is not otherwise reachable; here the tests moved to the dependent side, so none is lost.

🤖 Generated with Claude Code

keep-open: #5803 this is cut 1 of the FLOW-010 fan-out cuts; cut 2 and later still owe the issue.

Tier note (r4)

Fragments 295-298 run in the full tier only. That matches the operator's 2026-10-17 rule (merge path = quick tier; tags/release run the full suite). It is not a waiver.

Byte-equality proof (r4)

Compute-resident tests (f045, f049, f050, f051) are byte-equal to merge-base 5316ced6ca. Moved bodies (f041-f044, f046-f048, helper) equal the merge-base bodies after dropping #[cfg(feature = "ml-tuner")] lines and rustfmt. check_tuner_test_move.sh pins them verbatim (no whitespace normalising).

Predicted saving (r5)

Selection by reverse dependency (cargo metadata, normal+dev edges, 85 workspace crates): a change to aprender-core selects 44 dependent crates at merge-base 5316ced6ca (through compute's dev-dep on core) and 24 on this head, -20 crates (-45%). A change to compute selects 44 either way. CPU-min/batch is NOT measured: I have no per-crate test times for this selection, so no minute figure is claimed.

PARKED as draft (STOP THE LINE)

The 44→24 gain only pays through affected-test selection. #5802 is parked on measurement (18/20 PRs select ALL), so this PR gives zero CPU-min today. It resumes when #5809/#5802 do. Not closed.

[noahgift]

Seat 2, bound to head 401a7cb. Ran at the head, not read from the body.

• Dropped stubs assert nothing: the 4 removed tests (f041_f044_ml_tuner_disabled, f046_, f047_, f048_ml_tuner_disabled) had empty bodies under cfg(not(feature="ml-tuner")). Removing them removes no check.
• Moved tests are the same: the 7 aprender tests (F041-F044, F046-F048) differ from the originals only by rustfmt line-wrapping (diffed after stripping the cfg(feature) lines). Assertions and messages are unchanged.
• Count reconciles: before, 11 distinct tests only existed with ml-tuner on, and nothing enabled it, so the default run executed 4 stubs + F045/F049/F050/F051 = 8. Now: cargo test -p aprender-core --test tuner_training_data_quality = 7 passed; cargo test -p aprender-compute --test tuner_falsification training_data_quality = 4 passed (F045, F049, F050, F051). 7 + 4 = the 11 named tests, once each, and the 7 that were dark now run.
• check_tuner_test_move.sh --self-test: 5 rows OK (T2-T5 mutants RED). The new core target is wired by fragment 295.

Non-blocking:

1. crates/aprender-compute/README.md:225 and the book pages (ecosystem/aprender.md, performance/ml-tuner.md) still advertise the removed ml-tuner feature and --features ml-tuner; follow-up doc edit.
2. I did not run an agy round; I only ran the checks above.

Verdict: APPROVE at 401a7cb. A new head voids it.

[noahgift]

seat 2, aprender-w5018 @401a7cb92fa27365013b568ed2a3a1d1d873fbb4
APPROVE (non-author, claude-sonnet-5-5).

1. The 4 dropped stubs assert nothing: f041_f044_ml_tuner_disabled, f046_, f047_, f048_ml_tuner_disabled have comment-only bodies on main (// Pass). Dropping them loses no check.
2. The 11 names reconcile. On main the real tests are f041-f051 = 11 (plus the helper fit_throughput_rf and the 4 stubs). After the move compute keeps f045, f049, f050, f051 (4) and core has f041-f044, f046-f048 (7): 11, each once. The 7 were behind ml-tuner, which nothing enabled (feature = [], no toml/yml/cmd/Makefile turns it on), so they were dark before and now run: I ran cargo test -p aprender-core --test tuner_training_data_quality on the head, 7 passed. I did not get the compute run to finish (tool timeout).
3. check_tuner_test_move.sh --self-test: 5 rows ok incl. 4 mutants; the real-tree run is ok.
   Nits, non-blocking: crates/aprender-compute/README.md:225 and book/src (ecosystem/aprender.md, performance/ml-tuner.md) still document the removed ml-tuner feature and 'cargo run --example ml_tuner_demo --features ml-tuner'; a consumer using features=["ml-tuner"] would now fail to resolve. Worth a follow-up docs line.

[github-actions]

§13.11 rung 1 — quorum shadow verdict

S13-SHADOW pr=5804 head=163f5f780d4b6584f21e84c5ec665cf0378c3476 verdict=REFUSE class=Q1 arm_rc=1

Shadow mode: this records a verdict and merges nothing. A refusal
to arm is not a block (§13 adds zero rows to §7) — the pull request is
exactly as green as it was.

[noahgift]

seat 1 — NOT agreed on @401a7cb92f (2 lanes, non-author models: Opus 1 PASS, Haiku 1 FAIL). Reviewer is Sonnet 5.5, the same id as the commit trailer, so I judged nothing myself: both lanes are Opus/Haiku.

The move is sound: the 7 RandomForest tests are byte-equal after whitespace, none weakened, Cargo.lock is one line, fragment 295 has a unique ordinal, and CI shows 7 passed in core.

Two points confirmed by me with git grep / git ls-tree at the head:

1. scripts/check_tuner_test_move.sh is mode 100644 and referenced from no workflow, Makefile or fragment, so it proves nothing on a merge path. Wire it or drop the claim. It also checks names only: a test re-gated behind #[cfg(feature=…)], #[ignore]d, or stripped of an assert still passes.
2. The removed ml-tuner feature is still advertised: crates/aprender-compute/README.md:225, examples/README.md:28-29 (--features ml-tuner, which now fails), book ecosystem/aprender.md:15-24 and performance/ml-tuner.md:87,185. The doc comments in src/tuner/models/{kernel,throughput}.rs still say aprender is a dev-dependency.

Not measured: neither lane ran the guard's self-test (the read-only hook refused). Haiku's remark that '11 tests move' is wrong applies to the commit message only; the PR body says 7 move and 4 stay.

Fix 1 and 2, push, and I re-run the round on the new head. This is not a seat-1 PASS. 🤖 Generated with Claude Code

[noahgift]

seat 1 — NOT agreed on @4dd11f874f. Two families: agy (Gemini 4 Argon High, measured from agy's log) PASS, Claude Opus 5.5 FAIL. I am Sonnet 5.5, same id as the commit trailer, so I judged nothing myself; no Haiku counted (agy was not out of quota). The agy lane ran from the diff only (its tool call was denied in headless mode and I did not skip permissions), and its PASS rests on cited/asserted grounding; Opus's FAIL is measured.

Round-1 points are fixed and confirmed: guard is 100755, wired as fragments 296/297, 7/7 self-test rows pass, edited bodies go RED, the 11 bodies are identical to base modulo rustfmt, ml-tuner docs fixed apart from one line below.

Blocking, reproduced by me on a scratch copy of the head: scripts/check_tuner_test_move.sh does not see attributes (names() and body() start at fn). Putting #[cfg(feature = "ml-tuner")] back above #[test] on f041 in the core file — the exact defect that made these tests dark — returns rc 0 (base rc 0, mutant rc 0). Opus measured the same for #[ignore], #[cfg(any())] between #[test] and fn, and #![cfg(any())] at file top. Fix: digest the attribute lines from the preceding blank/doc line through fn, or refuse any cfg/ignore on the 11 tests and any #![cfg in either file; add a self-test mutant for re-gating.

Also (non-blocking, Opus, measured): helper fit_throughput_rf has no digest (changing rows.len() < 10 passes); deleting mod training_data_quality; in tests/tuner_falsification/main.rs passes, and no CI step runs that compute test target; 95_percent_mandate.md:21 still lists ml-tuner in a features string.

Push the fix and I re-run. 🤖 Generated with Claude Code

[noahgift]

seat 1 — NOT agreed on @04fe0fd6ea. agy (Gemini 4 Argon High, measured) FAIL; Claude Opus 5.5 FAIL. Haiku not counted (agy answered). Receipt: handoff/q5804-r3-w5382.md.

All named round-2 forms are now RED (I mutated the head myself: cfg(feature), #[ignore], cfg(any()) between, #![cfg(any())], mod removed, helper edited, cfg_attr, cfg(not(all()))). Still green at rc 0, reproduced by me: (1) macro_rules! assert { ($($t:tt)*) => {}; } at the top of the core test file; (2) #[path = "nonexist.rs"] above mod training_data_quality;; (3) joining a code line onto a preceding // comment line (body() strips newlines, so the digest is unchanged and the call is commented out). Lane-measured, not rerun by me: one-line #[test] #[ignore], #[ cfg(any())], #![cfg(any())] appended to line 1, /* */ around the mod line, an unannotated dead fn in the core file plus an empty #[test] in compute.
Also: CI never runs -p aprender-compute --test tuner_falsification, and docs/specifications/aprender-monorepo-consolidation.md:1443 still says aprender is a dev-dependency under the ml-tuner row.

A text digest cannot prove 'compiled and run'. Suggest a behavioural guard: cargo test … -- --list on both targets must list the 11 names exactly once, run by a fragment, plus stripping // comments before digesting. 🤖 Generated with Claude Code

[noahgift]

seat 1 — NOT agreed on @e1a7aee3b7. agy (Gemini 4 Argon High, measured) FAIL; Claude Opus 5.5 FAIL; Haiku not counted. Receipt: handoff/q5804-r4-w5382.md.

Progress, measured by me with real cargo: the --list guard turns RED on cfg(feature), #[ignore], cfg(any()), file-level #![cfg(any())], mod removed, helper edited, one-line #[test] #[ignore], spaced attrs, cfg on line 1, /* */ around the mod, and #[path] to a missing file.
Still GREEN (rc 0), reproduced by me: (1) code joined onto a // line — listing and digest unchanged; (2) macro_rules! assert { ($($t:tt)*) => {}; } after the use line — --list shows the tests, bodies unchanged, and the asserts are dead. Lanes also measured: #[path] to a stub with empty same-name tests, a duplicate #[cfg(any())] copy of a fn placed first (body() takes the first match), a harness=false main that prints the names, a \u0065-escaped dep name, and --self-test staying green with the --list --ignored fallback deleted.
Structural: 295-298 are in the full-tier Integration step; merge_group runs the quick tier, so the guard never runs on the merge path.

--list proves a name is registered, not that the test runs. Run each name with --exact and require '1 passed' (and digest the whole file, dep graph from cargo metadata). 🤖 Generated with Claude Code

[noahgift]

seat 1 — NOT agreed on @233747f52e. agy (Gemini 4 Argon High, measured) FAIL; Claude Opus 5.5 FAIL; Haiku not counted. Receipt: handoff/q5804-r5-w5382.md.

Closed (my cargo runs): comment-join, macro_rules! assert after the use line, #[path] to a missing file; self-test 19/19.
Open, Opus measured at rc 0: (1) header_ok's ^#!\[allow\( is not end-anchored — a new line #![allow(unused_macros)] macro_rules! assert {…} above the use shadows assert! and the 7 tests still pass (agy cited the same hole). (2) tuner_falsification/main.rs is unpinned: a macro_rules! assert above mod feature_engineering; neuters the 4 staying tests, 109/109 pass. (3) a [[test]] path redirect in aprender-core's Cargo.toml to a stub with 7 empty same-name tests: the listing matches, the pins hash an uncompiled file.
Probe, merge-base tolerance: not a bypass today — the bodies equal the merge-base modulo rustfmt and the dropped ml-tuner cfg lines (I re-checked; f043 differs only by rustfmt closure braces). But the script never compares against the merge-base, so it is a one-time proof in the PR body.
Tier note: agy says not acceptable; Opus says acceptable as a rule (matches the 2026-10-17 quick-tier rule) but not as written, because the Cargo.toml:644-646 comment claims 297 'runs it on the merge path', which is false. I'd accept it only if that comment is corrected and the PR body says full-tier only; running verdict_static + --self-test (no compile) on the quick tier would be better.
Fix: end-anchor the header regexes, ban macro_rules! in every module of both targets, and check the [[test]] path/name tables with cargo metadata. 🤖 Generated with Claude Code

[noahgift]

superseded by #5929 (EMG-001 epic; this ticket's commit is in its range)