Preconditions

• Python code and code/Qx/qx_code_plan.md exist.
• Approved method decision, method card, data profile, and relevant run summary are available.
• Required inputs are accessible.

Workflow

1. Resolve the approved main and usable baseline. Flag scripts for unapproved candidates unless a fallback activation exists.
2. Inspect and run the code in the intended order.
3. Evaluate required checks:
   • syntax: imports, execution, exceptions, and obvious runtime faults.
   • input_contract: paths, fields, units, shapes, missing-data handling, and raw-data protection.
   • method_alignment: formulas, objectives, constraints, assumptions, main/baseline roles, and fallback scope match the approved plan.
   • reproducibility: seed, deterministic setup, dependency/runtime record, and rerun consistency.
   • output_contract: saved tables/metrics/figures, valid run summary, comparable main/baseline metrics, degeneracy evidence, and fallback-trigger state.
4. Add risk-specific checks only when relevant, such as leakage, constraint feasibility, numerical stability, or scale.
5. If asked to fix findings, make minimal changes, rerun affected checks, and record the repair. Otherwise report findings without changing code.
6. Save code/Qx/reviews/qx_python_review.json.

Review Schema

{
  "schema_version": 1,
  "question_id": "Q1",
  "language": "python",
  "reviewed_files": [],
  "decision_id": "q1_method_choice",
  "checks": {
    "syntax": {"status": "PASS", "evidence": []},
    "input_contract": {"status": "PASS", "evidence": []},
    "method_alignment": {"status": "PASS", "evidence": []},
    "reproducibility": {"status": "PASS", "evidence": []},
    "output_contract": {"status": "PASS", "evidence": []}
  },
  "findings": [],
  "verdict": "PASSED",
  "reviewed_at": "ISO-8601"
}

Statuses are PASS, FAIL, or NOT_APPLICABLE with a reason. Any required FAIL blocks G3.

Rules

• Do not pad evidence to reach a count.
• Do not fabricate execution or outputs.
• Do not approve a toy diagnostic reference as the official baseline.
• Do not silently change mathematical meaning.
• Do not create success logs beyond the review JSON.
• Treat code newer than its review as requiring the affected checks to rerun, not necessarily the entire pipeline.

Verification

• Every required named check has concrete evidence.
• Main and baseline are approved and comparable.
• Run summary and on-disk outputs agree.
• Review verdict follows check statuses.