Backend code-quality guardrails
Backend code-quality guardrails
Status: Delivered
CAS: CAS-2403
Delivered: 2026-05-12
PRs: #626 (clippy), #627 (skill), #634 (review checklist + coverage gate)
What’s new
A four-layer guardrail system for Rust/backend that structurally prevents the “ship-without-tests” pattern: new code branches and error mappers now require coverage evidence before a PR can merge.
The immediate incident: cloud_bridge_report_issue added three error-mapping arms
(token_missing, gh_api_error, payload_too_large) with no tests for the new
paths. The engineer offered “if you want, I can add tests” — framing tests as an
optional extra rather than table stakes. Without a regent yes, the offer would have
lapsed.
The four layers
Layer 1 — Clippy denies ship-and-defer patterns.
src-tauri/Cargo.toml workspace lints now include:
[lints.clippy]todo = "deny"unimplemented = "deny"unwrap_used = "warn"expect_used = "warn"let_underscore_must_use = "warn"These run in CI (cargo clippy --workspace --all-targets -- -D warnings). Justified
exceptions require #[allow(clippy::...)] // reason comments at the call site.
Layer 2 — casaconomy-backend-quality skill.
New agent skill at .agents/skills/casaconomy-backend-quality/SKILL.md, loaded by
Runa and any Rust-touching agent. It covers: every new match with 2+ arms needs
a test per arm; every error mapper needs a test per error class; let _ = expr is
banned without a log; the CAS-2394 incident is the canonical case study. The “if
you want, I can add tests” offer-pattern is explicitly called out as wrong framing —
tests are part of the ship, not an opt-in bonus.
Layer 3 — review checklist.
casaconomy-review-protocol now includes a required grep before any backend PR
approval:
git diff origin/master -- 'src-tauri/**/*.rs' \ | grep -E '^\+\s*(todo!|unimplemented!)\(|^\+.*let _ ='Plus a manual check: if the diff adds new match arms or new error variants, the
reviewer verifies that the corresponding test module was also updated. No new arms
without new test coverage.
Layer 4 — coverage evidence in ready-for-review comments.
casaconomy-task-worktree requires that ready-for-review comments for backend PRs
adding new code paths include either:
cargo test --workspaceoutput naming the new tests, or- An explicit list of new test names (“Added:
test_token_missing_...”), or // no tests because <reviewer-acceptable reason>(e.g. “pure boilerplate forwarding”).
The CAS-2394 case would have been caught: the comment cited 5 existing passing tests but named no new tests; reviewer would have asked.
Why we built it
The same root cause as CAS-2396 on the frontend side: agents default to “ship-and-move”, not “prove-and-ship”. Moving to a more capable model doesn’t address the failure mode structurally. The offer-framing pattern (“if you want”) puts quality decisions on the regent one at a time — that doesn’t scale. Guardrails make the right path the default.