Skip to content

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:

Terminal window
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 --workspace output 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.