tddlisted

# Test-Driven Development Build one thin, observable behavior at a time. Require each test to prove that it can detect the missing or broken behavior before relying on it. Read `references/evidence.md` when deciding whether strict TDD fits the task or when making claims about its effects. If delegation is explicitly authorized, use `delegate-work` only for disjoint vertical slices; never run concurrent red-green cycles against overlapping production code or shared tests. ## Establish the Test Contract - Identify the requested behavior, completion criteria, and stable public seam. - Read the repository's test instructions, framework configuration, nearby tests, and implementation patterns. - Use the existing test framework and commands. Do not introduce a new framework unless the user requests it or the task clearly authorizes it. - Establish the narrowest relevant baseline before editing. - Test behavior and contracts, not incidental private structure. If the behavior is still materially undefined, resolve it through the active planning workflow before writing tests. If no stable public seam exists, apply the active codebase-design workflow before exposing internals only for testing. ## Choose the First Vertical Slice Select the smallest end-to-end path that delivers observable value and reduces uncertainty. The first slice should cross the real integration seam needed by the behavior without building every case in advance. Order later slices by: - core success behav