spec-productlisted

# Spec Product Author the product spec: the durable **what**, **why**, and **proof obligations** for an evergreen capability. A product spec is upstream of slices and design. It defines the product contract that later agents use to scope changes, derive implementation design, verify correctness, and avoid inventing missing intent. ## Boundary Use a product spec when the subject is an enduring capability, product surface, user/system need, or behaviour family. Do not use a product spec when the subject is a single bounded change. Use `/slice` for the change scope instead. Do not include implementation design, architecture, code structure, algorithms, storage layout, or phase plans. Put technical solution material in `/spec-tech` or `/design`. ## Canonical structure Use this shape unless the user explicitly supplies a different canonical template: ```md # {{ref}}: {{title}} ## 1. Intent Problem, value, and desired outcome. ## 2. Scope In scope, out of scope, and boundaries. ## 3. Principles Non-negotiable product/domain stances. ## 4. Requirements Framing sentence plus constraints and invariants only. Functional/quality requirements live as entities (synthesized below), never as prose rows. ## 5. Success Measures Expected outcomes, metrics, signals, and acceptance gates. ## 6. Behaviour Primary flows, alternate flows, edge cases, guards, and failure modes. ## 7. Verification Verification approach in prose; no coverage table; cite durable REQ-NNN, not labels. ##