diff-review

# Diff Review Find defects that would justify changing the candidate, with enough evidence for the author to reproduce and fix them. ## Boundary - Review only by default. Do not edit code, resolve threads, commit, push, or approve a pull request unless the user separately requests that action. - Resolve the exact target and record base, head, working-tree state, and whether the evidence covers a dirty candidate, local commit, or remote pull-request head. - Preserve staged, unstaged, and untracked work. Use an isolated temporary worktree when broad validation would mutate or misrepresent the candidate. - Review against repository instructions, the issue or spec contract, and current source behavior. A green suite does not prove the intended behavior was implemented. - Report only actionable defects, material test gaps, or explicit requested nits. Do not manufacture findings to make the review look useful. ## Workflow 1. **Resolve intent and target:** Read the request, issue, spec, plan, and change description. Identify the exact comparison and proof already supplied. 1. **Inventory the delta:** Inspect changed files, generated artifacts, dependency or schema changes, and nearby code needed to understand behavior. Do not review the diff in isolation when invariants live elsewhere. 1. **Read tests first:** Determine what behavior the candidate claims, whether tests can fail for the defect class, and which requirements remain unproved. 1. **Trace intended versus implemented:...