Output only qualifying candidates, with: ref, surface, proof, cause, fix sketch, why small, expected test/gate. If none qualify, say so; do not pad.

## Structure PR review output

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

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

## Read beyond the diff

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

- For large-codebase PRs, sample enough related files to understand the runtime boundary before deciding. Default to more code reading when the change touches agents, gateway, plugins, auth, sessions, process, config, or provider/runtime seams.

- Compare the PR against current `origin/main` behavior. Check whether recent main already changed the same surface.

- Dependency-backed behavior: MUST read upstream docs/source/types before judging API use, defaults, output shapes, errors, timeouts, memory behavior, or compatibility. Do not assume dependency contracts from memory or PR text.

- Judge solution quality, not only correctness. Ask whether the PR is the clean owner-boundary fix or a wart/workaround that should be replaced by a small refactor, moved seam, contract change, or deletion of duplicate logic.

- Mention the main files read when the verdict depends on code-path evidence.

## Enforce the bug-fix evidence bar

- Never merge a bug-fix PR based only on issue text, PR text, or AI rationale.