# Code review

Load this reference only when the fixed reviewed artifacts make the Code pipeline applicable.

Check in this order:

1. Safety and correctness: reachable bugs, data loss, security violations, invalid state transitions, broken contracts, unsafe failures, and regressions.
2. Change and Spec fidelity: observable behavior against explicit intent and stable facts.
3. Project standards: only rules established by nearest instructions or authoritative local conventions.
4. Production reachability — hard gate before completing a seam-dependent Finding or returning `clean` for a changed seam: when behavior depends on an adapter, wrapper, validator, normalizer, registration, loader, generated wire-up, bin, worker, subprocess, plugin assembly, or another shipped entry path, name the smallest real production entry chain and verify that it reaches the changed seam. Direct or isolated seam tests are insufficient when they bypass that entry chain. Put the checked entry path in Evidence or Coverage. If the shipped path bypasses the seam, or the required reachability evidence is missing, report the gap and do not return `clean` or present an isolated seam fix as sufficient.
5. Regression evidence — hard gate before `clean`: for every changed Code artifact, compare public return and failure behavior at the comparison point with the reviewed diff. Changing failure delivery between throw/rejection, sentinel values, `null`, status codes, or result objects is always a failure-contract change, even when implementation matches the selected Change. Without a focused test or other explicit verification evidence, emit a Finding and return `issues_found`. Absence of a new test is not actionable by itself: apply the simple deterministic-correction exception when the public behavior shape is preserved and no risky branch, state transition, concurrency, persistence, security behavior, or failure delivery changes, even though the corrected value differs. The exception never applies to a failure-contract change.
6. Test and seam value — hard gate before `clean` when the diff adds or preserves a permanent test, public seam, validator, fallback, capability, compatibility path, or generic option: classify its consumers as production, non-production, or ambiguous. Tests and documentation alone do not make behavior production-load-bearing. For each questioned permanent test, identify its observable consequence, distinct plausible regression, why existing evidence misses it, and maintenance cost. Report test-only generality, wrapper or forwarding-hop assertions, shared-constant restatement, source-string coupling, or duplicate failure coverage only when a concrete real owner or smaller evidence path exists. Do not recommend deleting or merging tests that protect independent consequences, and do not infer that fewer tests are inherently better.
7. Simplicity: unnecessary abstraction, duplication, indirection, dependency, or scope expansion with a concrete smaller alternative; never trade away required behavior.

Anchor each Finding to changed lines or the smallest behavior chain. State a realistic trigger and impact. Do not report formatting, naming, generated output, taste, or hypothetical cleanup without authority or demonstrated downside.