behavior-implementlisted

# Test-Driven Implementation Own the implementation cycle for one coherent observable behavior. Keep the implementation simple and limited to current requirements. Reuse an existing source of truth when the same rule or knowledge would otherwise be maintained in more than one place, but do not combine unrelated behavior merely because the code looks similar. Add abstractions, flexibility, and configuration only when a concrete current need justifies them. ## Workflow 1. Read the requested behavior, repository instructions, and closest implementation and test patterns. 2. Confirm that focused automated tests are proportionate. For engineering tooling and infrastructure, use this workflow only when native checks cannot credibly prove important behavior, concrete complexity or failure risk warrants regression coverage, and a focused deterministic test boundary fits the task. Otherwise leave this skill and use direct implementation with the applicable native checks. 3. Identify the observable outcome, important side effects, and state preserved on failure. At each dependency boundary, name the supported contract that makes the outcome reliable. Do not base a guarantee on undocumented or incidental behavior, or claim more than the contract supports. 4. Choose the smallest reliable mechanism with complexity and maintenance cost proportionate to the behavior. If no supported mechanism can meet the requirement without material scope growth, stop before implementation, explain the