release

Invoke the release workflow with a version number and it walks through sequential gates: code-complete verification, QA regression sign-off, security review, documentation updates, and release notes approval. Each gate must pass before the next begins, and critical bugs or security findings stop the process.

A canary deployment routes a small percentage of traffic to the new version before full rollout. This workflow deploys to staging, then canary at 5% traffic with a 30-minute soak, then production, auto-rolling back if error rate rises over 1% or crash-free rate drops below 99.5%.

Use the release workflow for cutting a full versioned release to production with QA and security sign-off. For taking a single feature or branch to a merged pull request, use the ship-it workflow instead, as the release gates are too heavy for individual PRs.

The release process stops immediately when critical or high-severity bugs are found during QA sign-off. The bugs are routed to the responsible engineer, and the release cannot proceed to security review or deployment until they are resolved.

Yes, after deployment it saves a release record to docs/artifacts, tags the release in git, and updates the board. On GitHub backends it labels shipped issues with the release version; on markdown boards it clears the Done column in the same PR as the release record.