wavefnd / wavefnd/Wave

Align verify_patch Cargo checks with contributor verification commands

Open Beginner friendly
#652 0 comments 0 reactions 0 assignees View on GitHub
build good first issue
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.