Repository navigation
CI: add rustfmt gate and decide enforcement for undocumented_unsafe_blocks #1401
Description
Problem
Two quality properties this repo relies on are enforced by nothing in CI. Both were surfaced while closing #1343, and both are deliberately out of scope for that issue's PR — turning them on can redden branches other people are working on, which is a scheduling decision rather than a technical one.
1. No rustfmt gate
There is no CI job running cargo fmt --check. #1343 restores a repository-wide rustfmt baseline — verified with cargo fmt --manifest-path src-tauri/Cargo.toml --all -- --check returning exit 0 with zero output, spanning the root workspace, all three members, every crate root, build.rs and every integration-test target — but once that lands, nothing prevents it from being broken again by the next merge.
Restoring a baseline without a gate means paying the cost of restoring it repeatedly.
2. undocumented_unsafe_blocks is allow-by-default
clippy --workspace --all-targets -- -D warnings passes green while unsafe blocks carry no // SAFETY: justification. This was measured concretely during #1343: src-tauri/src/testability/reset.rs had 8 unsafe sites and 0 SAFETY comments, and src-tauri/tests/cli_test_reset.rs had 30 and 0, all while -D warnings was green.
#1343 documents the sites it owns. The lint gap remains: the next unsafe block can land undocumented with CI fully green.
Why this is a separate issue
Enabling either gate repo-wide can turn currently-green branches red. That interrupts whoever is mid-flight on them, so the decision is when to absorb that cost, not whether the gates are correct. Filing it separately keeps #1343's PR to the scope its issue actually states.
Suggested scope
- Add a CI job running
cargo fmt --checkacross the workspace, matching the invocation above so its coverage is the same one already verified. - Decide the enforcement level for
clippy::undocumented_unsafe_blocks: repo-wide (a lint table entry or workspace lints config) versus per-module opt-in as files are touched. Repo-wide is the stronger guarantee; per-module avoids a large one-shot cleanup. - Before flipping either on, measure how many existing files fail, so the size of the cleanup is known rather than discovered in a red CI run.
Notes
Depends on nothing; can be done any time after #1343 lands. If the repo-wide unsafe lint proves cheap enough to enable during #1343 itself, that PR will say so explicitly — otherwise it belongs here.
Activity
mblua commentedon Aug 17, 2026
Measured cost of the rustfmt gate: it is bigger than this issue first implied
Measured on
main@8f272a76, while closing #1343:cargo fmt --checkexits 1 with 221 hunks across 31 files.4f69e6b3. Largest:config/session_context.rs(31),lib.rs(25),config/seeded_context_templates.rs(14),agent_update.rs(12),commands/ac_discovery.rs(10), plus 21 more files.At the point #1343 branched, the five baseline paths were the only rustfmt failures in the whole workspace — "repository-wide baseline" and "these five files" were the same statement. They are no longer the same statement about today's
main.What this changes here
Landing #1404 closes 76 of the 221 hunks, so
cargo fmt --checkonmainwill still fail afterwards. That is expected: #1343's scope is explicitly the baseline files only, and it was deliberately not widened.The consequence for this issue: turning a fmt gate on today lands red on day one. The 26 remaining files have to be cleared first, and that cleanup is the real cost of the gate — not the CI job, which is a few lines. Sequencing is therefore: clear the drift, then enable the gate, ideally close together so new drift cannot accumulate in between.
The drift is also evidence for the gate rather than against it: 145 hunks appeared across 26 files precisely because nothing was checking.
Full measurement recorded at
__agent_dev-rust\gap1343\main-rustfmt-drift.md.Status of the second half of this issue
The
undocumented_unsafe_blockshalf is now partially resolved outside this issue, and worth recording so it is not re-litigated:#1404 adds
#![deny(clippy::undocumented_unsafe_blocks)]tosrc-tauri/src/testability/reset.rsandsrc-tauri/tests/cli_test_reset.rs. That was measured before being applied: with the attribute in both files and nothing else changed, clippy emitted 7 errors, all insidereset.rs, and cited no other file in the workspace — so it stays contained to the two files rather than dragging the repo red. A negative control (removing oneSAFETYcomment, re-running, getting exactly one error naming line 1 as the lint level source) confirmed the attribute is live rather than decorative.So the per-module opt-in path is proven to work and is already in use on two files. What remains for this issue is the repo-wide decision: keep opting in file by file as they are touched, or enable it workspace-wide and absorb the one-shot cleanup — which should be measured the same way before being flipped.