requirements-to-acceptancelisted

# Requirements to Acceptance ## Purpose Convert an imprecise request into a **small, testable contract for success** without forcing the user to know every engineering requirement in advance. The output should clarify what must be true when the task is complete while preserving implementation freedom. ## When to use Use this capability when: - the user describes an outcome but not exact behavior; - multiple interpretations could produce materially different results; - a feature, bug fix, integration, or refactor needs explicit completion criteria; - professional requirements can be inferred from repository/context but should be distinguished from user requirements. Skip a formal acceptance contract for trivial, fully specified changes where success is already obvious and directly observable. ## Core principle **Infer engineering details; escalate product decisions.** Do not make the user specify technical requirements that a competent engineer can derive from the repository, platform, existing behavior, or ordinary professional practice. But do not silently invent product policy, destructive trade-offs, legal/business decisions, or user-visible behavior when plausible alternatives matter. ## Requirement classes Keep these classes distinct: 1. **Explicit** — stated by the user or authoritative task source. 2. **Repository-derived** — required by existing interfaces, conventions, tests, schemas, or compatibility commitments. 3. **Professional inference** — a propor