- 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`.

- Show size near the top as `LOC: +<additions>/-<deletions> (<changedFiles> files)`, using live PR stats or local diff stats.

- 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.

- Provenance must separate roles when they differ: blamed code author username, blamed PR author username, blamed PR merger/committer username, automerge trigger when known, current PR author username, PR number, and date. Do not collapse them into one "introduced by" actor.

- 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.

LOC proof:

```bash

gh pr view <number> --json additions,deletions,changedFiles \

--jq '"LOC: +\(.additions)/-\(.deletions) (\(.changedFiles) files)"'

```

## Read beyond the diff

- Review the surrounding code path, not just changed lines. Open the caller, callee, data contracts, adjacent tests, and owner module.