# Releases

A release is how a version reaches production — the QA and implementation
team's surface, and the one the operation-phase plugin drives through the
[API](/api).

1. **Assemble** (`POST /v1/releases`) — pins the channel heads: the app
   versions with their commits since production, the config labels with
   the sets they change.
2. **Begin testing** — deploys the pins to the target environment and
   *holds* it: every repository in the release stays put until it ships
   or is abandoned.
3. **Request approval** — one promotion request per repository, decided
   by the approver its policy names. Requester and approver are two
   people.
4. **Approve and ship** — `stable` advances for every repository in the
   release; production follows stable and deploys.

## Regression suites

A release is tested against a **regression suite generated from what
ships**: the PRs in the app pins and the config revisions in the config
pins pick the areas, and the drafted steps are editable before running.

The executor model is extensible — the same suite mixes:

- **guided human** steps, walked by QA in the held environment;
- **agent** steps, dispatched (`POST …/regression-suite/dispatch`)
  against the held environment.

Every result is recorded through one operation —
`POST …/regression-suite/steps/{stepId}/result` — with **evidence**: a
screenshot of the run, attached to the step as its proof. Whether a
person or an agent ran the step, the release page shows the same thing:
the step, who ran it, and the screenshot that proves it.