release-deployment-safetylisted

# Release & Deployment Safety ## Why this exists Most production outages are not caused by bad code — they're caused by *how* good code was shipped: a migration that locked a table, a deploy with no rollback path, a change that assumed old and new versions would never run at the same time. The difference between a hobby project and infrastructure that scales is not the architecture, it's that every change can be released gradually, observed, and undone in seconds. This skill makes safe release the default, so "it works" becomes "it ships without anyone noticing the seam." This skill is about the *delivery* half of CI/CD. The `bdd-comprehensive-testing` skill wires tests into the pipeline (continuous integration); this skill governs what happens after the tests pass (continuous delivery/deployment). Use them together. ## The core principle **Every change must be independently deployable, backward-compatible, observable while rolling out, and reversible within minutes.** If any of those four is missing, the change is not ready to ship — regardless of whether the code is correct. Treat a deploy without a rollback plan the same way you'd treat code without tests. ## The workflow ### Step 1: Classify the change and pick a rollout strategy Identify what kind of change this is — it determines the safe path: - **Stateless app/service code change** → rolling or canary deploy behind a load balancer. - **Risky or user-visible behavior change** → feature flag (dark launch), then