tddlisted

# TDD Implement software through short feedback loops that make each behavior and design decision observable. ```text List → Red → Green → Refactor → Repeat ``` Treat this as a design discipline, not merely a requirement to write tests first. Preserve the user's requested workflow and apply the strongest test-driven feedback that fits the task. ## Choose the Operating Mode Choose the mode before editing production code. - **Behavior change**: Use the full List → Red → Green → Refactor loop. - **Bug fix**: Reproduce the reported failure with a regression test, then make the smallest fix. - **Untested existing code**: Capture relevant current behavior with a characterization test, then add a failing test for the desired change. - **Pure refactoring**: Establish relevant Green coverage and refactor in small steps. Do not manufacture a failing test when observable behavior must not change. - **Exploration**: Run the smallest useful spike when an SDK, algorithm, or external behavior is unknown. Keep or discard the spike deliberately, then test the stable behavior before treating production work as complete. - **Non-behavioral work**: Skip strict TDD for visual-only styling, mechanical migrations, generated output, and documentation-only changes unless an executable check protects a real contract or risk. ## Prepare Before starting a cycle: 1. Identify the target behavior and useful observation boundary. 2. Inspect nearby code and tests for the established framework, namin