test(aprender-train): H1 falsifiers FALSIFY hypothesis A at unit-test level (PMAT-CODE-PRETRAIN-EVAL-METHODOLOGY-001)

[noahgift]

Summary

Two CUDA-gated falsifier unit tests in pretrain_real_cuda.rs::tests that probe the H1 (eval_batch degenerate) hypothesis surfaced by PR #1580's evidence (1500× train/val discrepancy at the same model state, post H2-fix).

Both tests PASS on lambda-vector RTX 4090, EMPIRICALLY FALSIFYING H1 hypothesis A (logits_buf train→eval state pollution at the unit-test level).

What this PR ships

Test	Probes	Result
falsify_eval_batch_h1_sanity_bound	eval_batch on fresh-init returns loss ∈ [0.5, 1.5×ln(vocab)]	✅ PASS (~6.91, theoretical)
falsify_eval_batch_h1_train_pollution	eval_batch loss after train_batch doesn't collapse by ≥95%	✅ PASS

Both tests are CUDA-gated (#[cfg(feature = "cuda")]) so default CI doesn't see them. Operator runs:

cargo test -p aprender-train --features cuda --lib falsify_eval_batch_h1

Hypothesis status update

Sub-hypothesis	Pre-this-PR	Post-this-PR
H1A (logits_buf train→eval pollution)	OPEN suspected	FALSIFIED at unit level
H1B (stream synchronization)	OPEN	OPEN (not tested)
H1C (held-out label corruption)	OPEN	OPEN (not tested)
H1 at production scale	OPEN	OPEN (needs integration test)

H1A falsification narrows the hypothesis space. The production bug must require something not present in the unit-test reproducer:

• real Qwen 0.5B model size + weights (vs tiny random-init)
• real seq_len=512 batches (vs 16)
• real Python tokens (vs LCG random)
• many train steps (state accumulation)

Why ship GREEN falsifiers if they don't reproduce the bug?

The tests still prove H1A is FALSIFIED at unit level — that's a real positive contribution to hypothesis decomposition. Per feedback_falsifier_first_cascade_pattern.md: 1 PR ≈ 1 falsifier discharge. "H1A falsified at unit level" IS a discharge.

The production-level bug needs a different reproducer (probably a smaller-but-real-Qwen integration test). That's tracked as a follow-up in PMAT-CODE-PRETRAIN-EVAL-METHODOLOGY-001.

Five-Whys

1. Why ship GREEN falsifiers? They falsify H1A at unit level — narrows the hypothesis space.
2. Why two tests instead of one? 001 = simplest sanity bound; 002 = direct H1A probe (train→eval pollution).
3. Why CUDA-gated? CudaTransformerTrainer::new requires CUDA runtime; default CI sees the gated-out stub.
4. What does this NOT cover? H1B (stream sync), H1C (held-out content), H1 at production scale.
5. Why ship now vs wait for fix? PR atomicity. Each falsifier outcome (PASS or FAIL) is its own discharge. Shipping the negative result NOW preserves the discovery.

Test plan

• cargo test -p aprender-train --features cuda --lib falsify_eval_batch_h1: 2/2 PASS on RTX 4090
• cargo test -p aprender-train --lib (default features): tests gated out, no CI breakage
• rustfmt --check: clean
• cargo clippy -p aprender-train --lib -- -D warnings: clean

SHIP-TWO impact

• MODEL-1 ship %: unchanged at 91% (this is MODEL-2 work)
• MODEL-2 ship %: unchanged at 57% (H1 still open at production scale)
• §50.4 cascade: COMPLETE per feat: §50.4 step 5f.5 CUDA --init wireup (PMAT-CODE-PRETRAIN-INIT-CUDA-WIREUP-001) #1577
• 5g.2 dispatch: OPERATOR-RUNNABLE; HONEST 5g.3 verdict still gated on H1 resolution at production scale

Out-of-scope follow-ups

• H1 at production scale: integration test with smaller-but-real Qwen checkpoint + real Python tokens
• H1B stream-sync probe: deliberate kernel-failure injection
• H1C held-out content audit: dump first 16 batches of 5g.1 corpus for pathological patterns

Files

• crates/aprender-train/src/train/pretrain_real_cuda.rs (+207 lines, two new falsifier tests)

🤖 Generated with Claude Code