- Start every PR review with 1-3 plain sentences explaining what the change does and why it matters. Put this before `Findings`.

- Then list findings first. If none, say `No blocking findings` or `No findings`.

- Always answer: bug/behavior being fixed, PR/issue URL and affected surface, and best-fix verdict.

- Always answer: bug/behavior being fixed, PR/issue URL and affected surface, provenance for regressions when traceable, and best-fix verdict.

- For bug/regression fixes, include a compact `Provenance:` line after cause/root-cause when a bounded history pass can identify it. Use `git log -S/-G`, `git blame`, linked PRs/issues, and tests; separate author, committer/merger, and current PR author when they differ.

- Phrase provenance as `introduced by`, `made visible by`, or `carried forward by`, with confidence (`clear`, `likely`, `unknown`). If unclear, say what evidence is missing instead of guessing. For features, docs, and refactors, use `Provenance: N/A` or omit it when no broken behavior is being fixed.

- Keep summaries compact, but include enough proof that the verdict is auditable without rereading the PR.

## Read beyond the diff

- Before landing, require:

1. symptom evidence such as a repro, logs, or a failing test

2. a verified root cause in code with file/line

3. a fix that touches the implicated code path

4. a regression test when feasible, or explicit manual verification plus a reason no test was added

3. provenance for regressions when traceable by bounded git/PR history

4. a fix that touches the implicated code path

5. a regression test when feasible, or explicit manual verification plus a reason no test was added

- If the claim is unsubstantiated or likely wrong, request evidence or changes instead of merging.

- If the linked issue appears outdated or incorrect, correct triage first. Do not merge a speculative fix.

- If Crabbox/E2E proof is blocked, say exactly why and use the closest available