← ClaudeAtlas

equivalent-mutantlisted

Use when a surviving mutant looks like a coverage gap but no falsifiable test can kill it in the current architecture. Re-classify it as equivalent; a test passing either way is the slop it hunts.
MrBinnacle/skills · ★ 0 · AI & Automation · score 68
Install: claude install-skill MrBinnacle/skills
# Mutation Equivalent-In-Current-Architecture ## Problem Mutation testing surfaces surviving mutants. The default disposition is to write a killing test (close the gap). But some surviving mutants are **structurally unreachable** by any falsifiable test in the current code architecture — usually because they're on a guard or branch that's never the FIRST guard/branch to fire on the relevant input domain. Naive response: write a test using a disjunction (`assert reason in ("A", "B")`) that "passes" against both current code and the mutation. This is double-slop: 1. The mutation isn't killed (the test passes under the mutation). 2. The test itself is the canonical ai-slop "tautological assertion / disjunction that passes either way" pattern that mutation testing exists to surface. Honest response: declare the mutant **EQUIVALENT-IN-CURRENT-ARCHITECTURE**, document the architectural constraint that blocks independent killability, and defer the architectural refactor (if desired) to a v-next punch list. The mutant remains uncovered in the report but the disposition is honest about why. ## Context / Trigger Conditions - A mutation-testing tool reports a surviving mutant. - Initial reading of the mutant suggests it's a genuine coverage gap. - On closer inspection, the mutated code path can only be reached via inputs that ALSO trigger an earlier guard which short-circuits before reaching the mutated line. - The earlier guard ALSO has a mutation on it (or a separate tes