tdd

# Test-Driven Development ## Core Rule Work in vertical red-green-refactor slices: 1. **RED**: write one test for one observable behavior. 2. **GREEN**: implement the smallest production change that makes that test pass. 3. **REFACTOR**: clean up only while tests are green. Do not write a batch of imagined tests before implementation. Each new test should respond to what the last cycle taught you about the actual behavior and interface. ## Plaited Defaults - Use `bun test` for targeted tests and `bun --bun tsc --noEmit` for the type gate. - Use `test`, not `it`, and organize with `describe`. - Prefer real dependencies and real runtime boundaries over mocks. - Mock only external boundaries such as remote APIs, time, randomness, or rare filesystem cases. - Avoid conditional assertions: assert the branch first, then assert branch-specific values. - Test both branches for conditionals, fallbacks, and error paths. - Exercise public interfaces and runtime contracts rather than private helpers. - Follow applicable repo skills and `AGENTS.md` rules for the touched area. ## When Starting Work Explore the codebase first. If the public interface, expected behavior, or risk boundary is discoverable from code, tests, or docs, use that evidence instead of asking the user. Ask one concise question only when the decision cannot be discovered and a reasonable assumption would be risky. Include your recommended answer. Before writing production code, identify: - the public interface...