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.

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.