verify-test-strengthlisted

# verify-test-strength — make green mean something A passing test proves nothing until you've seen it fail for the right reason. Coverage is cheap and lies: an LLM-written suite can hit 100% coverage at ~4% mutation score — it *executes* the code without *asserting* on it. The fix is a **mutation-feedback loop**, not a one-off "try to break it": mutate the code, see which mutants the tests fail to catch, strengthen the tests to catch them, repeat. Static "write fault-detecting tests" guidance is the floor; the measured gain comes from iterating on real survivors. **Use this selectively.** The loop costs meaningfully more tokens and time than a normal test run, so reach for it on the tests that *matter* — the contract test guarding an invariant, the security/guard hook, the parser everything depends on — not on every test. For a quick change with no load-bearing test, the plain break-it rule (change the thing, watch the test fail, restore) is enough. ## 1. Scope it Name the **one module (or a few functions) under test** and **its test file**. Mutation testing is slow and noisy at scale, so a tight scope is what makes it usable. Point the mutation tool at deterministic, pure-logic code — skip I/O, network, template rendering, and hooks, where mutants are dominated by false-equivalents. ## 2. Run the mutation tool Only meaningful where a mutation runner is wired for the language: | Language | Tool | Wired? | |---|---|---| | **Python** | `mutmut` — `just test-mutation` | ✅