review-pr

Review PR

Purpose and Modes

Judge the latest reviewed scope from root cause, behavior, contracts, tests, and public evidence. Select one output mode:

• Formal Review Mode: return one formal result for a PR review, code-readiness judgment, mergeability decision, or CI review.
• PR Discussion Reply Mode: return a copy-ready committer reply for a review thread, author or maintainer objection, or challenged finding. Do not add a formal verdict unless requested.
• Local Candidate Preflight Mode: review an authorized local implementation targeting an existing PR and return findings to the repository completion loop. Do not describe local-only work as the public PR state.

Review Focus

Review focus is independent from output mode.

Explicit user scope wins. Local Candidate Preflight uses Code Correctness Review unless the user explicitly requests CI.

In Code Correctness Review, unreviewed CI is not an evidence gap. Runtime facts may still be required from code, official specifications, public reproductions, or local verification. If such a decisive fact is unavailable, identify that fact—not CI—as the incomplete reason.

Canonical Assessment

Resolve one review basis before discovery: the effective candidate, applicable requirements, selected review focus, and admissible evidence. Run the Review Workflow against that basis and produce one mode-independent assessment: confirmed findings consolidated by fix boundary, needs-discussion conditions, incomplete-evidence gaps, and Completion Gate state.

Output mode must not affect candidate discovery, proof, classification, coverage, or convergence. Never use a previous Local or Formal result as evidence or as a conclusion to match. Treat previous public findings only as hypotheses whose cited facts must be reverified.

Two reviews with the same effective candidate, requirements, focus, and evidence must produce the same canonical assessment. Local and Formal modes may resolve different candidates and render different status labels, but they must not apply different code-correctness judgment. A changed focus, requirement, or external fact changes the review basis and may legitimately change the assessment. Mergeability or CI evidence may add external-state findings or gaps, but it must not change code-correctness findings derived from an otherwise unchanged basis.

Core Contracts

1. Review only. Do not modify PR code, post comments, submit reviews, resolve threads, rerun workflows, or change remote state without explicit authority.
2. Formal review scope is the latest public PR head and the complete GitHub changed-file list. Use local triple-dot semantics when reproducing it. A discussion reply starts from the latest head, thread context, and affected behavior; expand to complete scope only when the claim depends on it.
3. Community-visible conclusions use only public evidence and sanitized verification summaries.
4. Reconstruct trigger -> failing path -> observed result -> expected behavior before judging the patch. A fallback, default, null check, try-catch, or swallowed error is not a root-cause repair unless it fixes the owning contract.
5. Treat every concern as a candidate until it passes the Finding Proof Gate.
6. Do not turn uncertainty, inaccessible evidence, tool failure, skipped verification, or uninspected counter-evidence into a blocker.
7. In Formal Review and Local Candidate Preflight, do not select a verdict, stop at the first blocker, or publish findings before the Completion Gate. Consolidate findings by independent fix boundary and return the complete current-head set once. Only an explicit request for status, narrow review, or early high-risk blockers authorizes a partial result.
8. Follow AGENTS.md for repository authority, command execution, local verification, sensitive data, and completion-loop rules.

Scope and Evidence

For formal reviews:

• Resolve PR metadata, latest head SHA, base ref and SHA, authoritative GitHub file list, linked issue scope, public comments, and relevant reviews.
• Fetch every required page. When local Git is used, record the merge-base and whether the local file list matches GitHub.
• Review latest deltas after new commits; earlier findings never establish current-head readiness.
• Prefer PR facts, same-repository issues, code and tests, ShardingSphere documentation and conventions, then external official specifications.

For Local Candidate Preflight targeting an existing PR, resolve the same public requirements and code-correctness evidence before applying the authorized local delta. Record any explicit local requirement that extends the public PR scope as a distinct part of the review basis.

For discussion replies, establish the latest public head, complete thread context, relevant earlier review, and affected production or test paths. Fetch the complete file list when scope is disputed or the reply changes an overall readiness conclusion.

Read evidence-access.md whenever current GitHub, CI, Actions, or third-party behavior evidence is required.

Finding Proof Gate

A candidate may become a blocking issue only when all five conditions hold:

1. Evidence: current code, diff, contract, test, log, CI, public reproduction, official documentation, or generated artifact directly supports the claim.
2. Full path: trace the relevant production or test entry path end to end; inspect setup, wrappers, earlier calls, generators, and consuming runtime.
3. Counter-evidence: check the strongest evidence that could disprove the finding, especially author or maintainer replies and version-specific facts.
4. Necessity: the requested change is required for safety or correctness in the selected focus, not merely cleaner or preferable.
5. Scope: this PR causes the problem, exposes it through behavior it owns, or must address it to satisfy the linked issue.

Classify failed candidates as an incomplete-evidence gap, non-blocking observation, clarification question, pre-existing issue, or no issue. Do not publish non-blocking observations unless they materially help the user.

Behavior Clusters and Risk Triage

Before deep review, group the scope into the smallest independently meaningful behavior changes. A behavior cluster may cross several files, and one file may belong to several clusters. Map every substantive changed file to at least one cluster; treat churn-only files explicitly rather than silently dropping them.

For every cluster, identify its root cause, behavior owner, entry paths, callers or consumers, contracts, changed conditions or state transitions, and validation points. Then consider every risk axis and deepen only the triggered ones:

• Root cause and linked-issue completeness.
• Functional behavior, important boundaries, disabled paths, adjacent features, and old-scenario regression.
• Ownership, module boundaries, public APIs and SPIs, metadata, implicit state, lifecycle, and shared-code blast radius.
• Configuration, protocol, SQL and dialect semantics, supported versions, compatibility, migration, and rollback.
• Test validity and meaningful coverage of the owning production path.
• Concurrency, performance, allocation, I/O, memory, and resource cleanup.
• Diagnostics, security, user documentation, and release-note necessity.
• Dependencies, licenses, packaging, native metadata, generated resources, and distribution impact.

This triage is mandatory even when no risk is ultimately found. Read only the triggered sections in high-risk-review.md. For SQL grammar, visitors, parser tests, syntax documentation, dialect behavior, or parser baselines, also read sql-parser-review.md.

Review Workflow

Apply this workflow to the canonical review basis without using output mode or a previous result to influence the assessment:

1. Establish the authoritative effective-candidate scope and applicable requirements.
2. Confirm the selected review focus and admissible evidence.
3. Build behavior clusters and complete the mandatory risk triage.
4. Discover candidates across the complete scope before classifying the assessment. Use three distinct lenses:
   • Root Cause and Behavior: intended fix, changed decisions, boundaries, disabled paths, adjacent cases, and old-scenario regression.
   • Blast Radius and Contracts: callers, consumers, shared state, public contracts, compatibility, dependencies, packaging, and generated outputs.
   • Tests, Runtime, and Operations: realistic regressions that can still pass, error and lifecycle paths, runtime verification, diagnostics, documentation, rollout, and rollback.
5. Apply the Finding Proof Gate to every candidate. Keep discovery notes private and classify every candidate before publication.
6. Consolidate confirmed findings by independent fix boundary and identify any evidence or coverage gap that could still change the blocker set.
7. Review the latest delta and run a full-scope convergence pass after the most recent candidate change. If it finds a new independent candidate, return to step 5 and repeat. Freeze the canonical assessment only after the Completion Gate evaluation, then map it to the selected mode's status.

If the scope cannot be reviewed honestly, return the mode-appropriate incomplete result or request a split

Content truncated.