tdd

# TDD: red, green, refactor Write the test before the code. A test written first specifies the behavior, fails for a known reason, and gives you a definition of done you can run. A test written after tends to describe whatever the code happens to do — bugs included. ## Step 1: Find the test runner Don't assume the command. Detect how this project runs and writes tests: look at existing test files for the framework and conventions, and at the build/config for the invocation (`go test ./...`, `npm test`, `pytest`, `cargo test`, …). Match what's already there — same framework, same layout, same style. ## Step 2: Name the behavior as tests (RED) State the change as concrete cases before writing any implementation: - The main success path — the behavior actually requested. - The edges — empty, zero, boundary, maximum, unexpected input. - The failures — what should error, and how it should error. Write these as tests. For a bug fix, the first test **reproduces the bug**. Keep each test focused on one behavior with a clear name. ## Step 3: Watch them fail Run the tests and confirm they fail — and fail for the *right* reason (the behavior is missing), not a typo or an import error. A test you never saw fail proves nothing. This is the gate: do not write implementation until you've seen red. ## Step 4: Implement to green Write the **minimum** code that makes the tests pass. No features the tests don't demand, no speculative abstraction. Run the tests until they're green. #...