tdd

# TDD ## Execution Context Use this procedure directly in the primary conversation for every code change, regardless of size. The user may switch that conversation to the lower-cost implementation model before beginning the Red-Green-Refactor cycle. Implement code changes using strict Red-Green-Refactor. Iron law: **no production code without a failing test first.** Wrote code before a test? Delete it. Start over from a failing test. ## Related skills - **`/e2e`** — Follow this procedure when the current task needs Playwright E2E coverage. - **`/pr-fixup`** — After the task-defined checks pass and the PR opens, use it only for CI or actionable reviewer findings. ## When to use - Bug fixes — write a test that reproduces the bug before fixing - New functions, methods, or utilities - Refactoring existing logic that lacks tests **Skip** for: pure UI components (we don't test React components), config files, generated code. For UI rendering bugs, prefer extracting or using a pure helper and testing that helper. Add Playwright only when the behavior is truly visual or integration-level. Avoid adding React component tests just to assert DOM output; that does not match this project's testing convention. ## Determine test scope When implementing a UI work order, read its ASCII UI preview and linked plan before changing the surface. Use the structural requirements to guide the existing rendered checks; do not test ASCII whitespace or treat it as exact pixel geometry. Keep...