one-man-startup / rules

---
description: "The release checklist - QA pass, reviews in, rollback written, backup tested, then merge, migrate, deploy and announce, each on the founder's go - and the watch after. Use for every release to users."
alwaysApply: false
---

<!-- Generated by tools/sync_adapters.py from skills/release/SKILL.md. Edit the source, not this file. -->

# Release

Run in order. Any line not met stops the release.

## Before

1. `docs/work/<id>/qa.md` says PASS or PASS WITH KNOWN ISSUES, and the founder has read the issues.
2. `security.md` has no open critical or high; `legal` has no RED on the launch path.
3. If the product has a free tier or trial, every cap row is `T`: a test proves each per-user,
   per-device and global limit holds.
4. `python tools/run_all.py` green on the release commit; CI green on the same commit.
5. Release notes written in `docs/work/<id>/release.md`: what users will notice, in their words,
   and one line `Rows shipped: <ids>` naming every row the release ships. Each must be `T`: from now on its test runs in every
   sweep, so a later change that breaks it goes red (TPL-109, TPL-110).
6. **Rollback written down:** the exact steps and how long they take. If a migration cannot be
   reversed, say so and get the founder's explicit acceptance.
7. Backup taken and a restore of it tried, this session.
8. For a web feature, the performance scorecard is in `qa.md` with a source for every value
   (`skills/performance/`); for any new production path, a failure forced in staging was found
   from the telemetry alone and each new alert fired once (`skills/observability/`).

## Steps, each on its own go (`skills/ordered-steps/`)

1. Merge to main.
2. Run migrations.
3. Deploy.
4. Smoke test production: the main flow end to end, as a user.
5. Announce.

## After

Fold the feature's `contract.md` and `ux.md` into `docs/contract.md` and `docs/ux.md`: apply
what each adds, changes and removes, so the current files describe what is live (TPL-98). The
idea is OpenSpec's archive step, which merges a change's delta specs into the living specs
(https://github.com/Fission-AI/OpenSpec, read 2026-10-28); here it is a written step, not a
script. Watch errors and the feature's success number for the window set in the spec. On a major
error, `qa` writes ROLLBACK and the orchestrator starts `rollback`: roll back first (on the
founder's go) and investigate second, with `debugger`. Write a short entry in `docs/HISTORY.md`.

Close the gate: add `Build pass: closed <date> (released)` to `docs/work/<id>/readiness.md`, so
the next change to product code needs its own pass (TPL-120). Then the retrospective, below.

## Retrospective (TPL-124)

After the watch window, the orchestrator writes `docs/work/<id>/retro.md`: what the founder
asked for, what shipped, what `reviewer` and `qa` caught, the rows left open, and one lesson for
`docs/requirements/p1-traps.md` if there is one. It ends with a verdict: `accepted`,
`accepted-with-open-items` (each item a row or an open question) or `rejected`. A row in
`Rows shipped:` that is not `T`, or a blocking finding still open, makes it `rejected` unless
the founder accepts otherwise. The founder gets the verdict as a decision card and has the last
word. Action items are written, not done: each goes back through a track. Adapted from
BMAD-METHOD's epic retrospective (https://docs.bmad-method.org/build/finish-an-epic/, read
2026-10-30). The next retrospective starts by checking the last one's items were done.