docs(24_miracle): document and verify research lifecycle - #15

Process completed with exit code 1.

The legacy flow runs and writes baseline validation results and copies the rank09 validation opponent before invoking Codex. `workspace-write` limits writes but is not a read-isolation boundary%2C so the coding agent can inspect sibling session files%2C validation artifacts%2C opponent source%2C or the external AgentBench root despite the prompt saying not to. This contaminates the held-out validation set and makes the claim that only training evidence is exposed false. Suggestion%3A Do not materialize or run validation assets until after learning%2C and execute the provider in an OS-level sandbox whose readable filesystem is allowlisted to only `main.py` and approved training evidence. Add a test that attempts reads of validation/session/AgentBench paths and verifies they are denied.

The `--legacy-smoke` dispatch bypasses every approval/preflight boundary and directly starts real Judge/opponent processes plus a Codex provider. An ordinary CLI flag therefore re-enables exactly the runtime execution that this tool and protocol claim remains blocked%2C creating an unreviewed process and scientific-evidence path. Suggestion%3A Remove the executable legacy route from this production preflight tool%2C or require the same independently approved manifests and runtime authorization as the normal lifecycle before any process or output directory is created. Preserve historical code only as inert documentation or in a separately quarantined tool that cannot be mistaken for an approved run path.

Node.js 20 is deprecated. The following actions target Node.js 20 but are being forced to run on Node.js 24: actions/checkout@v4. For more information see: https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/

The Results integration test silently substitutes the vendored historical aggregate whenever the configured Results checkout lacks `aggregate.py`%2C while still using that checkout's `report_builder.py`. A partial or incompatible Results checkout can therefore pass against a component combination that does not exist in Results%2C contrary to the stated exact cross-repository integration boundary. Suggestion%3A Require both aggregate and report builder from the same configured Results checkout for integration tests and skip or fail with an explicit dependency reason if either is absent. Test the vendored aggregate separately as historical compatibility evidence.