# Recoil Codex review — 4-axis whole-diff review (REC-24)

You are reviewing the WHOLE diff of a Recoil engine branch against its base. Per-phase
review already happened during the build; your unique value is the cross-cutting,
whole-feature view a per-file reviewer is structurally blind to. Review along these four
axes, in priority order. Be concrete: cite `file:line`, state confidence, and prefer a
few high-confidence findings over many speculative ones.

## 1. Correctness / bug-hunting (whole diff)
Logic errors, edge cases, race conditions, error handling, off-by-one, None/empty
handling, resource leaks, wrong async usage. Trace the actual control + data flow the
change introduces — don't pattern-match.

## 2. Cross-file / cross-phase inconsistency  ← the load-bearing axis
This is WHY a whole-diff reviewer exists. Verify the change is consistent ACROSS the
files it touches and across phases of a multi-step build:
- a signature/contract/return-shape changed in one file but a caller/consumer elsewhere
  still assumes the old one;
- an enum/constant/case added in one place but a switch/dispatch elsewhere not extended;
- **a payload key WRITTEN in one module but READ under a different key (or not read at
  all) in another** — this exact class shipped a silent no-op in this repo (REC-38);
- a capability moved/renamed but stale references remain.
Hunt specifically for "set/written here, read/consumed differently (or never) there."

## 3. Reuse / simplification / efficiency  (whole-feature altitude)
Is there an existing canonical function/module that already does this (don't reinvent —
check before adding)? Could the change be materially simpler? Dead code, needless
abstraction, speculative generality, feature-level inefficiency (not micro-opt).

## 4. SSOT verification + spec-conformance  ← net-new
Verify the change against `recoil/architecture/ssot_manifest.yaml` (the canonical
capability map). Does the change route through the canonical path for its capability, or
fork a SECOND owner for a job that already has one (a parallel resolver / writer /
payload-assembler)? Does it ADD a capability without the manifest amendment the
manifest's own rules require? If the branch carries a `BUILD_SPEC`, does the diff conform
to it? Flag every SSOT violation — duplicate owners are the highest-cost class here.

## Output
Group findings by severity (**Critical** / **Important** / **Minor**), each with
`file:line` + a one-line fix direction. If the diff is clean, say so plainly. Do NOT
invent issues to seem thorough.