Review PR

4. Run the blocker scan

Apply every category in general-checks.md before lower-priority comments.

If the diff census contains an added, copied, or renamed Python path under examples/, read and apply the canonical examples policy. Treat a new model-specific Python example as blocking. Do not flag model-specific example debt that the PR only modifies or removes, and do not run the rest of the author-oriented precheck-pr workflow.

For each changed value or behavior, trace:

public ingress -> validation/defaulting -> producer -> transformations
  -> stage/worker/connector boundary -> final consumer -> terminal cleanup

Cover every applicable offline/online, streaming/non-streaming, sync/async, feature-on/off, topology, and compatibility path. Search bounded callers and sibling implementations rather than assuming the changed hunk is the only path.

5. Apply module and feature contracts

Apply the reference set selected in step 3 and any matching repo-local skill. Read the exact module and feature pages in the frozen head, including status, ownership boundary, dependencies, candidate invariants, safe-change guide, and promotion gate. Candidate or draft rules are questions, not blockers, unless current code, tests, or policy enforce them. Inspect both sides of any config, registry, serialization, connector, cache, or stage boundary.

Read and apply find-simplifications on every review. Constrain it to the diff and the adjacent ownership, callers, or consumers needed to prove a candidate. Check whether added or expanded helpers, classes, state, fallback and compatibility branches, data movement, or public behavior can be deleted, merged, moved, or inlined. Zero candidates is a valid result. Do not widen the review into repository backlog or report speculative style preferences as simplification findings.

6. Verify the changed path

Before each validation group, verify the frozen SHA plus the tracked, index, untracked, and ignored-file fingerprint, or recreate a pristine snapshot. On a head the user explicitly trusted for this host, run an import/version preflight, then the narrowest relevant tests and low-cost static checks. Bind every result to the head SHA, snapshot fingerprint, and environment fingerprint. Never run imports, tests, builds, hooks, or repo-configurable tooling from an untrusted head on the reviewer host.

• Treat CI as status evidence; inspect only the first overlapping failure.
• For docs-only changes, use diff hygiene, links/build checks, and bounded live contract verification instead of dependency setup or pytest.
• For hardware-dependent paths, run available static/CPU checks and name the exact GPU/NPU gap. Never simulate device evidence.
• For performance or accuracy claims, require comparable base/head runs with the same environment, workload, warmup, repetitions, and quality criteria.

Stop when each changed semantic path has a supported finding or an explicit no-issue conclusion. Do not search further only to increase confidence.

7. Consolidate and deliver

Verify each finding against the current diff, deduplicate by root cause, and order by severity.

Re-read the remote head and reverify or recreate the pristine validation snapshot immediately before delivery. If either changed, mark the review stale and restart from the new snapshot.

Return findings first. Use maintainer-style-study.md to keep them direct and brief. Each finding must include an exact path:line, trigger or call path, current behavior, impact, and smallest fix direction. If there are no findings, say so briefly and name material validation gaps.

Keep the review read-only unless the user explicitly authorizes posting. Do not submit APPROVE, COMMENT, or REQUEST_CHANGES, add labels, edit code, or push commits as an implied part of review.

8. Optionally request focused owner reviews

Only when the user asks to identify or request reviewers, read review-requests.md. Rank path-matched CODEOWNERS with the frozen module page's owners or required reviewers and documented governance expertise; propose one to three focused reviewers with an explicit contract rationale.

Identifying or suggesting reviewers is read-only. Requesting reviewers or posting @mention comments changes external state and requires explicit user authorization. When authorized, recheck the head, deduplicate existing requests, and post at most one consolidated comment. Do not infer this permission from a request to review the code.