code-reviewlisted

# Code review Review is source-read-only unless the user separately authorises fixes. A reviewer may write compressed findings and traces only to an assigned artifact directory. The diff is the entry point, not the boundary. Judge the resulting system, not the changed lines alone. ## Review 1. Read project instructions and preserve the requested scope and output contract. 2. Establish the change intent from the spec, issue, tests, commit message, or user request. Mark unclear intent instead of inventing it. 3. Trace the affected dependency cone: full touched files, live callers/ consumers, exports, canonical owners, tests, configuration, migrations, persistence boundaries, dependency/lock changes, and generated artefacts. Record inspected/excluded surfaces; unavailable context stays `unknown`. 4. Select review lenses from the task/risk profile. Correctness/spec alignment is mandatory; add security/privacy, data/concurrency, performance/reliability, tests, architecture, readability, UX/accessibility or operations only when activated by the dependency cone. 5. For substantial+ or wide-surface work, use independent targeted agents with distinct primary lenses and deliberate overlap on the riskiest invariant. `orchestrate` adds the required other-primary and distinct-family review pressure from `HARNESS.md`. Then run an anonymised claim challenge and a fresh reduction. Never rank prose or majority-vote findings. 6. Review the design delta