Module scheduler_bench 

The scheduler oracle’s driver: run a real Study with a scheduler over synthetic curves and record exactly what it pruned.

This is the other half of the M3.2 gate (docs/design/09-implementation.md §12). Where harness drives the sampler seam, this drives the whole study loop — because a scheduler is only ever consulted through TrialCtx::report, inside the objective’s inner loop (docs/design/03-architecture.md §3.2). So the oracle must run the real loop, let the objective stream a LearningCurve step by step, and honour the prune signal the loop returns.

Why the study loop works here without the system feature

Study::optimize at the default parallelism(1) spawns no threads and catches no panics — the wasm-clean path (docs/design/09-implementation.md §4) — so the whole driver runs against atune_core with default features off, exactly like the rest of this crate. Single-worker is also what makes the pruning deterministic: a scheduled study is replayable, not pre-determined under parallelism (its prunes depend on completion order), but under one worker with a fixed seed the completion order is fixed, so the whole pruned set is reproducible (docs/design/09-implementation.md §5).

How a trial is bound to a curve

The objective reads ctx.meta().number and evaluates curves[number]. Trials complete in number order (one worker, no queue), so trial i is curves[i] and completes before trial i + 1 — which is what makes the competitor set a scheduler sees at each decision point knowable, and the whole scenario hand-verifiable.

Structs

BenchReport

The result of driving a whole scenario through one scheduler.

TrialOutcome

What one trial did under the scheduler.

Functions

run

Runs scheduler over curves and records what it pruned.