production-readiness

Production Readiness

Decide whether the exact candidate can be operated safely. The audit produces a go/no-go recommendation; deployment, migration, and publication follow the user's existing authorization.

Workflow

1. Resolve the candidate: record repository state, revision, artifact or image digest, configuration set, environment, dependency and schema versions, and the proposed rollout window; preserve dirty worktrees and never infer exact-head CI from another revision.
2. Define working: state critical user journeys, availability and correctness expectations, latency or capacity thresholds, data-loss tolerance, compliance constraints, owners, and explicit stop conditions.
3. Inspect the release delta: review code, dependency, configuration, infrastructure, identity, data, and operational changes; identify one-way doors, coupled releases, hidden manual steps, and compatibility windows.
4. Audit security and identity: use threat-model for design risk and code-security for repository evidence.
5. Audit data and migrations: verify forward and backward compatibility, rehearsal evidence, lock and duration risk, backup and restore, rollback semantics, data validation, and ownership of irreversible transitions. data-migration owns implementation and rehearsal; this skill assesses its evidence.
6. Audit capacity and cost: compare measured demand and headroom with explicit thresholds and cost guardrails, without inventing traffic evidence.
7. Audit rollout and recovery: prefer the smallest reversible exposure; define preflight checks, canary or staged progression, health windows, stop signals (including SLO error-budget remaining and burn rate where an SLO exists), the rollback owner and mechanism (see cloud-run for revision rollback), and post-rollback verification.
8. Audit observability and operations: each critical journey and failure mode has an actionable alert, an owner, a tested runbook, and an escalation path.
9. Gate the candidate: run the repository's full gate (mise run all where defined) against the materialized candidate; when the tree carries unrelated changes, apply the dirty-tree rule.
10. Verify proportionally: run only the authorized runtime or staging checks. Failed, stale, unavailable, or differently scoped evidence remains a gap.
11. Place the candidate on the proof ladder: never collapse these states; a candidate may be ready at one rung and blocked at the next, and every claim records artifact identity, environment, command or observation, timestamp, and source.
    • source-ready: the intended source and configuration are reviewable.
    • local-green: the repository-owned local checks pass for the candidate.
    • exact-head-CI: required CI passes for the exact immutable revision.
    • runtime-proven: the built artifact works across the authorized runtime boundary.
    • deployed: that artifact is running in the target environment.
    • release-published: the intended audience can obtain the released result (see release).
12. Record the gates: for each material gate report its status (pass, fail, blocked, or not run), exact evidence, owner, and smallest next step; lead with blockers, then gaps, verified gates, rollback plan, highest proven rung, and recommendation.
13. Decide: return GO, GO WITH CHANGES, or NO-GO; authority, schedule pressure, and sunk cost cannot turn a failed hard gate into GO.