code-reviewlisted

# Review a change independently Return verified findings, not edits. Keep requirements, standards, and correctness separate: a passing axis cannot hide a failing one. The caller owns corrections, tests, and delivery. Review does not authorize publication or product execution. ## 1. Fix the review scope 1. Read the request and project instructions. Identify repository, authoritative issue/spec, delivery boundary, and task-owned changes. Prefer supplied requirements, then verified links in the work record or commits; never infer intent from code. 2. Resolve the base to a commit ID and state the comparison: | Request | Comparison | | --- | --- | | Explicit range | Requested endpoint or merge-base comparison, stated explicitly | | PR / branch against target | Verified target and merge-base with reviewed head | | In-progress implementation | Recorded task baseline plus scoped committed, staged, unstaged, and untracked changes | | Ambiguous base / ownership | Ask before review; never silently assume `main` or include unrelated work | 3. Validate refs and inventory additions, deletions, renames, and relevant untracked content. Empty or invalid comparisons end before delegation. 4. Record a checkpoint: base/head IDs, scoped paths, local-change inventory, and content hashes or equivalent snapshot identity. Pause caller edits during review or use an isolated snapshot including local changes; a worktree at HEAD alone omits uncommitted work. Excl