Audit a proposed scientific research environment in the T0-RSI/ai4sci-tasks repository.

TRACK_PATH: <replace with the top-level track directory>

Read the current root TASK_STANDARD.md and CONTRIBUTING.md first. Then inspect this track's code, configuration, documentation, data preparation, reference methods, submission contract, and verifier. Treat the current repository standard as authoritative and explain any documented exceptions.

Review these areas:

1. Scientific task
   - Is the problem fundamental or consequential in its scientific field?
   - Are the inputs, algorithmic objective, deliverable, metric direction, and scientific value clear?
   - Is there room for methodological improvement and a meaningful generalization test?

2. Required components and workspace
   - Check README.md, task.toml, instruction.md, environment/Dockerfile, environment/docker-compose.yaml, environment/contract.md, environment/data/, environment/baseline/, environment/references/, environment/evaluation/, tests/, and docs/ against the standard.
   - Verify the five instruction sections, eight developer README sections, declared artifact path, schema version, authors, and operator variables.
   - Resolve every copied or mounted /workspace path. Check read-only development data, a fresh writable research directory, and atomic publication at /workspace/submission.
   - Keep development budget and GPU counts out of the instruction. Check task.toml owns network and GPU configuration; agent compose must not redefine these.
   - Confirm agent and verifier are offline except for the controller-allowlisted agent model API. Do not add a task-specific runner or credentials.

3. Data and materialization
   - Can another machine reconstruct the data from documented upstream or licensed raw sources, without an author's private cache or hardcoded host paths?
   - Check materialize.sh, MATERIALIZE.md, configurable destinations, pinned revisions, integrity checks, expected layout, access requirements, and safe reruns.
   - Audit train/development/held-out split generation, seeds, duplicate or entity overlap, and relevant upstream or pretrained-data contamination. State known limits.
   - For simulation tasks, check simulator version, parameter ranges, seeds, validity constraints, and separation of development and evaluation conditions.
   - Flag unavailable resources and distinguish scaffolds, synthetic smoke fixtures, and verified data.

4. Contract and portability
   - Check the entry point, input/output schemas, ID mapping, arbitrary valid case counts and ordering, inference resources, and allowed training or pretrained assets.
   - Verify the graded artifact is a portable model or algorithm package with code, weights where needed, configuration, preprocessing, and all inference dependencies.
   - Check it can run after relocation, offline, on unseen valid inputs, without the training workspace, an undocumented cache, or hardcoded test IDs.

5. Evaluation correctness and isolation
   - Verify development and independent scoring use consistent metrics, aggregation, random seeds, and failure handling.
   - Check independent replay runs the submitted package rather than trusting a self-reported score or a predictions-only artifact.
   - Check tests/test.sh writes /logs/verifier/reward.json with raw metrics and the standard reward, or a documented permitted multi-metric exception.
   - Audit missing outputs, malformed shapes, non-finite values, invalid candidates, timeouts, failed-case denominators, and distinct infrastructure failures.
   - Verify private targets and label-bearing scorer internals are inaccessible to both the agent and submitted inference code. A separate verifier container is insufficient by itself.
   - Check model selection uses the allowed development data and follows the stated held-out evaluation protocol.

6. Reference methods and evidence
   - Check at least one runnable baseline publishes a contract-conforming package and has README.md, RESULTS.md, and a reproduction/ record.
   - Verify provenance, adaptations, configuration, seeds, commands, dependencies, hardware, runtime, and measured results.
   - Separate reproduced environment scores from paper-reported numbers, unverified reference material, and smoke-run results. Do not infer reproduction from the presence of code.

7. End-to-end validation and PR readiness
   - Inspect the recorded clean materialization, workspace build, brief reference run, package publication, relocation, and independent scoring.
   - Check invalid-output tests and comparisons with trivial methods and controlled better outputs where meaningful.
   - Check the root task table, readiness status, run instructions, remaining blockers, limitations, citations, licenses, and contributor attribution.

Run inexpensive local checks that are supported by the available runtime and documented task commands. Do not launch costly training, download large or gated data, or access credentials without authorization. Mark unavailable or unexecuted checks explicitly; never invent results. Do not expose private labels in the review or agent workspace. Review first; do not modify files unless asked.

Return:
1. Verdict: READY / INCOMPLETE / BLOCKED, with a short reason. READY requires recorded evidence for the critical end-to-end path and reference evaluation, not just plausible code.
2. A table: area | PASS / FAIL / NOT VERIFIED | file:line evidence | command or recorded run | required fix.
3. Critical blockers first, followed by other concrete fixes with file locations.
4. Commands actually run, their results, and any checks still needed on a machine with the required data or compute.
5. A concise PR-ready summary of scientific value, reproduced baseline results, validation, compute needs, and known limitations.