Stop adding a regression test for every bug

Adding a test for every production bug is a habit worth dropping, because most of those tests pin one symptom that will never recur in that exact shape while the real class of failure stays open. A regression-test-per-bug reflex is the move where you close an incident with one narrow assertion instead of guarding the category the bug came from. After enough incidents you own a slower test suite and the same escape rate. The fix is not a better assertion. It is a receipt the reviewer can read.

Why the test-per-bug habit quietly fails

Think about armoring a bomber by looking only at the planes that came back. The holes you see are in the spots a plane can survive. The dangerous hits are on the planes that never returned, and you have no data on those.

A test per bug does the same thing. It reinforces the exact spot where a defect already surfaced and survived, and it tells you nothing about the failure class that has not come home yet.

So the honest answer to "should I add a regression test for every bug" is usually no. Guard the class, run the guard, and write down that it ran. The cheapest place to lose trust after an incident is a green check nobody can explain.

Trade one more test for one missing receipt

After a bug, the better question is not which test was missing. It is which receipt was missing. A receipt is the small written record that lets a reviewer judge your fix without reverse-engineering the diff.

Here are four common failure classes and the receipt that closes each one.

Permission creep in Claude Code. Many production bugs are policy bugs. On a shared laptop, bash approvals turn into muscle memory and a session starts inventing its own test policy mid-run. The fix is a supremacy clause at the top of CLAUDE.md that states which hooks win, which folders need human eyes, and where temporary overrides live. Claude Code, Anthropic's coding agent, documents the mechanics in its getting-started docs. Policy stops being a per-session guess.

Replay gaps in Codex. A green merge from the Codex CLI, OpenAI's coding agent, can hide the fact that no reviewer ever saw which commands proved the guard. The fix is a replay sandwich: AGENTS.md requires an intent line, the command transcript, and a diff summary before the PR opens. Now the guard's execution is in the record, not a claim in your head.

Blast radius on MCP connectors. Some bugs no unit test will catch. A connector touching data nobody put on the diagram is a boundary failure. The Model Context Protocol spec gives you the words to scope it. The fix is a connector card: one markdown card per MCP server listing allowed actions, forbidden actions, owner, and rollback. The class of bug gets an owner.

Handoff blur in chained agents. When one agent forks work to another, the child often reports a summary that omits the paths it actually changed, so the fix you reviewed is not always the fix that ran. The fix is a child receipt block: every child returns the paths it touched, the commands it ran, and the tests proving its guards.

You can encode the boundaries themselves as a rule file. Here is a starting card you can paste and adapt.

---
description: Delegation boundary snapshot (adapt globs to your repo)
globs:
  - "**/*"
alwaysApply: false
---

- Cursor: keep scopes explicit in `.mdc`; forbid undeclared MCP domains.
- Claude Code: cite `CLAUDE.md` precedence before expanding bash scope.
- Codex: ensure `AGENTS.md` carries replay-friendly verification notes for CLI runs.

Cursor, Anysphere's AI code editor, plugs rule files in exactly here; its agent docs show where. The broader habit set lives under agentic coding governance, and the split between proving behavior and proving you can explain it is the heart of our methodology.

Make a bug-fix PR answer four questions

A bug-fix PR earns its merge by answering four questions in writing. If a reviewer can read the answers off the PR body, you have a receipt. If they have to guess, you have theater.

Paste this checklist into the PR and tick it off:

• Forked agent work lists parent and child responsibilities.
• Red-folder paths got explicit human acknowledgement.
• Scopes in the PR body match the folders in the diff.
• Verification command output is pasted or linked.

Picture two clocks running on every team: one for shipping, one for explainability. A test per bug winds the shipping clock and lets the other one stop.

Common questions

• Should I add a regression test for every bug?

  Usually not. A test pinned to one escaped defect guards a symptom that rarely recurs in that exact shape, while the class of failure stays wide open. Add a guard for the whole class instead, run it, and put the proof in the PR with a replay sandwich so the reviewer can confirm the guard actually fired.

• What proof should a bug-fix PR include?

  Three receipts: an intent line, the command transcript showing which checks prove the regression guard, and a diff summary. Add a short note recording the constraints you considered and the alternatives you rejected. That way the reviewer judges your approach on purpose instead of inferring it from the diff and hoping.

• What is verification theater?

  Verification theater is a green check with no reviewable story behind it. Commands ran, but nobody can point to which ones proved the guard. It is the failure mode behind test-per-bug suites, merged CLI greens with no transcript, and review threads that turn into archaeology weeks later.

• Where do I find the failure classes worth guarding?

  You do not have to invent the catalogue. The OWASP Top 10 for LLM applications and the NIST AI Risk Management Framework already name the classes worth guarding, which makes them a good starting list for your connector cards and red folders.

Try it on your next retro

Pull your last three incident PRs and check whether each added test guards a class or pins a symptom, then keep only the habits that closed a class. If your retros keep proposing the same test, book a 15-minute sync and we will rehearse the receipt-first version with your team.