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.

Proof Ladder

Never collapse these states:

1. source-ready: The intended source and configuration are reviewable.
2. local-green: The repository-owned local checks pass for the candidate.
3. exact-head-CI: Required CI passes for the exact immutable revision.
4. runtime-proven: The built artifact works across the authorized runtime boundary.
5. deployed: That artifact is running in the target environment.
6. release-published: The intended audience can obtain or use the released result.

A candidate may be ready at one level and blocked at the next. Record artifact identity, environment, command or observation, timestamp, and source for every proof claim.

Workflow

1. Resolve the candidate: Record repository state, revision, build artifact or image digest, configuration set, environment, dependency and schema versions, and the proposed rollout window. Preserve dirty worktrees and do not infer exact-head CI from a different revision.
2. Define working: State the 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 security-scan 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 structured logs, metrics, traces, dashboards, actionable alerts, and a tested runbook. Every alert needs an owner and a justified threshold.
7. Audit capacity and cost: Compare measured demand and headroom with explicit thresholds. Cover 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, automatic and human stop signals, rollback owner, rollback command or mechanism, 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. Protect unrelated work: Before any full gate, inspect the full gate's task definition and working-tree state. If it runs whole-tree write-formatters and unrelated or user changes are present, validate the exact candidate in an isolated temporary worktree or run equivalent non-mutating checks; never reformat unrelated work.
11. Verify proportionally: Run the repository-owned local gate, normally mise run all, and only the authorized runtime or staging checks. Failed, stale, unavailable, or differently-scoped evidence remains a gap.
12. Make the gate decision: Return GO, CONDITIONAL GO, or NO-GO. Authority pressure, schedule pressure, and sunk cost cannot turn a failed hard gate into GO.