rust-review

Run the mechanical gate first (cargo fmt --check, clippy with -D warnings, cargo test), then review the diff against the severity checklist covering safety, errors, ownership, concurrency, and performance. Finish with an Approve, Warning, or Block verdict citing findings by file:line and rule ID.

The gate is cargo fmt --check, cargo clippy --all-targets -- -D warnings, and cargo test, plus cargo audit and cargo deny check if installed. If CI already ran an equivalent check on the PR and it is green, consume that result instead of recomputing locally.

Blockers include unwrap or panic on reachable production paths, unsafe blocks without SAFETY comments, injection via string interpolation, hardcoded secrets, blocking calls inside async functions, locks held across await, and any red gate check. Confirmed CRITICAL or HIGH findings force a Block verdict.

Yes, when a diff changes a public API surface, an additional pass runs a condensed Rust API Guidelines checklist covering naming, common trait impls, error types, sealing, documentation, and Cargo metadata. It is skipped for application-internal code.

Every finding goes through adversarial verification where skeptics try to refute it, and a documented exclusion catalog (FP-001 through FP-007) defines when findings drop, each requiring a specific trace. Unverifiable premises demote findings to Suspected rather than refuted.

The rubric judges code but does not rewrite it, and it does not write missing tests; those belong to separate testing and refactoring skills. Security-sensitive changes with unsafe code or new dependencies should also dispatch a dedicated security scanner and Miri checks.