Ship It Safely

Plans and lints production schema changes as expand/contract phases with the exact lock each PostgreSQL or MySQL 8 statement takes, lock_timeout guards, throttled batched backfills, dual-write and read cutover, and a verification plus reversal per phase, written to the Release Dossier. Includes a zero-dependency Postgres DDL linter. Use when someone asks "is this migration safe to run in prod", "add a NOT NULL column to a big table", "rename or retype this column without downtime", "backfill millions of rows", or when release-risk-classifier scores the data shape criterion R1 or higher. Do NOT use for greenfield schema design with no production rows - use database-schema instead; for a quick single-statement lock check outside a release, use migration-safety-checker; for deciding whether to revert after a failure, use rollback-or-roll-forward.

Designs a canary and percentage rollout with numeric abort gates expressed relative to a concurrent baseline (error rate, p95/p99 latency, saturation, one business KPI), minimum sample sizes, bake times per step, which gates abort automatically versus page a human, a kill switch that works when the flag service is down, and the flag removal plan, then writes the Rollout plan section of the Release Dossier. Works with LaunchDarkly, Unleash, OpenFeature providers, or homegrown flags, and with any CI or deploy tool. Use when someone asks "how should we roll this out", "what percentage do we start at", "when do we abort the canary", "set up a kill switch", "what metrics gate the rollout", or when release-risk-classifier requires progressive rollout. Do NOT use for analysing an experiment's statistical result - use ab-test-analyzer instead; for flag taxonomy and lifecycle policy, use feature-flags; for the schema side of a release, use zero-downtime-db-migrations.

Runs a release readiness review that ends in a signed, timestamped go/no-go record in the Release Dossier - checks the evidence each risk tier requires, applies explicit no-go triggers, runs a structured pre-mortem that maps every predicted failure to a detection signal and a mitigation, names who decides, and sets an expiry on the decision. Use when someone asks "are we ready to ship", "run the go/no-go", "release readiness review", "can we deploy this today", "pre-mortem this launch", or before the first production step of any R1-R3 release. Do NOT use for classifying the release - use release-risk-classifier instead; for a marketing launch day plan, use launch-day-runbook; for deciding to revert during a live problem, use rollback-or-roll-forward.

Decides whether to roll back or roll forward a bad release using a fixed procedure (data compatibility between versions, current migration phase, measured time to revert versus time to fix, customer impact rate), gives the exact order of operations for flag kill, traffic drain, app rollback, and migration reversal, and lists what can never be reversed and how to compensate instead. Writes the Rollback plan section of the Release Dossier before the release and the executed decision into the incident log during one. Use when someone asks "should we roll back", "revert or hotfix", "can we roll back after the migration ran", "what's our rollback plan", "the deploy is broken, what do we do first", or when progressive-rollout gates abort. Do NOT use for running the incident itself - use incident-command instead; for designing migration phases, use zero-downtime-db-migrations.

Runs a production incident from declaration to blameless postmortem - SEV1-SEV4 levels with measurable criteria, the four roles (incident commander, comms, ops, scribe) and what each must and must not do, an update cadence per SEV with internal and customer templates, a timestamped decision log appended to the Release Dossier, a structured IC handoff, and a postmortem section with timeline, contributing factors, 5-whys per factor, and owned, dated action items. Use when someone says "we have an incident", "declare a SEV", "who is IC", "write the status update", "hand off the incident", "start the postmortem", or when a progressive-rollout gate aborts and impact continues. Do NOT use for the revert-or-fix decision itself - use rollback-or-roll-forward instead; for authoring standing service runbooks, use runbook-writer; for a routine on-call shift handoff with no active incident, use oncall-handoff; for a quick severity call on a single alert, use sev-triage; for a standalone postmortem with no Release Dossier, use postmortem-writer.