Checks
review/code investigates the exact software change and follows affected code, callers, contracts, and tests. A separate model pass then re-reads the source and independently verifies each proposed finding before it is reported.
With host-detected pull-request intent, a second investigator checks whether the change actually achieves that hypothesized outcome while preserving repository invariants and boundaries. The generic investigator does not receive PR prose. Both candidate lanes are verified together against current repository evidence.
When neither lane proposes a candidate for a nonempty change, an independent audit reconstructs before/after behavior and checks concrete boundary inputs before the review can report clean. Its candidates use the same verification pass; the audit never reports findings directly. This adds one investigation pass to reviews that initially appear clean. Source lookup gaps complete with coverage observations rather than failing the review. Independently verified findings remain reportable, but partial or excluded-only coverage cannot produce a whole-change clean opinion. Metadata-only in-scope patches can finish without text reads.
Source coverage completion policy
The October 6 completion-policy change, paired with SDK 0.1.36, supersedes the older diagnostic-task requirement to throw a stage-identifying exception for incomplete source recovery. A coverage gap is a successful review with a stated coverage limitation, including when zero source windows are available. Stage identity remains visible in diagnostics and observations. Returning an empty finding list under partial coverage must never become a whole-change clean opinion. This policy does not relax provider-error or citation validation.
Every model stage records partial coverage, including outcome investigation and focused verification. Structured stderr diagnostics contain only job and reviewer identifiers, stage, numeric source/hunk counts, and allowlisted reason codes. They omit paths, source content, prompts, and raw tool errors. Unknown counts remain null. Coverage counts describe retrieved patches; failed patches can have unknown hunks.
When composition is enabled, this generalist pass receives every changed file. Pinned public specialists receive the changed files selected by their manifest and can use the repository graph for surrounding context. The CLI merges their results and records source-reviewer provenance on every finding.
review/conventions receives every changed file and owns findings whose primary
issue is a declared or strongly inferred repository convention. The CLI also
supplies bounded repository-policy evidence to every model-backed specialist so
their analysis and recommendations fit the repository they are reviewing.
| Review area | Scans for |
|---|---|
| Correctness and completeness | Incorrect behavior, broken invariants, missing cases, and incomplete implementation introduced or newly exposed by the change |
| Contracts and compatibility | Violated caller, API, schema, persistence, configuration, or old/new-version compatibility contracts |
| Failure paths | Partial failures, missing cleanup or rollback, unsafe retries, cancellation gaps, and contradictory state transitions |
| Concurrency and repeated use | Races, ordering defects, stale state, cache or pool divergence, and behavior that fails on later invocations |
| Security boundaries | Newly reachable authorization, credential, trust-boundary, validation, or sensitive-data failures |
| Resources and data | Leaks, data loss or corruption, unsafe lifecycle changes, and persistence defects |
| Deployment and operations | Rollout failures, mixed-version hazards, broken runtime configuration, and weak recovery behavior |
| Validation quality | Tests that pass without establishing the changed effect or that omit a concrete regression path |
| Repository conventions | Violations of applicable written policy or patterns supported by at least three consistent repository examples |
Reporting boundary
A finding is reported only when the independent verification pass establishes all of the following from repository evidence:
- A changed hunk creates, newly exposes, or makes the defect reachable.
- A realistic input or state reaches it.
- The incorrect outcome follows from the current source.
- Existing guards or tests do not prevent it.
- The proposed correction is proportionate to the defect.
The adversary stays quiet about style, taste, generic requests for more tests, pre-existing problems unrelated to the change, speculative future misuse, and claims that depend on unread source. Silence is preferred when evidence is insufficient.
Verification accounting
Verification returns one decision for each candidate: verified, rejected, or
unresolved, together with the decisive evidence or missing context. Verified
candidates remain separate during this pass; overlap is handled after validity.
The verifier can narrow exaggerated impact to the supported defect, but cannot
invent a replacement defect. Every emitted citation must resolve to a source
read by the verifier. Missing decisions and malformed citations fail visibly.
When a batch decision says verified but omits the finding, the reviewer checks
that candidate alone with the same prompt and repository tools, using a smaller
4,000-token output budget. Recovered findings record verificationPasses: 2.
If that focused pass also omits the finding, the candidate is unresolved and the
review cannot report a clean opinion; other verified findings remain.
Unresolved candidates are recorded in observations and prevent a clean opinion,
without suppressing independently verified findings. Partial retrieval in any
stage retains supported findings and produces a limited-coverage opinion without
a clean verdict. Real provider errors, malformed decisions, and invalid citations
still fail validation; missing source is never treated as proof of a defect.
Collection authorization checks include mixed permitted/forbidden inputs. Changed calls require reading the callee or wrapper contract, including keyword names. These are general investigation procedures, not benchmark-specific answers.
Local tests use mocked model responses to check retention, rejection, incomplete verification, accounting, and citation handling. They do not measure model recall or precision. The eight reviewed PRs are development data after this diagnosis; accuracy claims require separate PRs and repositories with a frozen configuration.
Implementation and outcome discovery run concurrently with separate inputs; intent remains absent from implementation review. Empty candidate sets skip verification after the independent clean-result audit. Actual candidates still require independent verification and fresh source citations.