targeted-mutation-testinglisted

## Context marker 🧬 When the skill activates, begin the first commentary update with `🧬` and a concise `Using targeted-mutation-testing ...` announcement. Do not repeat the marker on later updates unless another skill activates. # Targeted Mutation Testing Run mutation testing for one changed production class or component and its dedicated specifications. This is a completion check for meaningful behavior, not a package- or repository-wide quality metric. ## Scope Contract Require one explicit production target and its dedicated specification files. Mutate only that file. Run only its dedicated specifications. Do not use directory globs, whole-project mutation commands, unrelated tests, or a coverage percentage as a goal. Do not add mock-call assertions simply to kill a mutant. Skip only a pure rename, formatting-only change, generated code, or a user-approved exception. Record the reason. ## Workflow 1. Run the dedicated specifications first. 2. Run Stryker against exactly the target and its specs. For example: ```bash npx stryker run \ --mutate src/path/ChangedThing.ts \ --testFiles src/path/ChangedThing.test.unit.ts \ --testRunner vitest \ --coverageAnalysis off ``` 3. If the target run is too slow or unreliable, divide only that file into explicit mutation ranges. Preserve the complete range accounting; never describe a sampled range as a full run. 4. Classify every result: - **Killed**: record it. - **Actionable survivor**: add one state- or o