Align verify_patch Cargo checks with contributor verification commands
- Dominant language
- Rust
- Stars
- 53
- Forks
- 16
- Avg merge
- 4h 22m
- Merged PRs (30d)
- 46
Description
## Current evidence
`tools/verify_patch.sh` currently runs bare `cargo fmt --check`, `cargo build --quiet`, `cargo test --quiet`, and `cargo clippy -- -D warnings` after applying an email patch.
`CONTRIBUTING.md` documents stricter Cargo verification for the repository: formatting uses `cargo fmt --all --check`, Clippy uses `--locked --workspace --all-targets`, tests use `--locked --workspace --all-targets`, and the normal build is locked. A patch can therefore pass the maintainer script while failing the corresponding documented Cargo gate.
## Scope
- Make the Cargo formatting, build, test, and Clippy invocations in `verify_patch.sh` match the corresponding current repository verification contracts.
- Keep the script focused on its existing patch-verification stages; do not fold every Python, std-policy, corpus, or documentation check into this issue.
- Update progress messages so they describe the commands actually being run.
- Preserve patch application and cleanup behavior tracked separately by #638 and #639.
## Completion criteria
- Formatting covers the full workspace with the documented `--all` behavior.
- Build/test/Clippy use the repository's locked/workspace/all-target contracts where applicable.
- A failure in any updated Cargo gate still causes patch verification to fail.
- `CONTRIBUTING.md` and the script no longer describe conflicting Cargo checks.
Contributor guide
Research direction
Start with tools/verify_patch.sh and compare its Cargo formatting, build, test, and Clippy commands with the corresponding contracts in CONTRIBUTING.md. Update the invocations and progress messages without changing patch application or cleanup behavior, then verify that each Cargo failure still fails the script and that the documented commands no longer conflict.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust, shell
- Domain
- build-system, developer-experience
- Issue type
- Refactor
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 84/100