Per spec §6.6 / Q6 train/dev/test split (defaults Q1-Q7 train, Q8 dev,
Q9 sealed final test):
- DQNHyperparameters: holdout_quarters + dev_quarters (default 1+1)
- crates/ml/examples/train_baseline_rl.rs: --holdout-quarters /
--dev-quarters CLI flags forwarded to hyperparams (this is the actual
training binary; bin/fxt/src/commands/train.rs is a gRPC client and
services/ml_training_service/src/main.rs accepts training params via
proto not CLI — see audit doc note).
- DQNTrainer::train_walk_forward slices training_data BEFORE fold
generation; folds run on Q1..Q(9 - holdout - dev) only.
- DQNTrainer struct: dev_features/dev_targets/holdout_features/
holdout_targets fields stash trailing slices for end-of-training dev
eval and the Phase 4.3 separate eval-only workflow.
- debug_assert sealed-slice guard catches future refactors that
re-introduce holdout into the training path.
Per established Phase 1 precedent (1.1-1.5: kernel/state lands first,
consumer wiring deferred to follow-up commit per
feedback_no_partial_refactor): CLI plumbing + slicing + dev/holdout
storage land in this commit. The post-final-fold dev evaluation call
(consumer of dev_features) is deferred to a follow-up commit and will
mirror Task 1.7's evaluate_dqn_graphed integration pattern. Phase 4.3
argo-eval-final.sh is the sole legitimate consumer of holdout_features
(separate eval-only workflow that does NOT call train_walk_forward).
cargo check -p ml --features cuda --example train_baseline_rl: clean
cargo check -p fxt: clean (no fxt changes needed; gRPC client only)
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
ce019c72d2