design-it-twicelisted

# Design It Twice Explore genuinely different interfaces before a consequential technical choice is committed. This is a decision aid, not implementation. Do not edit repository files or select a product preference on the user's behalf. This workflow adapts the Design It Twice mechanism documented in Matt Pocock's engineering skills and applies it without an issue tracker. ## Applicability gate Run only when all are true: 1. the decision creates or materially changes an important public, module, service, platform, data, or provider interface; 2. the decision is hard to reverse after callers or persisted data depend on it; 3. at least two credible designs remain after repository conventions and factual research; and 4. the result could materially change coupling, invariants, error handling, compatibility, testing, or task boundaries. Skip local helpers, routine implementation, small visual choices, speculative extensibility, and anything existing conventions already settle. Return `not-applicable` with the reason instead of manufacturing alternatives. ## 1. Frame the decision State: - the exact decision to make; - current behavior and callers; - constraints and invariants every design must preserve; - dependencies and trust boundaries; - ordering, concurrency, persistence, compatibility, and error requirements; - test and integration seams; - relevant repository paths or durable source documents; and - which facts are verified versus still uncertain. If a factu