05-deepak-patidar Release Readiness
"Done" and "ready for real users" are different claims. This skill is the go/no-go gate: a structured sweep that turns "I think it's ready" into a checked list with evidence. Run it before first launch, before major releases, and before handing anything to a paying client.
How to run it
Work through the seven gates below against evidence, not memory — for each item, the answer is a command output, a file path, a screenshot, or a tested behavior, never "yes, I'm pretty sure". Produce a written verdict at the end: ✅ ready / ⚠️ ready-with-known-risks (listed, accepted by the user) / ❌ blocked (by what). Deep-dive any failing gate with its dedicated skill (threat-model-security, deployment-safety, observability-readiness, etc.).
Gate 1 — Correctness of the money-and-data core
- Golden paths run end-to-end in a production-like environment, by hand, today — not "tests passed last week".
- Money math spot-checked against a calculator: one real invoice with discounts/tax/rounding, one payment, one return.
- Concurrent/duplicate actions tried: double-click submit, retry after timeout, two tabs. No dupes, no corruption.
- Test suite green from clean checkout; the regression tests for every previously found bug still exist and pass.
Gate 2 — Security minimum (threat-model-security)
- The IDOR test performed live: user A's token requesting user B's objects on every resource type → refused.
- Auth rate-limiting/lockout demonstrated, not assumed. Sessions revocable.
- Secrets audit: none in git history/client bundle/logs; prod secrets differ from dev; HTTPS enforced.
- Error responses leak nothing internal (trigger a 500 deliberately and look).
Gate 3 — Data safety (database-design)
- Backups: running, automatic, AND restored once successfully into a scratch environment — an untested backup is a hope, not a backup.
- Destructive operations inventoried: what can permanently delete/overwrite data, and what protects each (confirm, soft-delete, audit row)?
- The DB enforces its own invariants: spot-check that constraints exist in the live schema (not just in models).
Gate 4 — Deploy & undo (deployment-safety)
- Deployed-commit fingerprint verifiable in prod; deploy procedure documented and boring.
- Rollback rehearsed once for real. Migration pipeline handles "old code + new schema" coexistence.
- Config parity checked: every env var the code reads exists in prod; boot fails loudly if not.
Gate 5 — Eyes on production (observability-readiness)
- Error tracker capturing (send a test event), uptime check external, the three day-one alerts wired (down / error spike / queue age).
- One request traced end-to-end through logs by correlation ID, as a drill.
- The 4 incident questions answerable from tooling alone.
Gate 6 — Product finish (product-ux-quality)
- Five States sweep: pick every major screen; force loading/empty/error/overflow on each.
- Full run-through on a real phone, once on throttled network.
- A stranger (or the client) completed the golden path without you talking. Their confusion list is your bug list.
Gate 7 — Operations & the human stuff
- Support reality: when a user hits a problem, they can reach someone, and that someone can look them up (admin view/queries ready).
- Legal/compliance basics for the market: privacy policy, terms, data-deletion capability, tax correctness reviewed by someone qualified if money is involved.
- The bus-factor doc exists: how to deploy, where prod runs, where secrets live, how to restore — findable by someone who isn't you.
- Load sanity: golden path load-tested at 2–3× realistic peak (performance-improvement); connection-pool math checked.
The honesty rules
- Skipping a gate is sometimes right (an internal beta doesn't need Gate 7's legal pass) — but skipping is a decision the user makes, recorded in the verdict, never a silent omission.
- Anything found-but-not-fixed goes on a known-issues list in the verdict. A known risk accepted beats an unknown risk shipped.
- Re-run the failed gates after fixes; don't extrapolate green from "I fixed what it found".