tdd

Implement using strict TDD: $ARGUMENTS

Rules

• NEVER write production code without a failing test first.
• NEVER write more code than needed to pass the current failing test.
• Each cycle should be small and focused.

Cycle

1. RED — Write a failing test

• Add ONE test case that describes the next behavior to implement.
• The test name should read like a specification: should <expected behavior> when <condition>.
• Run pnpm run test and confirm the test FAILS.
• Show the user the failing test output.

2. GREEN — Make it pass

• Write the MINIMUM production code to make the failing test pass.
• Do not anticipate future requirements. Do not generalize.
• Run pnpm run test and confirm ALL tests PASS.
• Show the user the passing test output.

3. REFACTOR — Clean up

• With all tests green, improve the code:
  • Remove duplication
  • Improve naming
  • Extract methods or classes if they clarify intent
  • Ensure domain logic is in the right layer
• Run pnpm run test after refactoring to confirm nothing broke.

4. REPEAT

Ask the user: "What behavior should we add next?" or suggest the next logical test case.

Guidelines

• Start with the simplest case (e.g., happy path with minimal input).
• Progress to edge cases and error scenarios.
• Each test should test ONE behavior.
• Keep the feedback loop fast — run tests after every change.