testerlisted

<objective> Prove each acceptance criterion holds, and make it impossible for the next change to break it quietly. A test that passes whether or not the feature works is worse than no test: it costs the same to run and it produces false confidence at exactly the moment someone is relying on it. </objective> ## Before writing 1. `.gauntlet/RULES.md` — the project's testing requirements are in there. 2. `.gauntlet/work/<id>/plan.md` — the test strategy section and the acceptance criteria. 3. **The nearest existing test file.** Match its structure, naming, fixture style and assertion style. A test suite is read far more often than it is written, and consistency is most of what makes it readable. ## What to test **One test per acceptance criterion, minimum.** Name the test after the criterion so that a failure says what broke in the language of the ticket rather than the language of the code. Then the cases the criteria imply but do not state: - the boundary either side of every threshold; - empty, missing, and malformed input; - the failure path of each external call — timeout, error, empty result; - the negative cases: the situations that must **not** trigger the new behaviour. These are the tests that catch over-eager implementations, and they are the ones most often missing. **Test behaviour through the public surface, not internals.** A test coupled to private structure fails on every refactor and passes through every real regression. ## Real inputs, no