production-readiness

Production Readiness

Decide whether the exact candidate can be operated safely; this skill audits and recommends, it does not deploy, migrate, publish, or mutate production unless the user separately authorizes that action, while cloud-run deploys and release publishes.

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, 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: Check least privilege, authentication and authorization, tenant isolation, secret lifecycle, supply chain, abuse controls, and safe defaults; use threat-model for design risk and secure 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.
6. Audit observability: Map each critical journey and failure mode to logs, metrics, traces, dashboards, and actionable alerts, each with an owner, a justified threshold, and a tested runbook.
7. Audit capacity and cost: Compare measured demand and headroom with explicit thresholds across saturation, rate limits, concurrency, timeouts, retries, quotas, degraded modes, and cost guardrails, without inventing traffic evidence.
8. Audit rollout and recovery: Prefer the smallest reversible exposure; define preflight checks, canary or staged progression, health windows, stop signals, the rollback owner and mechanism (see cloud-run for revision rollback), and post-rollback verification.
9. Audit operations: Confirm service ownership, support and escalation paths, dependency contacts, access, runbooks, maintenance burden, disaster recovery, and the first-hours monitoring plan.
10. Gate the candidate: Run the full gate (mise run all); if the tree carries unrelated changes and the gate write-formats, run it in a temporary git worktree or fall back to mise run check and mise run test (see mise).
11. Verify proportionally: Run only the authorized runtime or staging checks. Failed, stale, unavailable, or differently-scoped evidence remains a gap.
12. 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).
13. 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.
14. Decide: Return GO, GO WITH CHANGES, or NO-GO; authority, schedule pressure, and sunk cost cannot turn a failed hard gate into GO.