tddlisted

# Test-Driven Development Apply [`context-discipline.mini.md`](../../../standards/rules/context-discipline.mini.md): `grep` for the system-under-test before reading; never `Read` test fixtures or large generated files into this context. Apply [`grill-first.mini.md`](../../../standards/rules/grill-first.mini.md) **before** writing the first failing test. If the user handed you an issue/PRD/spec, open with grill questions on scope, edge cases, detection logic, and override patterns — even when the source doc looks complete. Skip only if those questions were already answered in the same turn. ## Philosophy **Core principle**: Tests should verify behavior through public interfaces, not implementation details. Code can change entirely; tests shouldn't. **Good tests** are integration-style: they exercise real code paths through public APIs. They describe _what_ the system does, not _how_ it does it. A good test reads like a specification - "user can checkout with valid cart" tells you exactly what capability exists. These tests survive refactors because they don't care about internal structure. **Bad tests** are coupled to implementation. They mock internal collaborators, test private methods, or verify through external means (like querying a database directly instead of using the interface). The warning sign: your test breaks when you refactor, but behavior hasn't changed. If you rename an internal function and tests fail, those tests were testing implementation, not behavio