mustflow 2.107.3 → 2.108.0

package/templates/default/locales/en/.mustflow/skills/database-migration-change/SKILL.md

@@ -2,11 +2,11 @@
 mustflow_doc: skill.database-migration-change
 locale: en
 canonical: true
-revision: 3
+revision: 4
 lifecycle: mustflow-owned
 authority: procedure
 name: database-migration-change
-description: Apply this skill when database migration files, schema migration history, ORM schema migrations, generated clients, schema dumps, SQL snapshots, online DDL, large indexes, constraints, state-dependent CHECK constraints, backfills, rolling deploy compatibility, expand-and-contract changes, destructive database changes, migration rollback or roll-forward claims, cut-over plans, lock or timeout policy, replication lag risk, migration observability, or production database migration procedures are created, changed, reviewed, or reported.
+description: Apply this skill when database migration files, schema migration history, ORM schema migrations, generated clients, schema dumps, SQL snapshots, online DDL, large indexes, constraints, state-dependent CHECK constraints, background-job backfills, zero-downtime migration claims, rolling deploy compatibility, expand-and-contract changes, destructive database changes, migration rollback or roll-forward claims, cut-over plans, feature-flagged read/write switches, lock or timeout policy, replication lag risk, migration observability, or production database migration procedures are created, changed, reviewed, or reported.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -33,13 +33,14 @@ Keep database migrations safe for running systems by checking deploy compatibili
 
 Do not treat migration authoring as "make a file that applies locally." Treat it as "old code and new code must survive the same database during rollout."
 Migration incidents usually happen in the interval where old code, new code, old data, and new data are all alive at once. Design that interval first.
+Do not collapse schema expansion, data backfill, read or write cut-over, and destructive cleanup into one deploy-time migration just because that worked on a developer database.
 
 <!-- mustflow-section: use-when -->
 ## Use When
 
 - A database migration file, migration history entry, schema dump, ORM schema, SQL snapshot, generated client, seed, fixture, schema validator, or migration documentation is created or changed.
 - A change adds, removes, renames, splits, merges, backfills, rewrites, validates, constrains, indexes, foreign-keys, type-changes, defaults, nullable rules, enum values, tables, columns, generated columns, triggers, views, functions, row-level policies, or data migrations.
-- A task mentions rolling deploy, expand-and-contract, online migration, backfill, production schema change, rollback, roll-forward, down migration, migration lock, lock timeout, statement timeout, DDL transaction, `CREATE INDEX CONCURRENTLY`, MySQL `ALGORITHM=INSTANT`, MySQL `LOCK=NONE`, generated ORM client, migration drift, schema drift, or database migration safety.
+- A task mentions rolling deploy, zero-downtime migration, expand-and-contract, online migration, long-running migration, background job backfill, feature flag migration, dual-write, dual-read, compatibility read fallback, production schema change, rollback, roll-forward, down migration, migration lock, lock timeout, statement timeout, DDL transaction, `CREATE INDEX CONCURRENTLY`, MySQL `ALGORITHM=INSTANT`, MySQL `LOCK=NONE`, generated ORM client, migration drift, schema drift, or database migration safety.
 - Prisma, Drizzle, TypeORM, Rails Active Record, Django migrations, Alembic, Diesel, Ecto, Flyway, Liquibase, Knex, Sequelize, SQLx, or another migration tool changes schema, generated output, migration metadata, or deployment behavior.
 - A final report claims a database migration is safe, reversible, applied, validated, production-ready, no-downtime, rollback-safe, or tested from an old schema.
 
@@ -58,6 +59,8 @@ Migration incidents usually happen in the interval where old code, new code, old
 - Deployment shape: single-step deploy, rolling deploy, blue-green, multiple app versions, background workers, read replicas, multiple services, serverless functions, mobile clients, or external integrations.
 - Database engine and operational surface: PostgreSQL, MySQL, SQLite, SQL Server, managed database, migration lock behavior, DDL transaction behavior, online DDL options, table size, write load, long-running transactions, replication or CDC topology, expected lock time, statement timeout, lock timeout, and restore capability when known.
 - Data preservation needs, compatibility window, backfill size, batch strategy, cursor or checkpoint marker, validation query, observability query, rollback or roll-forward type, cut-over control, and whether old code can run after the new schema lands.
+- Application transition controls: feature flags, tenant gates, read fallback, dual-write window, old-write cutoff, old-read cutoff, worker rollout order, admin/reporting/BI dependency review, and how to disable the new path without restoring the database.
+- Production runbook boundary: execution owner, intended window, expected lock time, expected replication lag, metrics to watch, stop or pause thresholds, retry policy, partial-apply handling, customer-impact communication trigger, and manual approval points when relevant.
 - State and timestamp invariant matrix when a migration introduces lifecycle statuses, terminal
   timestamps, retry or dead-letter states, delivery states, soft-delete states, approval states, or
   other columns whose valid nullability depends on status.
@@ -78,6 +81,7 @@ Migration incidents usually happen in the interval where old code, new code, old
 
 - Update migration files, ORM schema files, generated client expectations, schema dumps, SQL snapshots, seeds, fixtures, compatibility code, backfill code, validation checks, docs, and tests directly required by the migration.
 - Prefer expand-and-contract for live systems: add compatible shape, dual-write or compatibility-read where needed, backfill safely, switch reads and writes, then contract only after compatibility is proven.
+- Move long-running data rewrites out of deploy-time schema migrations into bounded, restartable background jobs when production-sized data or live traffic can be affected.
 - Keep destructive cleanup separate from expansion unless the repository explicitly proves a single-step deployment is safe.
 - Do not weaken tests, delete migration history, hand-edit generated client output, suppress migration drift, or claim rollback safety for lossy changes.
 
@@ -93,19 +97,21 @@ Migration incidents usually happen in the interval where old code, new code, old
    - Django: migration files, state operations, historical models, schema editor behavior, generated SQL when relevant, and data migration functions.
    - Alembic or SQLAlchemy: migration revisions, autogenerate output, branch heads, model metadata, downgrade functions, naming conventions, and generated SQL.
    - Diesel, Ecto, Flyway, Liquibase, Knex, Sequelize, SQLx, and raw SQL: migration history, checked-in SQL, generated metadata, compile-time query checks, rollback files, and schema dumps.
-3. Build a migration ledger: old shape, new shape, rows affected, old code behavior, new code behavior, rollback expectation, generated artifact changes, dependent callers, and validation query.
+3. Build a migration ledger: old shape, new shape, rows affected, old code behavior, new code behavior, worker and batch behavior, admin/reporting/BI behavior, rollback expectation, generated artifact changes, dependent callers, and validation query.
 4. Classify compatibility.
    - Old code on old schema.
    - Old code on expanded schema.
    - New code on expanded schema.
    - New code after backfill.
    - New code after contract.
+   - Old background workers, cron jobs, admin tools, reporting queries, and external integrations during the same window.
    If any required state fails, the migration is not rolling-deploy safe.
 5. Split the deployment plan into expand, backfill, switch, and contract phases.
    - Expansion adds shapes old code can ignore and new code can start writing.
-   - Backfill is bounded, restartable, idempotent, observable, and separately validated.
-   - Switch changes read paths through a feature flag, rollout gate, tenant gate, or compatible deploy step where possible.
+   - Backfill is bounded, restartable, idempotent, observable, separately validated, and separated from the deployment pipeline when it can run long.
+   - Switch changes read and write paths through a feature flag, rollout gate, tenant gate, or compatible deploy step where possible.
    - Contract removes old shapes only after at least one compatibility window proves no code, job, report, or manual SQL still depends on them.
+   - A single migration file that expands, rewrites data, flips reads, and drops old structures is not zero-downtime evidence unless the repository proves the single-step path is safe for its deployment model.
 6. For column add, decide nullability, default behavior, backfill strategy, write path, read fallback, index need, and when a future `NOT NULL` or constraint can be enforced.
    - Add nullable first unless a proven engine/version/table-size path makes the non-null default safe.
    - Do not assume a database default backfills existing rows or matches ORM, API, batch, or application defaults.
@@ -139,6 +145,10 @@ Migration incidents usually happen in the interval where old code, new code, old
     - Partition attach can scan existing rows unless a suitable `CHECK` constraint proves the range first.
     - Table split, table merge, or relationship rewrite must preserve stable identifiers, foreign keys, audit references, external IDs, permissions, search documents, exports, and old-to-new mapping until all callers switch.
 15. For backfills, make them bounded, restartable, observable, and validated. Define batch size, cursor-based ordering key such as `id > last_id`, checkpoint, retry behavior, idempotency, timeout, lock expectation, throttle or pause/resume control, dead-letter or manual review behavior, and validation queries.
+    - Keep long-running data rewrites out of deploy-time migrations unless the affected row count, lock behavior, WAL/binlog or undo impact, replication lag, and timeout behavior prove the operation is short and bounded.
+    - Commit in small batches instead of one huge transaction when live data volume can be large.
+    - Process only rows that still need work, so reruns and retries cannot corrupt already migrated rows.
+    - Track progress with a durable cursor or checkpoint; do not rely on offset pagination for mutable production tables.
 16. Do not run or recommend full-table updates on production-sized data without measured volume, lock expectation, WAL or undo impact, replication lag risk, batch plan, timeout policy, and recovery plan.
 17. Review replication, CDC, and long-running transaction interactions.
     - Online DDL can leave replicas, read traffic, backups, CDC connectors, or failover readiness behind even when the primary looks healthy.
@@ -150,14 +160,17 @@ Migration incidents usually happen in the interval where old code, new code, old
     - Monitor dual-write mismatch and sample old/new values during the compatibility window; code intent is not proof that every path writes both sides.
 19. Prepare observability before apply.
     - Pair the migration with read-only progress and safety queries for lock waits, index build progress, replication lag, backfill cursor, skipped rows, failed rows, duplicate rows, missing rows, dead tuples, or estimated remaining range when the engine supports them.
+    - Watch application error rate, p95 or p99 latency, connection pressure, fallback-read rate, dual-write mismatch rate, and critical business event failures when the migration changes a live request path.
     - Log or report dry-run selection counts, apply counts, skip reasons, batch durations, and recovery handles.
     - A final `done` line is not enough evidence for a live migration.
+    - Prepare a runbook before apply. It should name the operator, execution window, expected duration, expected lock and replication behavior, stop thresholds, pause or abort action, partial-apply behavior, code rollback order, feature-flag fallback, validation queries, and customer-impact communication trigger.
 20. Decide rollback honestly and prefer roll-forward for partial live changes.
     - Reversible: schema-only and data-preserving.
     - App rollback: old and new code both tolerate the expanded shape, so the read path can move back without losing new writes.
     - Forward-fix preferred: partial live migration can be corrected without restoring.
     - Restore required: deletes, table merges, generated IDs, hashing, encryption, irreversible type conversions, external side effects, or lossy transforms.
     Do not promise rollback for changes that cannot reconstruct old values.
+    Treat backups as disaster recovery evidence, not ordinary deploy rollback, unless a restore drill proves that restoring the database would not lose acceptable live writes, external side effects, or dependent service state.
 21. Keep external side effects out of database migrations unless the repository has an explicit recovery model. Sending emails, calling payment APIs, deleting files, or mutating external providers from a migration usually breaks rollback.
 22. Check generated surfaces after schema changes: ORM clients, types, SQL snapshots, schema dumps, OpenAPI or GraphQL projections, API mocks, fixtures, seeds, admin screens, analytics, ETL, BI queries, and docs examples.
 23. Review ORM-specific traps.
@@ -180,11 +193,13 @@ Migration incidents usually happen in the interval where old code, new code, old
 - Source schema, target schema, migration files, generated artifacts, schema dumps, seeds, fixtures, and dependent code agree.
 - Expand, backfill, switch, and contract phases are separated or explicitly proven unnecessary.
 - Old-code/new-schema and new-code/expanded-schema compatibility is classified.
+- Read-path fallback, write-path transition, dual-write mismatch detection, feature-flag control, and old worker/admin/reporting dependency review are explicit when a live rollout can overlap versions.
 - Backfill and validation behavior is cursor-based or otherwise bounded, restartable, idempotent, observable, and checkable where relevant.
 - State-dependent CHECK constraints, terminal timestamp exclusivity, and valid nullability matrices
   are explicit where status columns can otherwise contradict timestamp or reason columns.
 - Lock levels, online DDL support, long-running transaction waits, replication lag, cut-over control, timeout policy, and observability queries are explicit where production data may be affected.
 - Rollback claims distinguish schema rollback, data rollback, app rollback, roll-forward, forward-fix, and restore-required cases.
+- Production runbook stop thresholds, pause or abort behavior, partial-apply handling, and communication triggers are explicit where the migration can affect live service behavior.
 - Destructive changes and production lock risks are either deferred, measured, guarded, or reported as remaining risk.
 
 <!-- mustflow-section: verification -->
@@ -212,6 +227,8 @@ Prefer configured migration dry-run, generated-output, schema-diff, or database
 - If online DDL support, long-running transaction behavior, replication lag, or cut-over control is unknown, report the migration as operationally unproven.
 - If an autogenerator proposes drop/create for a rename, stop and rewrite the migration plan.
 - If a migration is lossy, do not claim rollback beyond restore or forward corrective migration.
+- If rollback depends only on a backup restore, label it disaster recovery instead of deploy rollback and report live-write loss or external-state reconciliation risk.
+- If the migration plan lacks feature-flag fallback, read/write cut-over order, stop thresholds, or partial-apply handling for a live rollout, do not call it zero-downtime.
 - If a backfill is not idempotent, restartable, observable, and throttled or bounded, keep it out of a production migration claim.
 - If generated clients or schema dumps drift, fix the source of truth and regenerated surfaces together.
 - If configured verification is missing, report the missing command intent instead of inferring package-manager, ORM, or migration-tool commands.
@@ -224,7 +241,8 @@ Prefer configured migration dry-run, generated-output, schema-diff, or database
 - Source schema, target schema, and migration phase
 - Old-code/new-schema and new-code/expanded-schema compatibility
 - Expand/backfill/switch/contract plan and destructive cleanup timing
-- Backfill cursor, idempotency, throttle, pause/resume, validation, lock, timeout, replication, cut-over, and observability classification
+- Read/write transition, feature-flag fallback, dual-write or compatibility-read window, old worker/admin/reporting dependency review
+- Backfill cursor, idempotency, throttle, pause/resume, validation, lock, timeout, replication, cut-over, runbook stop threshold, and observability classification
 - Status, timestamp, CHECK constraint, and existing-row validation matrix where relevant
 - Rollback, app rollback, roll-forward, forward-fix, and restore-required classification
 - ORM/generated client/schema dump/snapshot surfaces synchronized

package/templates/default/locales/en/.mustflow/skills/deployment-rollout-safety-review/SKILL.md

@@ -2,11 +2,11 @@
 mustflow_doc: skill.deployment-rollout-safety-review
 locale: en
 canonical: true
-revision: 2
+revision: 3
 lifecycle: mustflow-owned
 authority: procedure
 name: deployment-rollout-safety-review
-description: Apply this skill when server, backend, worker, scheduler, queue consumer, cron, container, VM, serverless, migration, config, feature-flag, cache, deployment pipeline, canary, rollback, release envelope, image digest, deployment history, traffic rollback, health check, readiness/liveness/startup probe, graceful shutdown, artifact promotion, release observability, or post-deploy smoke behavior is created, changed, reviewed, or reported and the risk is whether a deployment can be rolled out, stopped, observed, or rolled back safely.
+description: Apply this skill when CI/CD pipeline gates, required checks, preview deploys, migration checks, server, backend, worker, scheduler, queue consumer, cron, container, VM, serverless, IaC, config, secret handling, feature-flag, cache, canary, rollback, release envelope, image digest, deployment history, traffic rollback, health check, readiness/liveness/startup probe, graceful shutdown, artifact promotion, release observability, or post-deploy smoke behavior is created, changed, reviewed, or reported and the risk is whether a deployment can be rolled out, stopped, observed, or rolled back safely.
 metadata:
   mustflow_schema: "1"
   mustflow_kind: procedure
@@ -29,13 +29,15 @@ metadata:
 <!-- mustflow-section: purpose -->
 ## Purpose
 
-Review a server deployment as a runtime state transition, not as "the build passed".
+Review a server deployment as a runtime state transition, not as "the build passed" or
+"CI is green".
 
 Deployment failures usually come from changed ordering, config, data, cache, queues, rollback shape,
-permissions, and observability. Rollback is not just restarting an older container. It is the older
-release surviving today's data, config, cache, queue messages, external side effects, and traffic
-state. This skill makes the agent prove that a wrong deploy has small blast radius, is detected
-quickly, can be stopped quickly, and can be rolled back without inventing a recovery plan during the
+permissions, secrets, infrastructure policy, human approvals, and observability. Rollback is not
+just restarting an older container. It is the older release surviving today's data, config, cache,
+queue messages, external side effects, secret versions, and traffic state. This skill makes the
+agent prove that a wrong deploy has small blast radius, is detected quickly, can be stopped quickly,
+and can be rolled back or safely rolled forward without inventing a recovery plan during the
 incident.
 
 <!-- mustflow-section: use-when -->
@@ -43,10 +45,12 @@ incident.
 
 - A change touches server deployment, backend runtime behavior, workers, schedulers, cron, queue
   consumers, containers, VMs, serverless functions, Kubernetes manifests, process managers,
-  deployment pipelines, release gates, canaries, release envelopes, or rollback procedures.
+  CI/CD workflows, preview environments, deployment pipelines, release gates, canaries, release
+  envelopes, or rollback procedures.
 - A change touches DB migration order, config or env vars, feature flags, cache keys, queue or topic
   message formats, external API dependencies, storage paths, startup probes, readiness probes,
-  liveness probes, graceful shutdown, worker drain, deployment locks, or post-deploy smoke checks.
+  liveness probes, graceful shutdown, worker drain, deployment locks, secret scope, IaC policy, or
+  post-deploy smoke checks.
 - A review needs to decide whether code, config, database, cache, queue, and scheduler changes can
   coexist across old and new versions while traffic is still moving.
 
@@ -77,11 +81,26 @@ incident.
 - Deployment model: environment order, artifact promotion path, rolling/blue-green/canary strategy,
   traffic rollback path, old-version retention, deployment history retention, deployment
   concurrency, and deployment lock owner.
+- Pipeline gate model: required status checks, branch protection or merge gate, reviewer or
+  CODEOWNER gate, fast-fail ordering, clean CI environment, test data setup, flaky-test quarantine
+  owner, artifact retention, and security scan coverage.
+- Preview model: preview URL, isolated namespace or schema, ephemeral database or seeded data,
+  teardown policy, cost guardrail, deployment protection, and proof that production secrets and
+  production PII are not exposed.
+- Migration check model: dry-run or shadow database evidence, destructive-change detection,
+  lock or table-rewrite risk, online DDL assumptions, backfill separation, N-1 app compatibility,
+  and rollback or roll-forward boundary.
+- Secret and approval model: environment-scoped secrets, production approval gate, OIDC or
+  short-lived credential path, log masking, rotation or revocation path, external secret store or
+  encryption-at-rest boundary, and least-privilege deploy job permissions.
 - Compatibility model: old code with old data, old code with new data, new code with old data, new
   code with new data, N-1 message compatibility, cache key version, and rollback survivability.
 - Runtime control model: startup/liveness/readiness probes, graceful shutdown behavior, load
   balancer connection draining, worker drain, cron duplicate guard, kill switch, safe flag defaults,
   automatic stop conditions, synthetic transactions, and post-deploy observation window.
+- Infrastructure and observability model: rendered manifests or plan output, policy checks, image
+  digest pinning, resource requests and limits, probe presence, privileged or hostPath use,
+  plaintext-secret checks, release-labeled logs, metrics, traces, alerts, and dashboard slices.
 
 <!-- mustflow-section: preconditions -->
 ## Preconditions
@@ -99,6 +118,9 @@ incident.
 - Add or update deploy runbooks, release checklists, pipeline metadata, smoke tests, probe tests,
   config validation, feature-flag defaults, rollback notes, canary gates, and deployment safety
   tests when they match the repository style.
+- Add or update preview-deploy guardrails, migration preflight notes, manifest or IaC validation
+  fixtures, secret-scope checks, required-check documentation, and release evidence templates when
+  they are already within the task scope.
 - Add local code guards for startup config validation, readiness separation, shutdown handling,
   worker drain, cache-key versioning, and deployment attribution when the task scope includes the
   affected runtime code.
@@ -115,131 +137,171 @@ incident.
    external APIs, permissions, config, and feature flags. If the ledger is unknown, report that the
    deployment blast radius is unknown instead of guessing.
 
-2. Build the release envelope.
+2. Check the merge and CI gate before the deploy gate.
+   Required status checks, protected branches, review or CODEOWNER gates, and stale-review handling
+   should stop unreviewed or partially verified production changes. Order checks so cheap failures
+   happen before slow checks: format, lint, typecheck, unit tests, build, security scans,
+   integration or contract tests, then focused end-to-end smoke. Require a clean reproducible CI
+   environment, explicit test database setup, seeded data, dependency and container scan coverage,
+   IaC or configuration scans when those files changed, secret scanning, and a named owner or SLA for
+   flaky-test quarantine. A flaky test silently bypassed by the merge gate is a deployment-safety
+   risk, not a testing nuisance.
+
+3. Build the release envelope.
    Rollback needs more than an image tag. Bind image digest, chart or manifest revision, values
    file hash, ConfigMap name or version, Secret version, migration range, feature flag snapshot,
    ingress or router weight, deployer, and deployment time under one `release_id` when the platform
    exposes those facts. If only a mutable tag such as `latest` identifies production, report that
    rollback identity is not reproducible.
 
-3. Separate artifact promotion from environment rebuilds.
+4. Make preview deployment a rehearsal, not just a link.
+   Preview deploys should use an isolated namespace, schema, or ephemeral database with explicit
+   seed data and teardown. Do not allow production secrets, production OAuth callbacks, production
+   webhooks, or production PII in preview. Name deployment protection, access control, teardown
+   failure alerts, and cost cleanup. Run or identify the preview checks that matter for the changed
+   flow: smoke, selected E2E, API compatibility, accessibility, visual regression, and thin DAST or
+   security probes where the repository owns them.
+
+5. Separate artifact promotion from environment rebuilds.
    Verify whether staging and production receive the same artifact identity. Prefer promoting one
-   built artifact over rebuilding per environment. If per-environment rebuild is unavoidable, name
-   the drift risk and require commit SHA, dependency lock, image digest, and build input evidence.
-   Treat image tags as human labels and image digests as the rollback proof.
+   built immutable artifact over rebuilding per environment. If per-environment rebuild is
+   unavoidable, name the drift risk and require commit SHA, dependency lock, build run, SBOM or
+   package inventory when available, image digest, and build input evidence. Treat image tags as
+   human labels and image digests as the rollback proof.
 
-4. Preserve rollback history and warm capacity.
+6. Preserve rollback history and warm capacity.
    For platform-managed rollbacks, check whether old revisions, ReplicaSets, Helm release history,
    blue/green environments, or rollout controller history are retained long enough to be useful.
    Do not treat a rollback path as safe if the old version is immediately scaled to zero, cold, or
    deleted. Prefer traffic rollback to an already-warm old version before rebuilding or pulling a
    replacement during an incident.
 
-5. Split deploy order from migration order.
+7. Split deploy order from migration order.
    For DB changes, check expand/migrate/read-write/switch/contract sequencing. New code must tolerate
    old data, old code must tolerate expanded schema or new data, and contraction must wait until old
    code is impossible. Check migration lock timeout, batch size, retryability, partial progress
    markers, rollback preview evidence, point-in-time recovery practice, database config backup, and
-   rollback limits. Treat destructive rollback SQL as a data-loss risk, not a recovery guarantee.
+   rollback limits. Require dry-run or shadow database evidence when the repository has a migration
+   surface. Treat destructive rollback SQL as a data-loss risk, not a recovery guarantee.
 
-6. Treat config changes as code changes.
+8. Treat config and IaC changes as code changes.
    Diff config and environment variables. Require startup validation for missing, misspelled, empty,
    malformed, or incompatible values. A service should fail fast before accepting traffic when a
    required setting is unsafe. Prefer versioned or immutable config names over in-place config
    mutation, and name whether env-var, mounted-file, or subpath-style config updates require pod or
-   process restart.
-
-7. Separate startup, liveness, and readiness.
+   process restart. For infrastructure files, review rendered manifests or plans rather than only
+   source snippets. Check resource requests and limits, probes, privileged mode, hostPath mounts,
+   plaintext secrets, IAM or service account scope, image digest pinning, and policy validation
+   coverage.
+
+9. Keep secrets out of the wrong stage.
+   Test, preview, staging, and production jobs should use environment-scoped secrets with the
+   smallest permission set that can complete that job. Prefer OIDC or short-lived credentials over
+   long-lived cloud keys in CI. Production secrets should require the production environment gate,
+   and preview jobs should not be able to read them. Check secret masking, rotation or revocation
+   notes, external secret store or encryption-at-rest boundary, and whether platform-native secrets
+   also need RBAC, namespace, and audit controls.
+
+10. Separate startup, liveness, and readiness.
    Startup should protect slow boots, liveness should detect stuck processes, and readiness should
    gate whether the instance can serve real dependencies. Do not count "process is running" as
    deployment readiness. Keep liveness conservative enough that overload or long GC pauses do not
    turn a recoverable incident into a restart loop.
 
-8. Check graceful shutdown before rolling traffic.
+11. Check graceful shutdown before rolling traffic.
    Verify SIGTERM or platform shutdown handling for in-flight requests, DB transactions, uploads,
    payment or webhook callbacks, and streaming responses. The app shutdown timeout must be shorter
    than load balancer connection draining.
 
-9. Drain workers deliberately.
+12. Drain workers deliberately.
    Queue workers need a stop-accepting-new-work phase, a current-work completion or checkpoint phase,
    and an idempotent retry path for interrupted work. Ack, delete, offset commit, and visibility
    timeout behavior must match the shutdown path. Rollback should name consumer pause, in-flight
    work completion, idempotency-key checks, and dead-letter or quarantine inspection for worker and
    scheduler surfaces.
 
-10. Prove message compatibility.
+13. Prove message compatibility.
    Producers and consumers are rarely deployed at the exact same instant. Message format changes need
    N-1 message compatibility, tolerant readers, versioned fields, defaults for missing data, and a
    plan for queued old messages. Unknown event types should not crash old consumers; require
    quarantine, dead-letter, or ignore policy that preserves investigation evidence.
 
-11. Design external side effects as compensation.
+14. Design external side effects as compensation.
     Emails, payment authorizations, third-party webhooks, provider state, and object-storage writes
     do not disappear when code rolls back. Require outbox, idempotency key, state machine,
     reconciliation, or compensation notes for side effects that cannot be undone by reverting code.
 
-12. Keep API compatibility wider than the deploy window.
+15. Keep API compatibility wider than the deploy window.
     Server versions and clients do not change at the same instant. Check N-1 and N+1 compatibility
     for request fields, response fields, enum values, error codes, API versions, and mobile or SDK
     clients. Removing fields, narrowing enums, or adding required inputs can make rollback fail even
     when the old container starts.
 
-13. Add a kill switch, not just a flag.
+16. Add a kill switch, not just a flag.
    Feature flags that only select a new path are not enough. Require a fast disable path, a safe
-   default when flag lookup fails, and an owner who can flip it during the observation window.
-
-14. Define the canary cohort.
+   default when flag lookup fails, an owner who can flip it during the observation window, rollout
+   percentages or cohorts, and an expiry or removal plan so release flags do not become permanent
+   hidden branches.
+
+17. Run production preflight before touching traffic.
+    Preflight should name the active incident status, deployment window, error budget or SLO burn,
+    DB replication lag, queue depth, cache health, dependency health, cloud quota, feature flag
+    defaults, rollback target digest, migration compatibility, alert mute state, and on-call owner.
+    If the system is already degraded, default to blocking or narrowing the deploy rather than adding
+    another variable to an incident.
+
+18. Define the canary cohort.
     Percent-only canaries can hide the exact risky traffic. Name which users, tenants, regions,
     routes, worker partitions, queues, payment methods, or dependency paths receive the new version.
     Prefer a cohort that exercises the changed behavior without making the blast radius vague.
 
-15. Measure canaries by version and by user harm.
+19. Measure canaries by version and by user harm.
     A small canary can disappear in global averages. Require metrics split by service version,
     release id, route, cohort, or worker partition where safe. Prefer user-impact signals such as
     5xx, p95 or p99 latency, login failure, payment failure, order failure, queue backlog, or retry
     explosion over CPU-only rollback triggers.
 
-16. Make automatic stop conditions numeric.
+20. Make automatic stop conditions numeric.
     Before rollout, define stop or rollback thresholds for error rate, p95 or p99 latency, login or
     payment failure, queue backlog, retry rate, dependency timeout, and saturation. "Watch it" is not
     a stop condition.
 
-17. Verify read and write paths separately.
+21. Verify read and write paths separately.
     A read-only health check can pass while writes are broken. Add or identify smoke checks and
     synthetic transactions that cover the changed read path, changed write path, and visible business
     result without corrupting production data.
 
-18. Preserve release attribution in logs and telemetry.
+22. Preserve release attribution in logs and telemetry.
     Deployment logs and runtime logs should expose commit SHA, image tag or digest, config version,
     chart or manifest revision, config version, migration version, feature flag state, deployment
     environment, deployment id, service version, and instance. Log format changes must not silently
     break alerts, dashboards, or search queries.
 
-19. Version cache keys and narrow invalidation.
+23. Version cache keys and narrow invalidation.
     Cache changes need cache key versioning or compatibility. Avoid blanket flushes unless the cold
     DB load has been budgeted. Prefer narrow, gradual invalidation with fallback behavior named.
     Old code must not deserialize new cache payloads without a compatibility plan.
 
-20. Guard scheduler duplication.
+24. Guard scheduler duplication.
     Cron and scheduled jobs can overlap during rolling deploys. Check singleton locks, leader
     election, idempotency keys, deployment locks, and duplicate execution behavior for old and new
     versions.
 
-21. Treat CRDs and operators as schema rollouts.
+25. Treat CRDs and operators as schema rollouts.
     Custom resources, operators, storage versions, conversion strategies, and controller downgrade
     behavior can block rollback even when application pods are healthy. When those surfaces change,
     require stored-object migration, old-client compatibility, and operator downgrade notes.
 
-22. Use deployment locks per service and environment.
+26. Use deployment locks per service and environment.
     Two deploys, migrations, or production commands against the same service/environment need an
     explicit conflict rule. Name the lock scope and the operator-visible owner.
 
-23. Make production commands boring.
+27. Make production commands boring.
     Any production command touched by the change should have dry-run output, bounded target scope,
     explicit confirmation or ticket reference, and refusal behavior for ambiguous environment,
     tenant, region, or time range.
 
-24. Reserve post-deploy observation time.
+28. Reserve post-deploy observation time.
     Deployment is not done when traffic flips. Require a post-deploy observation window with owners
     available, synthetic transaction results, dashboards, logs, queue backlog, dependency health, and
     stop-condition status checked.
@@ -257,13 +319,22 @@ incident.
 ## Review Checklist
 
 - Deployment resource ledger is complete enough to name the blast radius.
+- Merge and CI gates include required checks, branch protection or equivalent merge policy,
+  fast-fail ordering, clean test data, flaky-test ownership, and security scan coverage.
 - Release envelope binds image digest, config, Secret, migration, flag, traffic, deployer, and time
   under a stable release identity where those platform concepts exist.
+- Preview deploys are isolated, seeded, protected, cleaned up, and kept away from production secrets
+  and production PII.
 - Same artifact is promoted across environments or rebuild drift is explicitly controlled.
 - Rollback history is retained, the old version can stay warm when needed, and traffic rollback is
   separated from rebuilding or repulling code.
-- DB migration, code deploy, data backfill, cache, queue, and rollback order are separated.
-- Required config is validated at startup and deployment config diff is inspectable.
+- DB migration, migration dry-run or shadow evidence, code deploy, data backfill, cache, queue, and
+  rollback order are separated.
+- Required config is validated at startup, deployment config diff is inspectable, and rendered
+  manifests or IaC plans are policy-checked for resources, probes, privileges, secrets, and digest
+  pinning.
+- Secrets are environment-scoped, production-gated, least-privilege, short-lived where possible,
+  masked in logs, and rotatable.
 - Startup, liveness, and readiness probes answer different questions.
 - Graceful shutdown, load balancer connection draining, worker drain, and interrupted work retry are
   compatible.
@@ -272,6 +343,8 @@ incident.
 - External side effects have idempotency, reconciliation, or compensation instead of rollback
   overclaim.
 - Feature flag lookup failure chooses the safe default and a kill switch can stop the change.
+- Production preflight checks active incidents, error budget, queue depth, DB lag, dependency
+  health, quota, rollback target, feature defaults, alert mute state, and owner availability.
 - Canary cohort, version-split telemetry, and automatic stop condition are concrete, numeric, and
   tied to the changed flow.
 - Read smoke, write smoke, synthetic transaction, deployment logs, and post-deploy metrics are
@@ -315,7 +388,8 @@ When reporting a review or change, include:
 - Skills used.
 - Deployment resources touched.
 - Rollout and rollback risks found or guarded.
-- Config, migration, cache, queue, probe, shutdown, canary, and observation decisions.
+- CI, preview, artifact promotion, config, secret, migration, IaC, cache, queue, probe, shutdown,
+  canary, rollback, and observation decisions.
 - Verification commands run and their result.
 - Remaining manual deployment checks, especially production-only smoke, canary, and observation
   steps that cannot be executed locally.