Playtest → fix loop: reports a coding agent can act on

What it's for

Use it once the first build exists and you're into play → report → fix. It handles two kinds of problem:

• Bugs: something happens that shouldn't (falling through a floor, a door that never opens, a score counted twice). These need steps to reproduce, expected against actual, and evidence.
• Feel problems: everything works, but it feels floaty, slippery, laggy or weak. These need a measurement and a target, because "make it feel better" invites the model to add particles, screen shake and a dash you never asked for. Target numbers are in game feel tuning.

The loop rests on five rules. They're worth adopting even if you never paste the templates:

1. One problem per round. Two changes in one round means that when things get better or worse, you can't tell which change did it.
2. Causes before code. The model lists up to three likely causes, each with the file and function it suspects, then tests the top one. This stops it fixing a symptom somewhere else, like raising friction to hide velocity being applied twice.
3. The smallest change that tests the cause. A hard cap (1–2 files, about 20 lines, no refactors, no new dependencies) keeps every diff reviewable in under a minute.
4. Measure before and after. If the problem can't be seen as a number or a log line yet, the round's only job is to add that readout.
5. Keep or revert, never pile on. A change that didn't help is undone before the next idea is tried, so the codebase doesn't fill up with half-fixes.

A round takes 3–10 minutes. Ten clean rounds move a prototype further than an afternoon of "it's still wrong, try again".