You are reviewing an uncommitted change in the proj-bolero repository (root = current directory), a sealed multi-stage research harness. The change implements three operator rulings about the d3_planner → d3_executor → d3_reviewer loop. You audit it hunk by hunk against the rulings; you do not redesign it. You are one of two independent reviewers.

THE OPERATOR'S RULINGS (authoritative; where they conflict with any older document, the rulings win):
R1. When the executor finds a plan defect, it executes only the defect-free parts and writes the concrete defect into result.md. If the round is revised, the planner reads it in the next round. The executor never adjusts a defect: it must be faithful; what cannot be done as written is not compromised on, only reported.
R2. The executor's report is written by a separate sub-agent, `execution-reporter`, which alone writes the terminal.
R3. The planner gains a `feasibility-prober` sub-agent that verifies the current execution environment permits every operation the plan names — Python and R dependencies, versions, and the like — so that at least at the environment/package level the plan can run.

READ FIRST (repo-relative; all exist):
- evaluation/meta-harness/outputs/2026-08-30/00-26-arch-review-codex/DIFF.patch — the complete uncommitted diff. Read all of it.
- bolero-harness/bolero/stages/d3_executor/.bolero/agents/execution-reporter.md — new file (R2).
- bolero-harness/bolero/stages/d3_planner/.bolero/agents/feasibility-prober.md — new file (R3).
- bolero-harness/bolero/prompts/d3_executor.md — the whole executor prompt as it now stands (4,8xx words), so you can see what the diff removed in context: the previous version (git HEAD) refused a whole plan on any contradiction, let the executor choose an "operative reading" of an ambiguous gate, and let it propose and synthetically check repairs in prose; those were removed under R1.
- bolero-harness/bolero/schema/result.py — the terminal contract the stop gate enforces (the reporter must produce a document that passes `check_format` and `check_executed_actions`).
- bolero-harness/bolero/stages/d3_executor/.bolero/hooks/stop-gate.py — the gate.
- bolero-harness/bolero/stages/d3_executor/.bolero/skills/execute-research-plan/SKILL.md, bolero-harness/bolero/stages/d3_executor/.bolero/agents/executor-coder.md, bolero-harness/bolero/stages/d3_executor/.bolero/agents/governed-runner.md — the executor's other instruction surfaces (must not contradict the prompt).
- bolero-harness/bolero/prompts/d3_planner.md — the planner prompt (§ "Mandatory independent advice" now has a step 4 for the prober); bolero-harness/bolero/stages/d3_planner/.bolero/agents/planner-feasibility-checker.md — the existing DATA-side feasibility adviser, which the prober must not duplicate.
- bolero-harness/bolero/prompts/d3_reviewer.md lines 155–180 — how the reviewer routes a terminal with failure rows (unchanged; check the new partial-execution terminal still routes correctly).
- bolero-harness/bolero/conf/stage/default.yaml lines 36–46 — the governed interpreter environment variables the prober relies on (`BOLERO_GOVERNED_PYTHON`, `BOLERO_GOVERNED_RSCRIPT`).
- bolero-harness/bolero/conf/layout.yaml, bolero-harness/bolero/conf/layout.md, bolero-harness/bolero/prompts/layout.md — `environment.md` added to the planner workspace.
Do not open evaluation/ session directories, any parquet/CSV, routing.json, or .env.

AUDIT QUESTIONS:
1. Traceability: does every hunk trace to R1, R2, or R3 (or to keeping another document consistent with them)? Name any hunk that does not.
2. Duty loss: list every duty the previous prompt carried that this version drops, and for each say whether the drop is required by a ruling, carried by another surface (reporter, prober, skill, gate, reviewer), or simply lost. The removed "two readings of a gate" rule is a known consequence of R1 — say whether you agree that R1 requires its removal, and what the executor should do under R1 when a gate's condition and rationale state different grains.
3. Contradictions: any sentence left anywhere (prompt, skill, coder, runner briefs, layout docs) that still assumes the main executor writes the terminal, may choose a reading, may repair a plan, or that refers to a whole-plan refusal.
4. Reporter feasibility: can `execution-reporter`, from the files it is allowed to read, produce a terminal that passes result.py's `Format` and `check_executed_actions` (pointer shapes, plan_version, action keys), and the posterior fields? Name any information it needs that no persisted file carries. Is its "never open row-level or undeclared grain" rule consistent with the manifest the runner writes (see the runner's `_write_manifest`)?
5. Prober feasibility: do the probe commands work in the planner container as the manifest mounts it (`conf/stage/d3_planner.yaml`; same image, same env vars from default.yaml)? Can it verify "versions" meaningfully? Does it stay off the data? Does it duplicate `planner-feasibility-checker`?
6. Instruction-load: word counts before/after for the executor's visible instruction text (prompt + two skills + three sub-agents); did the change add net instruction the executor's main context reads?
7. Risks: what gets worse. In particular, does R1's "report, never approximate" make over-refusal more frequent on plans with minor wording ambiguities, and is that the operator's intent as stated?

OUTPUT PROTOCOL — plain text, no Markdown headers, nothing else:
VERDICT: ACCEPT | REVISE
FINDINGS:
- F<n> [MAJOR|MINOR] <file>:<line or hunk> — <one sentence defect> — <one sentence fix>
DUTY-LOSS:
- <duty> — required-by-R<n> | carried-by:<surface> | LOST — <one line>
ANSWERS:
Q2-two-readings: <your position and what the executor should do>
Q4: <reporter feasibility, one paragraph>
Q5: <prober feasibility, one paragraph>
Q6: <numbers>
Q7: <risks, up to four lines>
