red-green-refactor-tddlisted

# Red Green Refactor TDD Use red-green-refactor for behavior changes. ## Loop 1. **Red** — write or update the narrowest deterministic test that proves the desired behavior or reproduces the defect, and observe it fail for the expected reason. 2. **Green** — make the smallest correct production change and rerun that focused test plus directly affected boundary tests. 3. **Refactor** — improve structure only when useful, keeping the same behavior green. The safety invariant is observed RED before the implementation and GREEN afterwards. Separate pushed RED/GREEN commits are optional; do not create Git/CI choreography solely to demonstrate the process. ## Bugs: fix the invariant, not just the occurrence For a defect: - name the violated invariant; - search sibling callers, providers, modes, transports, install paths, and equivalent implementations for the same defect class; - repair in-scope occurrences or make the shared owner enforce the invariant; - keep one durable canonical regression at the narrowest boundary that would catch recurrence. ## Match evidence to the real boundary Prefer production-shaped behavior over convenient test behavior. Use broader evidence only when the contract crosses that boundary: - external API/CLI/browser -> exercise or qualify the real request/protocol shape when mocks cannot prove it; - timeout/network/concurrency -> inject hostile failure, non-settling operations, cancellation, retry, or race behavior as relevant; - persistence/inst