tdd-bug-reproductionlisted

# TDD and Bug Reproduction ## Purpose Turn intended behavior into executable evidence before relying on an implementation claim. For a bug, first prove the failure you intend to fix. For a new behavior, define the smallest useful test contract when the repository and task make test-first work informative. This capability uses TDD as an engineering method, not as a ritual. ## When to use Use this capability when: - fixing a reproducible defect; - changing observable behavior covered by an existing test system; - adding logic where a focused test can establish the contract before implementation; - preventing a regression whose failure mode can be captured reliably. Do not force a synthetic RED phase for documentation-only edits, generated artifacts, one-time exploratory work, or bootstrap/infrastructure steps where no meaningful executable behavior exists yet. In those cases define the closest useful verification instead. ## Core principles ### Reproduce the intended failure, not just any failure A red test is useful only if it fails for the reason the task is supposed to fix. ### Use the nearest trustworthy test layer Prefer the smallest layer that can observe the real behavior without mocking away the defect: - unit when the contract is local and pure; - component/module when collaboration matters; - integration when boundaries, persistence, serialization, network adapters, or framework behavior cause the bug; - end-to-end only when lower layers cannot represent