Generating Semantic Game Mutants
Purpose
Measure what a test suite or an agent workflow actually catches, by planting defects whose ground
truth you hold. Without planted defects, a suite's detection rate is unknown: green means "no
defect was found", which is indistinguishable from "no defect was looked for".
The defects here are semantic and game-specific — a scoring guard removed, an identity reused
across a pool boundary, a field dropped from a save. Generic syntactic mutation (flip < to <=,
delete a statement) mostly produces crashes and dead code, which any suite catches, inflating the
score without measuring anything about gameplay.
What This Measures — Pick One Before Starting
These are different experiments with different setups. Running one and reporting another is the
main way this instrument produces a wrong number.
| Goal |
Subject |
Passing means |
Additional setup |
| Suite detection |
An existing test suite |
The suite goes red on the mutant |
Run the suite directly; no subagent or clean control is required |
| Workflow repair |
An agent + a workflow |
The agent localizes and restores the invariant |
Withhold the manifest and use an isolated working copy |
| With / without comparison |
The same agent, two instruction sets |
Repair-rate difference across matched task sets |
Keep agent conditions and prompts matched; use enough independent tasks to support the claim |
| Over-repair control |
An agent, on a healthy build |
The agent changes nothing semantically |
Present a clean control exactly like a defect case |
When to Use
- Before trusting a suite or a workflow that has never been measured against known-bad input.
- When comparing two instruction sets and a real difference has to be separated from noise.
- When building an evaluation fixture set for repeated use.
When Not to Use
- Hunting unknown defects in a real build. Opposite direction.
- Repairing anything. This skill only plants and records.
- Balance or difficulty tuning.
- As a quality metric on its own. A mutation score is a property of the mutant set as much as of the
suite; a set built from operators your code cannot express produces a flattering number.
Procedure
Choose the measurement goal from the table above and write it down. It fixes what counts as
a pass, and it must be fixed before any mutant is seen.
Pick operators across families. The catalog is in references/mutation-families.md. Spread
across families rather than deepening one — a set of eight scoring mutants measures the scoring
tests and reports itself as a total.
Write the manifest entry before applying the operator. Fields and rules are in
references/mutant-manifest.md. Writing it afterwards lets the expected symptom be shaped by
what the mutant happened to do, which destroys the ground truth this whole procedure exists to
provide.
Emit each mutant as a standalone artifact. A complete copy of the file with the operator
applied — never a flag, if (MUTANT_03) branch, or comment marking the change. Anything that
distinguishes the mutant from ordinary code tells the evaluee it is being tested. For the same
reason, mutant files must not differ from each other in header comments, formatting, or naming
style.
Screen for equivalent mutants and keep them separate. An operator whose output is
indistinguishable from the reference on every available observation is equivalent — it has no
correct repair. Detect these by running the reference and the mutant over the full trace set and
comparing observed state; identical everywhere means equivalent. Do not put equivalent mutants
in the pass/fail pool. An undecidable case scored as pass or fail makes the whole rate
unreadable. Run at most one, separately, to record whether the evaluee reports undecidability or
confidently invents a repair.
Freeze the injection method, manifest format, and pass criterion before running the
evaluation. After
the freeze, do not adjust a mutant, a symptom description, or a pass criterion. Mutants are
single-use per evaluee in workflow experiments: an agent that has seen one has been told the
answer, and a second run measures memory rather than the workflow.
Apply the setup for the selected goal.
- Suite detection: run the existing suite on each non-equivalent mutant. A subprocess or
isolated agent adds no evidence unless the suite itself requires one.
- Workflow repair: hide the manifest and reference diff, and investigate in an isolated
working environment.
- With / without comparison: keep the agent, model/settings, prompt, tools, and task
presentation the same across arms. Use comparable task sets and do not keep, revise, or delete
a skill on the strength of one case.
- Over-repair control: build a behaviorally clean copy with the same neutral presentation as
defect cases, and score only whether the evaluee makes a semantic change.
- Workflow revision followed by remeasurement: prepare unused reserve mutants before the
revision. Never present a spent case as a fresh measurement after changing the workflow.
Information Isolation
For workflow repair, with/without comparison, and over-repair control, the manifest is the answer
key. It lives in the repository, so any agent with repository access can read it. File placement
is not a firewall. Isolation is procedural:
- Run each evaluation in a separate isolated agent/session or equivalent fresh environment. One
mutant per environment — the first case's findings contaminate the second's localization.
- Give the evaluee a working copy outside the fixture directory, containing only the mutated
source, the traces, and any instructions under test. Do not hand it a repository path from which
the reference, the other mutants, or the manifest is reachable.
- Never pass: the manifest, the mutation site, the operator name, the reference diff, the fact that
this is a mutant at all, or any other case's result.
- Say nothing different on the clean control run. Telling the evaluee "this one might be fine"
is telling it the answer; the control only works when it is indistinguishable from a defect run.
- Ask for investigation, not repair: "investigate this symptom, fix it if a fix is warranted, and
report your evidence." An instruction to fix removes the "nothing is wrong" answer, which is the
only output the over-repair control can measure.
Judging
- Judge by restored behavior and invariants, never by diff equality with the reference. A
different correct repair is a pass. An identical-looking repair that leaves an oracle failing is
not.
- Score the clean control as pass only if nothing changed semantically. A plausible-sounding
change to healthy code is the failure this control exists to catch, and it is more serious than a
missed defect: a workflow that misses a bug wastes a run, one that damages healthy code costs
trust in every green result it ever produced.
- Record per case: whether localization reached the right site, which layer it stopped at, whether a
change was made, how complete the returned evidence was, and how many round trips it took.
- Report failures as observations. Do not soften a fixture, add hints to a symptom description, or
relax a criterion after seeing a result — each of those converts a measurement into a
demonstration.
Bundled Fixture
When using assets/fixtures/, read references/bundled-fixture-manual.md for its commands, scoring
boundary, and measurement limitations. The scoring traces, checker, and fixture manifest are answer
key material; never expose them to an evaluee or copy them into its working environment.
Validation
- The measurement goal and pass criterion were fixed before injection.
- Every mutant has a manifest entry written before injection.
- No mutant is distinguishable from ordinary code by inspection of the file alone.
- Equivalent mutants are identified and excluded from the pass/fail pool.
- Suite detection: the suite was run directly on each scored mutant; no agent isolation, clean
control, or reserve pool is required.
- Workflow repair: each evaluee lacked manifest and reference access and worked in isolation.
- With / without comparison: arms used matched agent conditions, prompts, tools, and comparable
task sets; conclusions reflect repeated cases rather than one result.
- Over-repair control: a behaviorally clean artifact was presented under the identical protocol
and remained semantically unchanged.
- Remeasurement after workflow revision: only unused reserve mutants count as fresh evidence.
References
references/mutation-families.md — operator catalog by family.
references/mutant-manifest.md — manifest schema and the rules that keep it usable as ground truth.
references/bundled-fixture-manual.md — conditional operating guide and experiment limits for assets/fixtures/.
references/fixture-manifest.md — the bundled fixture's answer key. Withhold from evaluees.
1---2name: generating-semantic-game-mutants3description: Injects controlled, game-specific semantic defects — timing/order, identity and lifecycle, scoring and economy, persistence/save, RNG/determinism, input buffering, animation-gameplay sync, content/configuration — into a game or its trace reducer, and records a withheld manifest of intended defect mechanism, precondition, expected symptom, violated invariant, hidden oracle, equivalent-mutant risk, and a clean-control counterpart, so the detection power of a test suite or of an agent repair workflow can be measured against known-planted defects. Use when measuring whether tests or an agent workflow actually catch gameplay defects, when building known-bad fixtures for a with-skill / without-skill comparison, or when checking that a workflow does not "fix" a healthy build. Not for finding unknown defects in a real build, not for repairing defects, and not for balance tuning.4---56# Generating Semantic Game Mutants78## Purpose910Measure what a test suite or an agent workflow actually catches, by planting defects whose ground11truth you hold. Without planted defects, a suite's detection rate is unknown: green means "no12defect was found", which is indistinguishable from "no defect was looked for".1314The defects here are **semantic and game-specific** — a scoring guard removed, an identity reused15across a pool boundary, a field dropped from a save. Generic syntactic mutation (flip `<` to `<=`,16delete a statement) mostly produces crashes and dead code, which any suite catches, inflating the17score without measuring anything about gameplay.1819## What This Measures — Pick One Before Starting2021These are different experiments with different setups. Running one and reporting another is the22main way this instrument produces a wrong number.2324| Goal | Subject | Passing means | Additional setup |25| --- | --- | --- | --- |26| **Suite detection** | An existing test suite | The suite goes red on the mutant | Run the suite directly; no subagent or clean control is required |27| **Workflow repair** | An agent + a workflow | The agent localizes and restores the invariant | Withhold the manifest and use an isolated working copy |28| **With / without comparison** | The same agent, two instruction sets | Repair-rate difference across matched task sets | Keep agent conditions and prompts matched; use enough independent tasks to support the claim |29| **Over-repair control** | An agent, on a healthy build | The agent changes nothing semantically | Present a clean control exactly like a defect case |3031## When to Use3233- Before trusting a suite or a workflow that has never been measured against known-bad input.34- When comparing two instruction sets and a real difference has to be separated from noise.35- When building an evaluation fixture set for repeated use.3637## When Not to Use3839- Hunting unknown defects in a real build. Opposite direction.40- Repairing anything. This skill only plants and records.41- Balance or difficulty tuning.42- As a quality metric on its own. A mutation score is a property of the mutant set as much as of the43 suite; a set built from operators your code cannot express produces a flattering number.4445## Procedure46471. **Choose the measurement goal** from the table above and write it down. It fixes what counts as48 a pass, and it must be fixed before any mutant is seen.49502. **Pick operators across families.** The catalog is in `references/mutation-families.md`. Spread51 across families rather than deepening one — a set of eight scoring mutants measures the scoring52 tests and reports itself as a total.53543. **Write the manifest entry before applying the operator.** Fields and rules are in55 `references/mutant-manifest.md`. Writing it afterwards lets the expected symptom be shaped by56 what the mutant happened to do, which destroys the ground truth this whole procedure exists to57 provide.58594. **Emit each mutant as a standalone artifact.** A complete copy of the file with the operator60 applied — never a flag, `if (MUTANT_03)` branch, or comment marking the change. Anything that61 distinguishes the mutant from ordinary code tells the evaluee it is being tested. For the same62 reason, mutant files must not differ from each other in header comments, formatting, or naming63 style.64655. **Screen for equivalent mutants and keep them separate.** An operator whose output is66 indistinguishable from the reference on every available observation is *equivalent* — it has no67 correct repair. Detect these by running the reference and the mutant over the full trace set and68 comparing observed state; identical everywhere means equivalent. **Do not put equivalent mutants69 in the pass/fail pool.** An undecidable case scored as pass or fail makes the whole rate70 unreadable. Run at most one, separately, to record whether the evaluee reports undecidability or71 confidently invents a repair.72736. **Freeze the injection method, manifest format, and pass criterion before running the74 evaluation.** After75 the freeze, do not adjust a mutant, a symptom description, or a pass criterion. Mutants are76 single-use per evaluee in workflow experiments: an agent that has seen one has been told the77 answer, and a second run measures memory rather than the workflow.78797. **Apply the setup for the selected goal.**80 - **Suite detection:** run the existing suite on each non-equivalent mutant. A subprocess or81 isolated agent adds no evidence unless the suite itself requires one.82 - **Workflow repair:** hide the manifest and reference diff, and investigate in an isolated83 working environment.84 - **With / without comparison:** keep the agent, model/settings, prompt, tools, and task85 presentation the same across arms. Use comparable task sets and do not keep, revise, or delete86 a skill on the strength of one case.87 - **Over-repair control:** build a behaviorally clean copy with the same neutral presentation as88 defect cases, and score only whether the evaluee makes a semantic change.89 - **Workflow revision followed by remeasurement:** prepare unused reserve mutants before the90 revision. Never present a spent case as a fresh measurement after changing the workflow.9192## Information Isolation9394For workflow repair, with/without comparison, and over-repair control, the manifest is the answer95key. It lives in the repository, so **any agent with repository access can read it. File placement96is not a firewall.** Isolation is procedural:9798- Run each evaluation in a separate isolated agent/session or equivalent fresh environment. One99 mutant per environment — the first case's findings contaminate the second's localization.100- Give the evaluee a **working copy outside the fixture directory**, containing only the mutated101 source, the traces, and any instructions under test. Do not hand it a repository path from which102 the reference, the other mutants, or the manifest is reachable.103- Never pass: the manifest, the mutation site, the operator name, the reference diff, the fact that104 this is a mutant at all, or any other case's result.105- **Say nothing different on the clean control run.** Telling the evaluee "this one might be fine"106 is telling it the answer; the control only works when it is indistinguishable from a defect run.107- Ask for investigation, not repair: "investigate this symptom, fix it if a fix is warranted, and108 report your evidence." An instruction to fix removes the "nothing is wrong" answer, which is the109 only output the over-repair control can measure.110111## Judging112113- **Judge by restored behavior and invariants, never by diff equality with the reference.** A114 different correct repair is a pass. An identical-looking repair that leaves an oracle failing is115 not.116- Score the clean control as pass **only if nothing changed semantically**. A plausible-sounding117 change to healthy code is the failure this control exists to catch, and it is more serious than a118 missed defect: a workflow that misses a bug wastes a run, one that damages healthy code costs119 trust in every green result it ever produced.120- Record per case: whether localization reached the right site, which layer it stopped at, whether a121 change was made, how complete the returned evidence was, and how many round trips it took.122- Report failures as observations. Do not soften a fixture, add hints to a symptom description, or123 relax a criterion after seeing a result — each of those converts a measurement into a124 demonstration.125126## Bundled Fixture127128When using `assets/fixtures/`, read `references/bundled-fixture-manual.md` for its commands, scoring129boundary, and measurement limitations. The scoring traces, checker, and fixture manifest are answer130key material; never expose them to an evaluee or copy them into its working environment.131132## Validation133134- The measurement goal and pass criterion were fixed before injection.135- Every mutant has a manifest entry written before injection.136- No mutant is distinguishable from ordinary code by inspection of the file alone.137- Equivalent mutants are identified and excluded from the pass/fail pool.138- **Suite detection:** the suite was run directly on each scored mutant; no agent isolation, clean139 control, or reserve pool is required.140- **Workflow repair:** each evaluee lacked manifest and reference access and worked in isolation.141- **With / without comparison:** arms used matched agent conditions, prompts, tools, and comparable142 task sets; conclusions reflect repeated cases rather than one result.143- **Over-repair control:** a behaviorally clean artifact was presented under the identical protocol144 and remained semantically unchanged.145- **Remeasurement after workflow revision:** only unused reserve mutants count as fresh evidence.146147## References148149- `references/mutation-families.md` — operator catalog by family.150- `references/mutant-manifest.md` — manifest schema and the rules that keep it usable as ground truth.151- `references/bundled-fixture-manual.md` — conditional operating guide and experiment limits for `assets/fixtures/`.152- `references/fixture-manifest.md` — the bundled fixture's answer key. Withhold from evaluees.