Release checklist

Use before a change merges or deploys, and before any report that says "done". The point is a report the reviewer can trust: what works is shown, what is not done is listed. Pair it with approvals (the human yes for the merge or deploy) and handoff (for whatever is left).

Checklist

1. Tests run on the final version, the commit that ships, not an earlier one. Give the command and the result ("212 passed, 0 failed"). New behaviour has a test; if not, say why.
2. Build: the production build passes from a clean checkout, not only the dev server.
3. Acceptance criteria: each one with how it was shown (a test, a screenshot, a command's output). Unmet ones are listed, not left out.
4. The change described: a few lines for the reviewer: what changes for users, what changes in the code, anything risky (migrations, configuration, permissions), anything removed.
5. Verified live versus not: three lists. Checked in the running app (say where: local, staging, production); checked only by tests; not checked. "Should work" belongs in the third list.
6. Rollback: how to undo it and how long that takes (revert the commit, redeploy the previous build, turn off the flag). For a migration or a data change, say whether it can be undone at all; if not, take a backup first and say so in the approval request.
7. Notes updated: changelog or release notes, the status file (what works, known limits), the docs for changed behaviour, the decision log if a decision was made.
8. Nothing private: no secrets, tokens, customer data or personal details in the diff, logs, screenshots or notes.
9. Approval: merging and deploying wait for a human yes on this exact version (approvals).

Report honestly

• Works: only what was verified, with the evidence next to it.
• Not verified: and why ("no staging access for the payment provider", "needs a real card").
• Planned: what is left, as backlog items with acceptance criteria, not as promises in prose.
• Never "done" because the code is written, never "tested" when only part of the suite ran, never "works in production" when only staging was checked.

Example report

Partial refund on the order page, commit <commit>
Works (staging, checked by hand): refund of part of an order; history row; inline error over the total.
Tests only: failed-refund path (provider stubbed). `npm test`: 212 passed. Build from clean checkout: passes.
Not verified: a real refund in the provider's live mode; needs the billing lead.
Rollback: revert the merge commit; no migration; about 5 minutes.
Notes: CHANGELOG and the refunds guide on the docs site updated; STATUS lists "refund emails" as not done.
Planned: refund email to the customer (backlog item filed, wording needs approval).
Waiting for: approval to merge this commit.

After it ships

• Check it where it runs: the screen, the logs, the error tracker, for the first minutes after the deploy.
• If it breaks, roll back first and investigate after; write what happened in the status file.
• Leftover work becomes backlog items (backlog-item); unfinished work gets a handoff note.