September 13, 2026
90.D — FIRST RELEASE CHECKLIST

Scope, testing, preview, review, launch, and rollback. Companion to Lesson 90.6. Run it in order; no step skipped silently — deferred steps get a trigger date, not a shrug.
The checklist
# FIRST-RELEASE-CHECKLIST — [Project], [flow], [date]
## Scope locked
- [ ] One flow written (5–9 steps) + acceptance criteria (each with how-checked)
- [ ] Non-goals listed, each with revisit trigger
- [ ] Dependencies present (sources, keys, reviewer, approval)
## Built clean
- [ ] Tasks ≤ half a day, each on its own branch
- [ ] SPEC + TASKS + DECISIONS updated (memory current)
- [ ] Review + tests pass (unit/integration/manual as planned)
## Preview (silent-watch test)
- [ ] Preview env = production-shaped, test data separated
- [ ] Named preview user + date set
- [ ] User completes flow without help while you watch silently
- [ ] Feedback filed (quotes + observed friction)
## Go / no-go
- [ ] Decision logged (go / fix-list / no-go) with owner + date
- [ ] Fix-list items are tasks with branches, not hallway promises
## Production
- [ ] Deploy + confirm logs, alerts, cost tracking live
- [ ] Support route + response promise published
- [ ] Rollback rehearsed: last-good state, revert steps, decider, user message
## After (within 7 days)
- [ ] Evidence signals from 90.7 collected against hypotheses
- [ ] Costs vs caps reviewed; quality sample taken
Pass rules
Preview passes only on unassisted completion. Any narration, prompt, or hot-fix is a fail — fix the path, re-preview. Production is earned, not scheduled: a date without a passing preview is a wish. Rollback must be writable from memory by the owner: commands, decider, and the exact user message ("we reverted to [state]; your [data] is [safe/effected]; next update [when]").
What blocks, what bends
Missing acceptance criteria and an untested rollback block the release — no exceptions. A thin backlog or an imperfect preview script bends: note the gap, set a fix date within seven days, and proceed only with the owner written approval in the decision log. The distinction matters because teams that bend on blockers ship incidents, while teams that block on imperfections never ship at all. Write which rule bent and why, so the Lesson 90.10 reviewer can judge the call.
Verify fast
Pre-mortem before launch day: state the revert commands aloud, name the decider, read the user message. If any answer is "we will figure it out," the checklist is incomplete. After launch, confirm the three live proofs: one log line from a real run, one cost line from a real bill, one support path a stranger could find. File all three next to the go decision so the Lesson 90.10 reviewer sees evidence, not recollection.
ARTICLE DISCUSSION
JOIN THE
CONVERSATION.
Got a question, a take, or a better way to do this? Log in and leave a comment.
