design-pricinglisted

Design a pricing model that is both commercially sound and implementable with Stripe's product/price/subscription primitives. Non-autonomous: every tier, limit, and Stripe mapping is proposed and confirmed before being written to the spec. ## Phases 1. **Load context** — read `docs/specs/prd.md` for the target user personas and success metrics, and `docs/specs/idea-validation.md` for willingness-to-pay signals. If neither exists, ask the user to describe the intended audience and rough price sensitivity. 2. **Propose tier structure** — suggest 2–4 plan tiers (e.g., Free/Starter/Pro/Enterprise) with names, monthly and annual prices, and the key differentiating limits (seats, usage units, feature gates). Present the tiers as a comparison table. Ask the user to adjust before moving on. 3. **Define metered units and feature gates** — for each tier, specify: which features are gated (boolean), which are metered (unit name, included allowance, overage price), and the upgrade trigger (what makes a user need the next tier). This informs which Stripe Price objects will be `recurring` vs. `metered`. 4. **Design upgrade/downgrade and trial rules** — propose: trial length (days), trial-to-paid conversion behavior, proration strategy on plan changes, and what happens to data when a user downgrades below a current-usage limit. Get explicit sign-off on these rules — they have customer-experience implications. 5. **Map to Stripe objects** — for each tier, define the Stripe Product name, Pri