implementation-qualitylisted

# Implementation Quality Working code is not enough. The bar is code that is correct, verified, secure, maintainable, and proven, not asserted. This capability applies to any code that ships, touches data, handles auth, or that someone else will maintain. Throwaway scripts do not need the full gate; say so when you skip it. ## Workflow 1. **Understand** the requirement; restate the observable behavior, callers, inputs, outputs, invariants, and failure modes. Surface ambiguity before building. 2. **Inspect** repository instructions and the nearest analogous implementation before choosing a pattern. Distinguish a requested behavior change from an accidental compatibility break. 3. **Design** the smallest complete slice: existing architecture, idioms, dependency set, and error model. Name the approach and why. 4. **Identify risks** up front: security, data, performance, concurrency, failure modes. Route to the matching capability when one applies. 5. **Implement** to the standards below. 6. **Self-review** the diff as a red-teamer, then run the completion gate (`testing-verification`). ## Standards - Keep validation at boundaries and domain invariants near the state they protect. Preserve error context; never turn failures into silent defaults or false success. - Strong typing where the language offers it; no loosening the type system for convenience. - Extract an abstraction only when current duplication or variation proves it useful. No speculative generality, no new depe