release-engineering

# Release Engineering Turn a release into a sequence of evidence-backed decisions rather than one irreversible event. ## Build the release contract Record the artifact/version, environments, owner, change scope, affected users, data or contract changes, dependencies, risk class, maintenance window, and success metrics. Use [release-record.md](references/release-record.md) for the go/no-go and rollout record. ## Establish gates Require checks proportional to risk: build and tests, contract and migration proof, security findings, performance budgets, smoke paths, accessibility or visual checks, artifact signing/provenance, monitoring, and a tested recovery path. A green generic pipeline is not proof of the release's critical behavior. ## Roll out safely 1. Separate deployment from exposure with a flag or routing control when practical. 2. Start with internal, shadow, canary, or low-percentage traffic. 3. Compare errors, latency, saturation, business outcomes, and support signals against a pre-release baseline. 4. Promote only after the observation window and all gates pass. 5. Roll back or disable immediately when a predefined threshold is crossed. 6. Verify recovery, communicate status, and preserve the timeline. For canaries and production observation windows, use [post-deploy-verification.md](references/post-deploy-verification.md). Confirm the deployed build marker, run critical browser journeys through `browser-testing`, and record each promote, hold, or roll...