Release Readiness

Never dismiss reviews or approvals or configure automatic stale-review dismissal to clear a release gate. Preserve history; request re-review only when authorized.

Read anti-ai-writing before drafting plans or reports. Coordinate the release using existing project procedures. Keep checks proportional to the product and risk; do not impose web-only checks on libraries or fixed rollout percentages and waiting periods on every service.

1. Identify the release and authorization

Resolve the repository, source revision, artifact/version and digest when available, target environment, changes being released, and intended user exposure. Distinguish deploying code, enabling behavior, publishing a package, and retiring old behavior. Inspect repository instructions, release runbooks, CI evidence, configuration, environment protections, and relevant incidents.

Establish the requested actions and preserve existing authorization. Planning or assessment does not authorize live changes. Before requesting missing execution approval, prepare the concrete candidate, destination, rollout, and recovery plan. Do not treat a general launch request as permission to bypass protections, make unrelated infrastructure changes, or send unseen announcements.

2. Assess readiness against evidence

Identify applicable acceptance criteria, required checks and reviews, compatibility obligations, and operational prerequisites. Verify evidence belongs to the candidate and intended environment. A green build or prior release does not prove the current release is ready. Reassess coverage after material changes.

Check relevant failure modes, security and tenant boundaries, performance/capacity, accessibility for affected user interfaces, configuration, credentials, and critical user flows. Use actual project budgets and requirements. State missing evidence instead of inventing universal thresholds or declaring all checklist items mandatory.

Use ci-cd-workflows for pipeline mechanics, safe-migrations for data or contract transitions, test-authoring for coverage gaps, and code-review for required candidate review. These procedures support readiness; invoking them does not establish completion.

Record the candidate and target, each applicable required gate and its actual result, and any missing or failed evidence. Reuse check results only when they cover the same candidate and the conditions they claim to verify; rerun affected checks after material changes. Apply the project's requirements rather than imposing a clean worktree, a test count, or a generic command list on every release. Record a supported disposition: ready for the identified next stage, blocked by named requirements, or incomplete because evidence is unavailable. Keep readiness separate from permission to execute and from final production success.

3. Prepare rollout and recovery

Define ordered stages with the artifact, target cohort, responsible owner, verification, advance/hold/abort criteria, and recovery action. Follow configured SLO and error-budget policy when present; do not invent one or override an exhausted-budget policy. If missing policy creates a consequential decision, surface it before dependent work.

Choose direct, canary, staged, or flag-controlled exposure according to risk and existing infrastructure. A feature flag is optional machinery, not a substitute for compatible deployment. When used, verify both states, cohort selection, kill switch limitations, owner, and cleanup conditions.

For canaries, compare relevant errors, latency, resource use, and business outcomes with a representative baseline. Check telemetry freshness, sample size, traffic mix, and background or delayed effects. Select observation windows based on usage cycles and available signal. No traffic or missing telemetry cannot demonstrate success.

Prepare actionable recovery steps tied to the deployed artifact and state. Distinguish flag disablement, traffic reversal, code rollback, and data restoration or forward repair. Confirm prerequisites, permissions, expected recovery time when measured, and irreversible boundaries. Rehearse safely when authorized; label untested procedures. Do not claim that reverting a commit or deploying an old binary reverses data changes.

4. Execute only the authorized stages

Immediately before execution, recheck candidate identity, current environment state, required evidence, protections, and authorization. Stop if changes invalidate the plan or require an unresolved decision. Preserve prior approval for unchanged supported actions; obtain approval only for genuinely added scope or materially changed actions.

Use existing deployment mechanisms and promote the verified artifact. Record actual run, version, environment, cohort, and status. Verify deployment success separately from user exposure and application health. Advance only when the stage's evidence supports its criteria; do not auto-expand a canary merely because the job passed.

If criteria fail, hold progression and follow authorized recovery. Without recovery authorization, report the concrete required action and continue safe diagnosis. Use root-cause-debug for investigation. Do not retry ambiguous deployment or publication results until checking whether the action succeeded.

5. Verify outcomes and close the release

Check critical behavior, observability, relevant service metrics, and compatibility after exposure. A health endpoint alone cannot establish that the user flow works. Track known issues and delayed-effect checks with an owner and handoff. If a requested observation period extends beyond this run, use authorized monitoring or an explicit handoff; do not claim the period completed or imply unattended monitoring exists.

Report what was assessed, deployed, enabled, published, or recovered, citing actual evidence and remaining limits. Keep required release notes proportional and accurate. External announcements require approved text and destinations. Git actions and PRs use authorized git-delivery. Cleanup of flags or retired paths follows its own scope and readiness, not an arbitrary post-launch deadline.