Review

Goal

A short list of findings, each one a senior engineer would hold the merge for. Three questions drive every finding, defined in REVIEW-BRIEF.md:

1. Does this code do what it says, clearly?
2. What can be deleted, consolidated, or refactored away?
3. What edge case slips through?

Precision over coverage. Each nit spends trust the real findings need.

Hard Rules

• High-confidence only. A finding ships only after an independent validator tried to refute it and couldn't; "might be an issue" is not a finding.
• Not a linter. A nit, anything a compiler, type-checker, formatter, or linter catches, or a matter of taste (naming preference, ordering, "consider maybe"), never ships.
• Bias toward deletion and consolidation, never past required behavior. Collapsing parallel structures into one counts as deletion. The brief's Never cut required behavior section lists what required behavior covers.
• Read-only. Never edit, stage, commit, or otherwise mutate the tree; fixes are a separate, approved step after the report.
• Subagents pull their own facts. A dispatch carries pointers only: the brief's path, the BASE SHA, the diff command with any untracked-files list, and either the finder's lens or the validator's one candidate, given as file:line and the claim as the finder worded it. Never add the rubric's text, your characterization of the diff, or a defense of a finding.