test-first-implementationlisted

# Test-First Implementation Production code follows a failing test. A test written after implementation can describe the code but cannot prove it would have caught the missing behavior. Before the first test, inspect the entry point, callers, nearest convention, and existing coverage. If the cause of a failure is unknown, use `systematic-debugging` first. ## Red, green, refactor 1. Write one small test at a stable observable boundary. Prefer real behavior over assertions about mocks. 2. Verify red: run it and confirm a clean failure for the expected missing behavior, not a typo or setup error. 3. Add the minimum implementation that can satisfy that test. Avoid new options, abstractions, and adjacent cleanup. 4. Verify green: run the focused test and read its full result. Fix production code when it fails. 5. Refactor only the changed code while keeping the test green. Repeat for the next behavior. Use mocks only after understanding the real dependency. Do not add production APIs used only by tests. Run the repository's broader suite at the task or milestone boundary and before a completion claim. ## Code judgment Repository instructions, existing code, and configured project tools are authoritative; skills supply defaults only where the repository is silent. Match local idioms, package boundaries, and public contracts unless they violate the requested behavior or a clear safety property. Mechanical style stays with the formatter, linter, and tests. Type