1Complete the task described in `TASK.md` by following this research protocol. The protocol adds no scientific information to the task; it organizes how you work and what evidence you leave behind.23PHASES (execute in order; a phase is eligible only when its dependencies are satisfied):45P0 Scope and contract (depends on: nothing)6- Read `TASK.md` completely. In `out/state/contract.md`, restate in your own words: the scientific question; the quantity or quantities to be estimated (the estimands) and the assumptions under which they are meaningful; every required output file and key; the information-availability rules; what would make the task impossible or the result invalid.7- Write the initial phase ledger `out/state/phases.json`: a JSON object mapping each phase id (P0 … P5) to {"status": "pending"|"running"|"passed"|"failed"|"blocked"|"stale"|"skipped_optional", "checks": [], "notes": ""}. Keep it current as you work. A phase may only be set to "passed" when the checks listed for it in this protocol have actually been executed and their outcome recorded in "checks".89P1 Data audit and provenance (depends on: P0)10- Inspect every input file: compute and record its SHA-256, row and column counts, schema, units, date ranges, missing values, duplicates and anomalies in `out/state/data_audit.md`.11- Keep an exclusion ledger in `out/exclusions.csv` (columns: step, rule, n_before, n_after, n_removed, rationale) for every filtering step you apply, so that n_raw − total removed = n_analysed.12- Identify any input that violates the information-availability rules and decide, in writing, how you will handle it.1314P2 Baseline (depends on: P1)15- Before any elaborate method, compute the simplest valid baseline that answers the question (for example a naïve or unconditional estimate), with the same evaluation rule used later. Record it in `out/results.json` under the keys the task requires, or under `baseline_*` keys when the task does not name them.1617P3 Method and computation (depends on: P2)18- Implement the analysis in `out/analysis.py` so that it reads only `data/`, writes `out/results.json` deterministically (fix every random seed you use and record it), and prints nothing that contradicts the written results. Any figure or table must be generated by this script.1920P4 Verification (depends on: P3)21- Re-run `out/analysis.py` from a clean state and confirm it regenerates `out/results.json` with identical values. Record the check in `out/state/phases.json` under P4.22- Check internal consistency: identities that must hold (for example counts that must add up, standard errors that must be positive, confidence intervals that must contain their estimates, date orderings that must respect the information rules), units, and magnitudes against the baseline. Record every check and its outcome in `out/state/checks.md`. A failed check must be fixed or honestly reported, never silently ignored.2324P5 Reporting (depends on: P4)25- Write `out/report.md` with the sections: Question; Data and exclusions; Method; Results; Uncertainty; Limitations and open issues. Every quantitative statement must cite the key of `out/results.json` it comes from.26- Write `out/claims.json`: a list of the central claims of your report, each as {"id": "C1", "text": "...", "results_keys": ["..."], "status": "supported"|"unsupported"|"not_evaluated", "caveat": "..."}. Do not state a claim in the report that is not in this ledger.27- Set the final statuses in `out/state/phases.json`.2829STOPPING RULES30- Stop and declare the task complete only when every phase P0–P5 is "passed" with recorded checks. If a phase is "blocked" (missing information, impossible requirement, violated availability rule), stop, set the status, explain in `out/report.md` (section Limitations and open issues) and still write every required file with `null` for values you could not legitimately produce.31- Do not spend effort on extensions that the task does not require.3233RECOVERY RULES34- Append a short dated entry to `out/state/log.md` after each phase transition and after any important decision, so that work can be resumed by reading `out/state/`.35- If you discover that an upstream input or decision changed after a downstream phase passed, mark the downstream phases "stale" and redo them; do not reuse stale results.36- If you are interrupted and later resumed, first read `out/state/` and continue from the last consistent state; never re-run expensive steps that already have recorded, unchanged outputs.3738EXECUTABLE GATES (additional, mandatory)39- A read-only gate program is provided at `~/wp29/gates/pgar_gate.py`. Run it from the workspace root as `~/wp29/venv/bin/python ~/wp29/gates/pgar_gate.py .` It checks the output contract of `TASK.md` (required files, keys, types, finite values, report sections, the claims ledger, the phase ledger, the exclusion ledger) and reproducibility (it re-runs `out/analysis.py` in a temporary copy and compares the regenerated `out/results.json` with yours). It never checks scientific correctness and it contains no reference answers.40- You must run the gate at the end of P4 and again at the end of P5, and record each run's receipt (the gate writes `out/state/gate_receipts/<timestamp>.json`) in `out/state/phases.json`. You may not declare the task complete while the latest gate receipt reports `"passed": false`. Fix the reported problems and re-run the gate.41- The controller will run the same gate after your session ends. If it fails, you will be resumed with the gate output and asked to fix the problems; each such cycle consumes your remaining budget.42