Define and validate a run plan

An experiment plan is input to the runner. Validate the whole plan before any run can create evidence.

Goal

Load an ordered list of configurations and reject duplicate names, unsafe run identities, and invalid numerical settings before execution begins.

Inputs

Use plans/baseline.json and the configuration rules in the project overview. The plan is a JSON list of objects with run_name, seed, scale, offset, and noise_bound. Keep the order supplied by the reader; it becomes the order recorded in the root manifest.

Test plans should include a valid plan, a duplicate name, an unsafe name with path syntax, a name that is too long or otherwise malformed, and each kind of invalid number. A non-finite number includes NaN and positive or negative infinity.

Deliverables

Implement src/config.py with a loader and validator that returns a normalized ordered plan or a clear validation result. Record the accepted configuration schema and a validated plan record in report.md or a stable plan artifact.

The validator must preserve the numeric values needed by the supplied computation. It may normalize JSON types, but it must not silently clamp, round, rename, or repair an invalid value.

Checks

Check that a valid plan preserves order and that duplicate names are rejected case-sensitively according to the documented name rule. Reject absolute paths, .., separators, empty names, names outside the length limit, invalid seeds, out-of-range values, and non-finite numbers.

Prove that an invalid plan is refused before the first run directory is created. The error should identify the plan entry and field without exposing a traceback as the learner's only explanation. Check that a valid plan cannot select a directory outside runs/.

Workspace

Implement validation in src/config.py. Keep plan loading separate from run execution; src/main.py will call the validator before it calls the runner. Use plans/ for supplied or reader-created plans and reserve runs/ for generated evidence.

Hints

Review

Try each invalid fixture and read the resulting message. Confirm that the validator reports the offending field, that it does not change a valid value, and that no partial plan is passed to execution. Explain why accepting one valid entry before rejecting a later entry would make the runner harder to audit.

How to check your work

Checks compare the validator with the supplied fixture. The fixture demonstrates the schema boundary and failure vocabulary; it is not permission to broaden the accepted input.