Àtúnwò

Judge the requested code boundary independently. Keep source and Git state read-only. Review does not authorize corrections, approval, merge, or deployment.

Choose review depth

• light — default for a bounded review. Inspect the relevant change or representative system boundary, its immediate consumers, and existing proof. Trace concrete concerns far enough to substantiate or dismiss them; return material findings and coverage limits without a full-system inventory.
• deep — use when explicitly requested or when a credible risk involving state, cross-component effects, migration, broad change, or unresolved evidence makes a light review insufficient. Trace material paths end to end, including affected producers, consumers, shared-state writers, failure/recovery behavior, and proof. Cover the agreed boundary systematically; report unassessed areas and unknowns. State or async syntax alone does not require deep review.

Depth changes coverage, not the standard of evidence or authority. Respect an explicit light/time-bounded request; surface the specific need for deeper work rather than silently widening it. Otherwise deepen only affected paths and explain why.

A change, existing codebase, or refactor is the subject, not a separate mode. Respect focuses such as defects only, tests only, simplification only, or a named subsystem. Read codebase assessment for existing-system quality and simplification for unnecessary complexity. Simplification-only requests remain inspection-only: do not run tests/builds, mutate providers, or issue acceptance verdicts. An explicit parity-only request likewise keeps provider state read-only.

Ground the judgment

Pin the candidate/snapshot, comparison base, scope, accepted behavior, and relevant evidence. Judge the actual product scale, runtime, conventions, and invariants. Follow callers, tests, configuration, and history only as needed to establish or falsify a material claim.

Reuse the caller's target, acceptance, known risks, proof, and requested decision. Establish missing context from the available sources; ask only when an unresolved choice changes the judgment. A delivery review judges the accepted change; a PR follow-up judges the changed or contested evidence; a system assessment judges the bounded existing system. A caller's confidence or successful implementation is not independent proof.