spec-vs-shippedlisted

# Spec vs. Shipped Compares the promise to the artifact. Produces a line-by-line reconciliation — shipped as specced, shipped differently, silently dropped, or shipped but never in the spec — and turns each gap into a decision rather than a complaint. **Grounded in:** *Inspired* — Marty Cagan: the spec exists to manage value, usability, feasibility, and viability risk, so a gap between spec and build is a risk that came back unpriced. Paired with blameless postmortem practice from *The DevOps Handbook* — Gene Kim et al.: the drift is almost always a rational local decision made under pressure, and the useful question is what made it invisible, not who made it. **The load-bearing idea:** most delivery drift is never decided, only accumulated. Nobody chose to drop the empty state — it just never came up again. This skill makes the accumulation visible while it's still cheap. ## When to use this - Before writing release notes or a launch announcement, so you don't announce something that didn't ship. - At the end of a milestone, before the retro, so the retro argues about causes instead of facts. - When the product and the PRD have visibly diverged and nobody can say by how much. - Before a stakeholder update where you'll be asked "is it done?" and need a defensible answer. - When taking over someone else's project and needing to know what the spec still describes accurately. - After an incident traced to behavior nobody remembered agreeing to. ## Before you start (gather t