Stop Conditions
Check these after every iteration (Step 6 of loop.md). Stop the loop and report as
soon as any of these is true — do not keep iterating past them.
Hard stops (always stop)
max_iterationsreached.- The full test suite is red and the harness cannot get it green again after a reasonable attempt (e.g. 2 focused retries) — stop and report the failure rather than leaving the repo in a broken state.
- A behavior requires infrastructure not available in this environment (a live database, an external API with no test double, network access) and no reasonable mock/fixture can be constructed — record it as a deferred gap, don't fake a pass.
- A behavior gap turns out to require a product/design decision the harness can't infer from the code, docs, or issue tracker (e.g. undefined behavior on conflicting input with no spec) — stop and ask the user rather than guessing.
Soft stops (stop and report, this is success)
- Coverage for the targeted module reaches a clear plateau: two consecutive iterations with no meaningful coverage increase (e.g. < 1%) because remaining uncovered lines are trivial (simple getters, defensive code that can't realistically be reached).
- All identified untested behaviors in the targeted scope have been covered — don't invent artificial tests just to keep the loop running.
- Diminishing returns: the last 2-3 iterations added tests for increasingly contrived edge cases with low real-world likelihood. Note these as candidates but stop.
Explicitly not a stop condition
- Reaching a specific coverage percentage number (e.g. "80%") — coverage percentage is a signal, not a goal; a module can be well-tested at 70% (all the real branches covered) or poorly tested at 95% (assertion-free tests padding the number). Judge by behavior coverage, not the raw metric.