Zero-Downtime Laravel Migration Review

Public field comparison

Zero-Downtime Laravel Migration Review

Zero-Downtime Laravel Migration Review

Review Laravel migrations for deployment safety, database locks, rollback risk, data backfills, schema compatibility, and production rollout hazards.

Use Codex to produce an evidence-based safety review of proposed Laravel schema and data migrations, including engine-specific lock analysis, rolling-release compatibility, backfill controls, recovery planning, and measurable deployment acceptance criteria.

Use this to have Codex review Laravel migrations before production deployment and identify lock risks, rollback hazards, backfill needs, and safer rollout phases.

Use this prompt when a Laravel team needs Codex to review schema or data migrations against the exact database engine, production workload evidence, rolling-release compatibility, backfill controls, recovery readiness, and measurable human-approved release gates.

Zero-downtime Laravel migration review
Production database migration safety check
Laravel schema change risk assessment
High-traffic table migration planning
Safe index and column rollout review
Expand-backfill-contract migration planning
Rollback and recovery planning for Laravel releases
Database lock and downtime risk detection
Backfill strategy review before deployment
Laravel migration verification checklist

Evidence-based Laravel migration review before an authorized release
Lock and table-rewrite risk assessment for MySQL, MariaDB, or PostgreSQL migrations
Expand-backfill-contract planning for high-write Laravel tables
Rolling-deployment compatibility review across Laravel application and queue-worker versions
Index, foreign-key, unique-constraint, and non-null transition review
Idempotent backfill design with measurable reconciliation and pause criteria
Rollback and forward-recovery planning for Laravel schema releases
Production-like migration rehearsal and acceptance-check design

Repository context
Laravel version
Migration files
Related models
Related queries
Related jobs or queues
Related controllers or services
Database engine
Database version
Table sizes
Write volume
Read volume
Existing indexes
Deployment process
CI/CD process
Rollback requirements
Backfill needs
Application compatibility window
Maintenance constraints
Allowed downtime
Production traffic pattern
Backup process
Verification commands
Definition of done

Repository and change set
Framework and database versions
Production schema evidence
Workload and table evidence
Deployment topology and compatibility window
Backfill and recovery constraints
Operational limits and approvals
Acceptance evidence

Paste this prompt into Codex while working inside the Laravel repository. Add the migration file paths, database engine, table sizes, deployment process, rollback expectations, and any maintenance constraints. Use the output before running production migrations, especially when changing high-traffic tables, adding indexes, backfilling data, or removing columns.

Open Codex in the Laravel repository, then replace every bracketed variable with the exact release and migration details requested.

Provide the migration diff, related Laravel code, current production schema metadata, exact Laravel and database versions, aggregate table and workload measurements, deployment and queue-worker topology, backfill constraints, recovery procedures, and any existing test or rehearsal evidence.

Redact credentials, personal data, customer records, payment information, connection strings, and confidential production rows. State clearly whether Codex may perform read-only inspection, run non-mutating local diagnostics, or edit repository files.

Run the prompt, then have the database owner and release owner review the evidence ledger, blockers, phased migration design, backfill controls, verification runbook, recovery matrix, and approval gates before any staging or production action.

A Laravel app needs to add non-null columns and indexes to a high-traffic orders table. The team uses this prompt in Codex to review the migration, split the rollout into expand, backfill, and contract phases, check rollback risk, and prepare verification commands before production deployment.

A Laravel release proposes adding required fulfillment fields and a unique index to a heavily written orders table. The team supplies Codex with the migration diff, related model and queue-worker code, exact database version, production index metadata, row and duplicate counts, deployment topology, and recovery constraints. Codex is asked to determine whether an expand-backfill-validate-contract sequence is required and to produce evidence-based acceptance checks. The resulting report remains a proposal until authorized engineers run and record the checks.

Expert

Expert

Codex

Codex

database

database

laravel-migrations
zero-downtime
database-safety
codex
deployment-risk
rollback-plan
schema-changes
backfill-strategy
production-safety
database-locks
expand-contract
laravel
mysql
mariadb
postgresql
verification
release-safety

laravel
laravel-migrations
zero-downtime
database-safety
schema-changes
expand-contract
backfill-strategy
deployment-risk
rollback-plan
codex

Codex Zero-Downtime Laravel Migration Prompt

Zero-Downtime Laravel Migration Review with Codex

Use this Codex prompt to review Laravel migrations for database locks, rollback hazards, backfill needs, schema compatibility, and production deployment safety.

Review Laravel migrations in Codex for lock, compatibility, backfill, recovery, and zero-downtime release risks using concrete evidence.

Prompt-body line comparison

Removed Added Unchanged context

−You are a senior Laravel engineer, database reliability reviewer, and production deployment safety analyst.
−
−You review Laravel migrations before production deployment, with special attention to database locks, rollback hazards, data backfills, schema compatibility, and zero-downtime rollout planning.
−
−You focus especially on high-traffic Laravel applications where downtime, long-running table operations, failed rollbacks, or unsafe data changes can create serious production incidents.
−
−## Objective
−
−Review the proposed Laravel migrations and related application code for zero-downtime deployment risk.
−
−Produce a practical migration safety review that identifies hazards, recommends safer rollout phases, explains rollback and recovery options, and provides verification commands before any production migration is executed.
−
−## Context Placeholders
−
−Use the context below. If a placeholder is missing, name the missing item and make a conservative assumption before continuing.
−
−- [Repository context]
−- [Laravel version]
−- [Migration files]
−- [Related models]
−- [Related queries]
−- [Related jobs or queues]
−- [Related controllers or services]
−- [Database engine]
−- [Database version]
−- [Table sizes]
−- [Write volume]
−- [Read volume]
−- [Existing indexes]
−- [Deployment process]
−- [CI/CD process]
−- [Rollback requirements]
−- [Backfill needs]
−- [Application compatibility window]
−- [Maintenance constraints]
−- [Allowed downtime]
−- [Production traffic pattern]
−- [Backup process]
−- [Verification commands]
−- [Definition of done]
−
−## Important Rules
−
−1. Inspect the actual migration files before giving recommendations.
−
−2. Inspect related models, queries, jobs, observers, factories, seeders, validation rules, and application code where relevant.
−
−3. Do not assume the migration is safe because it works locally.
−
−4. Do not recommend running production migrations until lock risk, rollback risk, and compatibility risk have been reviewed.
−
−5. Do not drop columns, rename columns, change column types, transform data, or remove indexes without identifying a recovery path.
−
−6. Do not assume rollback is safe just because a `down` method exists.
−
−7. Do not assume `php artisan migrate:rollback` is safe for production recovery.
−
−8. Do not invent table sizes, traffic levels, database engine behavior, indexes, constraints, or deployment details.
−
−9. Separate confirmed findings from assumptions.
−
−10. If the database engine is unknown, assume a conservative production database and ask the user to confirm whether it is MySQL, MariaDB, PostgreSQL, SQLite, or another engine.
−
−11. If table size is unknown, treat large-table operations as risky until proven otherwise.
−
−12. If the migration touches customer data, payment data, user identity, authorization, subscriptions, orders, logs, or analytics events, flag it as high-impact.
−
−13. If the migration affects public-facing behavior, queues, scheduled jobs, billing, permissions, or authentication, include a human review gate.
−
−14. Prefer expand-backfill-contract rollout phases for risky changes.
−
−15. Recommend minimal code edits only when they reduce migration risk or improve deployment compatibility.
−
−16. Keep the output practical enough for a Laravel developer to act on before deployment.
−
−## Review Process
−
−Follow this process before writing the final answer.
−
−1. Read the migration files.
−
−2. Identify every schema operation in each migration.
−
−3. Identify affected tables, columns, indexes, foreign keys, constraints, and data changes.
−
−4. Inspect related Laravel code that reads from or writes to the affected schema.
−
−5. Identify application compatibility risks during rolling deploys.
−
−6. Identify destructive operations.
−
−7. Identify long-running operations.
−
−8. Identify table-locking or index-build risks.
−
−9. Identify nullable and non-nullable transition risks.
−
−10. Identify default value risks.
−
−11. Identify foreign key risks.
−
−12. Identify unique index risks.
−
−13. Identify backfill needs.
−
−14. Identify rollback hazards.
−
−15. Identify recovery requirements.
−
−16. Recommend a safer rollout plan.
−
−17. Provide verification commands and manual checks.
−
−## Common Migration Risks to Check
−
−Review for these specific hazards:
−
−1. Adding a non-null column without a safe default.
−
−2. Adding a column with an expensive default on a large table.
−
−3. Changing a column type in place.
−
−4. Renaming a column that live code still reads.
−
−5. Dropping a column before all code paths stop using it.
−
−6. Dropping or changing an index used by production queries.
−
−7. Adding a unique index before duplicate data is cleaned.
−
−8. Adding a foreign key to a large existing table without checking bad rows.
−
−9. Running data backfills inside the migration transaction.
−
−10. Running large updates in one query without batching.
−
−11. Running slow migrations during normal traffic.
−
−12. Using Laravel schema methods that behave differently across database engines.
−
−13. Depending on `doctrine/dbal` behavior for column changes without confirming compatibility.
−
−14. Creating indexes in a way that blocks writes.
−
−15. Combining schema changes and data transformations in one migration.
−
−16. Combining expand and contract steps in one release.
−
−17. Relying on rollback for irreversible data transformations.
−
−18. Breaking old code during a rolling deployment.
−
−19. Breaking queued jobs that still expect the old schema.
−
−20. Breaking scheduled tasks, reports, exports, or API consumers.
−
−## Safer Rollout Patterns
−
−Use these patterns where appropriate.
−
−### Expand Phase
−
−Add new nullable columns, new tables, new indexes, or compatibility code without removing old schema.
−
−### Dual-Write Phase
−
−If needed, update application code to write to both old and new fields while reads remain compatible.
−
−### Backfill Phase
−
−Backfill existing records in safe batches using a command, job, queue, or controlled script rather than one dangerous migration.
−
−### Read-Switch Phase
−
−Switch reads from old schema to new schema only after backfill verification passes.
−
−### Contract Phase
−
−Remove old columns, old indexes, old code paths, and compatibility logic only after the new path is stable.
−
−### Cleanup Phase
−
−Remove temporary commands, flags, logging, and compatibility code after production verification.
−
−## Output Format
−
−### 1. Executive Summary
−
−Provide a short summary of:
−
−1. Overall migration risk level.
−2. Whether the migration appears safe for production.
−3. Main hazards found.
−4. Whether zero-downtime deployment is realistic.
−5. Recommended decision.
−
−Use one of these decisions:
−
−1. Safe to deploy as written.
−2. Safe with minor changes.
−3. Requires phased rollout.
−4. Requires backfill plan before deployment.
−5. Not safe for production as written.
−6. Not enough information to decide.
−
−### 2. Migration Inventory
−
−Create a table with:
−
−1. Migration file.
−2. Affected table.
−3. Operation.
−4. Columns or indexes affected.
−5. Data affected.
−6. Risk level.
−7. Notes.
−
−### 3. Migration Risk Assessment
−
−Assess each risk area:
−
−1. Table lock risk.
−2. Long-running operation risk.
−3. Data loss risk.
−4. Rollback risk.
−5. Backfill risk.
−6. Application compatibility risk.
−7. Queue and job compatibility risk.
−8. Index risk.
−9. Foreign key risk.
−10. Unique constraint risk.
−11. Deployment-order risk.
−12. Maintenance-window risk.
−
−Use this scale:
−
−1. Low.
−2. Medium.
−3. High.
−4. Unknown.
−
−Explain every high or unknown risk.
−
−### 4. Unsafe or Risky Operations
−
−List any operations that should not be run as-is in production.
−
−For each one, include:
−
−1. File.
−2. Operation.
−3. Why it is risky.
−4. Production impact.
−5. Safer alternative.
−6. Whether code changes are needed.
−
−### 5. Safe Rollout Plan
−
−Provide a phased rollout plan.
−
−Include:
−
−1. Pre-deployment checks.
−2. Expand migration.
−3. Compatibility code changes.
−4. Backfill approach.
−5. Verification after backfill.
−6. Read-switch or behavior-switch step.
−7. Contract migration.
−8. Cleanup.
−9. Final verification.
−
−If a phased rollout is not needed, explain why.
−
−### 6. Backfill Plan
−
−If data backfill is needed, provide:
−
−1. What data must be backfilled.
−2. Estimated risk based on known table size.
−3. Batch size recommendation.
−4. Whether to use an Artisan command, queued job, scheduled job, or manual script.
−5. Idempotency requirements.
−6. Progress tracking.
−7. Retry behavior.
−8. Failure recovery.
−9. Verification query or check.
−10. When it is safe to continue to the next phase.
−
−If no backfill is needed, say so.
−
−### 7. Code Compatibility Notes
−
−Review whether old and new code can run safely during deployment.
−
−Check:
−
−1. Models.
−2. Fillable or guarded fields.
−3. Casts.
−4. Accessors and mutators.
−5. Validation rules.
−6. Controllers and services.
−7. Jobs and queues.
−8. Scheduled tasks.
−9. Events and listeners.
−10. API resources.
−11. Tests.
−12. Factories and seeders.
−
−Explain any compatibility issue.
−
−### 8. Rollback and Recovery Plan
−
−Do not rely only on the migration `down` method.
−
−Provide:
−
−1. Whether rollback is safe.
−2. Whether rollback can cause data loss.
−3. Whether a database backup is required.
−4. Whether the application can continue running if rollback is partial.
−5. Recovery steps if the migration fails midway.
−6. Recovery steps if the backfill fails.
−7. Recovery steps if the application deploy must be reverted.
−8. Human approval gates before destructive rollback.
−
−### 9. Recommended Migration Edits
−
−If edits are needed, describe the minimal safe changes.
−
−For each recommended edit, include:
−
−1. File.
−2. Current issue.
−3. Recommended change.
−4. Why it reduces risk.
−5. Whether it changes application behavior.
−
−Only recommend code edits that are necessary for migration safety.
−
−### 10. Verification Commands
−
−Provide commands and checks for:
−
−1. Static review.
−2. Laravel migration status.
−3. Migration dry-run or SQL preview where possible.
−4. Test suite.
−5. Database checks.
−6. Backfill verification.
−7. Post-deployment verification.
−8. Rollback readiness.
−
−Use commands appropriate to the repository.
−
−If a command depends on missing project details, mark it as a suggested command and ask the user to confirm.
−
−### 11. Production Deployment Checklist
−
−Create a checklist for the release owner.
−
−Include:
−
−1. Backup confirmed.
−2. Maintenance constraints confirmed.
−3. Table sizes checked.
−4. Indexes checked.
−5. Migration reviewed.
−6. Application compatibility checked.
−7. Queue workers considered.
−8. Backfill plan reviewed.
−9. Rollback plan reviewed.
−10. Monitoring prepared.
−11. Human approval received.
−12. Post-deployment verification completed.
−
−### 12. Human Review Gates
−
−List the points where a human should approve before proceeding.
−
−Include review gates for:
−
−1. Destructive schema changes.
−2. Customer data changes.
−3. Payment or billing data changes.
−4. Authentication or authorization changes.
−5. Large-table operations.
−6. Irreversible transformations.
−7. Contract or cleanup migrations.
−8. Production rollback.
−
−### 13. Final Recommendation
−
−End with:
−
−1. Recommended decision.
−2. Required changes before deployment.
−3. Safest deployment sequence.
−4. Highest-risk unresolved assumption.
−5. Next action for the developer.
−
−## Verification
−
−Before finalizing, confirm that:
−
−1. Every migration file was reviewed.
−
−2. Every affected table was identified.
−
−3. Destructive operations were flagged.
−
−4. Long-running or locking operations were flagged.
−
−5. Backfill needs were identified.
−
−6. Rollback risk was assessed.
−
−7. Application compatibility was reviewed.
−
−8. Safe rollout phases were recommended where needed.
−
−9. Verification commands were provided.
−
−10. Missing assumptions were listed.
−
−## Final Instruction to Begin
−
−Begin now.
−
−If migration files, database engine, table sizes, or deployment constraints are missing, ask for them first.
−
−If enough context is available, inspect the repository and produce the full zero-downtime Laravel migration review in the requested markdown format.
+Review the proposed Laravel schema and data migration change set for zero-downtime feasibility and production safety using Codex and the actual repository.
+
+Use only repository content, database evidence, command output, and operational facts that are supplied or genuinely accessible in the current Codex workspace.
+
+## Required inputs
+
+- Repository and change set: [Repository and change set]
+- Framework and database versions: [Framework and database versions]
+- Production schema evidence: [Production schema evidence]
+- Workload and table evidence: [Workload and table evidence]
+- Deployment topology and compatibility window: [Deployment topology and compatibility window]
+- Backfill and recovery constraints: [Backfill and recovery constraints]
+- Operational limits and approvals: [Operational limits and approvals]
+- Acceptance evidence: [Acceptance evidence]
+
+The repository and change-set input should identify, where relevant:
+
+- the exact release, commit, branch, or diff under review;
+- migration files;
+- raw SQL;
+- related models and casts;
+- accessors and mutators;
+- validation rules;
+- services and query builders;
+- controllers and API resources;
+- jobs and queue payloads;
+- events and listeners;
+- scheduled commands;
+- factories and seeders;
+- tests;
+- feature flags;
+- application deployment order.
+
+Production schema evidence should include, where available:
+
+- current columns and data types;
+- defaults;
+- nullability;
+- indexes;
+- constraints;
+- foreign keys;
+- generated columns;
+- approximate row counts;
+- duplicate, null, orphan, or invalid-data counts;
+- relevant database metadata;
+- observed schema drift.
+
+Workload and table evidence should describe, where available:
+
+- read and write rates;
+- transaction duration;
+- long-running transactions;
+- high-traffic periods;
+- table growth;
+- replica use and acceptable lag;
+- connection pooling;
+- lock or statement timeouts;
+- queue throughput;
+- scheduled workloads;
+- disk, transaction-log, or WAL constraints.
+
+Deployment topology should identify:
+
+- environments;
+- promotion order;
+- application instances;
+- queue workers;
+- scheduled processes;
+- deployment strategy;
+- mixed-version window;
+- maintenance constraints;
+- maximum acceptable interruption or degradation.
+
+Backfill and recovery constraints should identify:
+
+- whether data transformation is required;
+- acceptable batch and runtime limits;
+- retry and resume requirements;
+- backup scope and freshness;
+- restore evidence;
+- rollback and roll-forward expectations;
+- data-loss tolerance.
+
+Operational limits and approvals should state:
+
+- permitted read-only inspection;
+- permitted local commands;
+- whether file edits are permitted;
+- prohibited actions;
+- production-access restrictions;
+- database-owner and release-owner responsibilities;
+- required human approval gates.
+
+Acceptance evidence should define the observable conditions required before:
+
+- rehearsal;
+- schema expansion;
+- backfill;
+- read switching;
+- constraint validation;
+- contract work;
+- cleanup;
+- production completion.
+
+## Zero-downtime standard
+
+Do not interpret “zero downtime” as a literal guarantee of zero locks, zero latency change, or zero operational impact.
+
+Evaluate zero-downtime feasibility against the supplied service objectives and acceptance constraints, including:
+
+- permitted service interruption;
+- acceptable latency or error-rate change;
+- write availability;
+- queue delay;
+- replica lag;
+- maintenance allowance;
+- user-visible degradation;
+- compatibility requirements.
+
+If those thresholds are not supplied, mark zero-downtime feasibility as unverified. Do not invent an acceptable outage or degradation threshold.
+
+## Input and evidence rules
+
+1. Begin with an input-status table. Classify every required input as:
+
+   - supplied;
+   - observed in the accessible workspace;
+   - missing;
+   - ambiguous;
+   - conflicting;
+   - not applicable.
+
+2. Bind all material evidence to the exact release under review where possible. Record:
+
+   - commit, revision, or diff;
+   - migration filename and identifier;
+   - database engine and version;
+   - target environment;
+   - schema snapshot date;
+   - workload measurement window;
+   - command or rehearsal timestamp;
+   - artifact or output identity.
+
+   Evidence from another commit, migration set, database version, schema state, environment, or execution window is not automatically evidence for this release.
+
+3. Cite repository findings using available file paths, line ranges, classes, methods, migration names, or symbols.
+
+4. Cite operational findings by naming the supplied:
+
+   - schema snapshot;
+   - command output;
+   - metric;
+   - query result;
+   - runbook;
+   - deployment record;
+   - backup record;
+   - rehearsal artifact;
+   - user statement.
+
+5. Label every material statement as one of:
+
+   - confirmed;
+   - inferred;
+   - assumed;
+   - unknown;
+   - conflicting.
+
+   Never convert an assumption or generic database practice into a confirmed finding.
+
+6. If migration files are unavailable, stop after listing the exact migrations and related code required. Do not issue a deployment or zero-downtime decision.
+
+7. If the database engine or exact version is missing or conflicting, do not make engine-specific claims about:
+
+   - locking;
+   - online DDL;
+   - table rewrites;
+   - transactional behavior;
+   - concurrent index creation;
+   - instant or in-place alterations.
+
+   Request authoritative version output.
+
+8. If table size, write load, production schema, long-running transactions, or deployment topology is unknown, mark lock duration and zero-downtime feasibility unknown. Do not automatically classify the operation as safe or unsafe.
+
+9. Reconcile repository migrations with the actual production schema.
+
+   Production schema evidence governs operational risk. Repository history remains evidence of intended state.
+
+   Unexplained schema drift is a release blocker.
+
+10. Distinguish clearly:
+
+    - requested work;
+    - proposed edits or commands;
+    - executed checks;
+    - supplied execution evidence;
+    - unavailable checks;
+    - unverified results.
+
+    A command is executed only when Codex actually runs it in an authorized environment and captures its result.
+
+    Command output supplied by the user is supplied evidence, not independently reproduced evidence.
+
+11. Do not invent:
+
+    - row counts;
+    - batch sizes;
+    - operation duration;
+    - lock duration;
+    - throughput;
+    - replica lag;
+    - backup validity;
+    - restore success;
+    - database behavior;
+    - test output;
+    - deployment success.
+
+12. When a numerical recommendation cannot be supported, provide a calibration method or bounded range instead of false precision.
+
+## Codex authority boundaries
+
+Unless [Operational limits and approvals] explicitly restricts it, permit:
+
+- read-only repository inspection;
+- inspection of supplied schema metadata;
+- non-mutating local diagnostics;
+- review of existing test and deployment configuration.
+
+Treat the following as unauthorized unless expressly approved:
+
+- file edits;
+- mutating commands;
+- dependency changes;
+- database writes;
+- migrations;
+- backfills;
+- destructive SQL;
+- production queries;
+- load tests;
+- cache or queue changes;
+- deployments;
+- rollbacks;
+- external-service changes.
+
+Even where local edits are authorized, do not execute:
+
+- production migrations;
+- production backfills;
+- destructive SQL;
+- production rollback commands;
+- deployment;
+- DNS or infrastructure changes.
+
+Production execution, restore decisions, destructive changes, and release approval remain human-controlled actions.
+
+Do not expose credentials, connection strings, customer records, personal data, payment data, or confidential production rows. Request redacted schema metadata, aggregate counts, and sanitized samples.
+
+If repository edits are separately authorized, make only the smallest reviewable changes required to reduce migration risk. Keep applied changes separate from proposed but unapplied work.
+
+## Focused review workflow
+
+### 1. Establish the release identity and review scope
+
+Record:
+
+- release or commit identity;
+- migration files;
+- related application components;
+- target database engine and version;
+- target environment;
+- deployment strategy;
+- compatibility window;
+- maintenance limits;
+- supplied acceptance criteria.
+
+State explicitly what Codex inspected and what remained unavailable.
+
+### 2. Reconcile the migration surface
+
+Inventory every `up` and `down` operation and every raw SQL statement.
+
+For each operation, identify:
+
+- migration file and location;
+- table or relation;
+- columns;
+- data types;
+- defaults;
+- nullability;
+- generated values;
+- indexes;
+- uniqueness rules;
+- foreign keys;
+- check constraints;
+- data transformations;
+- application dependencies.
+
+Trace old and new schema names through:
+
+- models;
+- casts;
+- accessors and mutators;
+- validation;
+- services;
+- queries;
+- API resources;
+- events and listeners;
+- queue payloads;
+- scheduled work;
+- reports;
+- imports and exports;
+- factories and seeders;
+- tests.
+
+Flag behavior dependent on:
+
+- Laravel version;
+- database driver;
+- doctrine/dbal;
+- database-server version;
+- migration configuration;
+- transactional DDL support.
+
+Do not infer the current production schema solely from migration history.
+
+### 3. Analyze database-engine behavior
+
+For MySQL or MariaDB, assess the supplied version and operation against applicable:
+
+- instant, in-place, or table-copy behavior;
+- metadata-lock acquisition;
+- index-build concurrency;
+- implicit commits;
+- foreign-key checks;
+- generated-column behavior;
+- default-expression support;
+- row format;
+- online-DDL options;
+- replica effects.
+
+Treat `ALGORITHM`, `LOCK`, online DDL, or similar clauses as proposals until their support is validated against the exact engine and version.
+
+Identify long transactions that could delay metadata locks.
+
+For PostgreSQL, assess:
+
+- catalog-only versus table-rewrite behavior;
+- required lock level and likely duration;
+- transaction boundaries;
+- `CREATE INDEX CONCURRENTLY`;
+- `DROP INDEX CONCURRENTLY`;
+- invalid indexes after failure;
+- `NOT VALID` constraints;
+- later constraint validation;
+- default-value behavior;
+- type-change rewrites;
+- long-running transactions;
+- dead tuples;
+- WAL growth;
+- replica lag.
+
+Identify where Laravel migration transaction behavior conflicts with concurrent operations.
+
+For another engine, limit conclusions to documented behavior supported by supplied evidence.
+
+SQLite development success is not evidence that a MySQL, MariaDB, or PostgreSQL production migration is safe.
+
+Do not recommend an external online-schema-change tool unless its suitability, operational ownership, constraints, and approval requirements have been evaluated separately.
+
+### 4. Analyze operation-specific failure modes
+
+If this is a prospective review, analyze credible migration failure modes without pretending a failure has already occurred.
+
+If an actual migration has failed, reconstruct the failure using supplied evidence and establish root cause only where the causal chain is supported.
+
+Check for:
+
+- non-null additions before compatible writes and backfill completion;
+- expensive defaults or table rewrites;
+- in-place type changes;
+- truncation;
+- collation or encoding changes;
+- lossy casts;
+- renames or drops while old code still uses the schema;
+- unique indexes before duplicate and null-semantics checks;
+- foreign keys before orphan and supporting-index review;
+- cascade effects;
+- indexes that do not match observed query predicates or ordering;
+- blocked writes;
+- metadata-lock queues;
+- statement or lock timeouts;
+- disk or temporary-space pressure;
+- transaction-log or WAL growth;
+- replica lag;
+- failover exposure;
+- schema and data changes combined into one irreversible unit;
+- unbounded updates;
+- offset-based backfills;
+- mutable pagination keys;
+- hot-row contention;
+- retries that duplicate effects;
+- queue flooding;
+- `down` methods that destroy data or restore structure without restoring meaning;
+- migration ordering and timestamp collisions;
+- environment-dependent migrations;
+- non-idempotent raw SQL;
+- mixed-version incompatibility.
+
+A migration `down` method is not, by itself, a complete rollback or recovery plan.
+
+### 5. Evaluate mixed-version compatibility
+
+Determine whether old and new application versions can coexist with the intermediate schema.
+
+Include:
+
+- web processes;
+- API processes;
+- queue workers;
+- delayed jobs;
+- scheduled commands;
+- reports;
+- exports;
+- integrations;
+- external consumers.
+
+Check:
+
+- reads from old and new columns;
+- writes to old and new columns;
+- dual-write behavior;
+- default and null handling;
+- serialized queue payloads;
+- cache-key or serialization changes;
+- deployment and worker restart order;
+- feature-flag ownership and defaults.
+
+Do not allow contract work while old application or worker versions may still depend on the old schema.
+
+### 6. Determine the compatible release sequence
+
+For every risky change, decide whether it requires:
+
+1. expand;
+2. compatibility code;
+3. dual write;
+4. backfill;
+5. reconciliation;
+6. read switch;
+7. constraint validation;
+8. contract;
+9. cleanup.
+
+For every phase, define:
+
+- compatible application versions;
+- compatible worker versions;
+- required entry evidence;
+- proposed action;
+- monitoring signals;
+- pause conditions;
+- acceptance criteria;
+- recovery path;
+- approval gate.
+
+Use feature flags only where ownership, default state, rollback behavior, and removal criteria are supplied or explicitly proposed.
+
+### 7. Design a controlled backfill
+
+Do not place a large backfill inside a schema migration.
+
+When a backfill is required, specify:
+
+- a versioned Artisan command, controlled job, or reviewed script;
+- stable keyset batching;
+- candidate batch-size range;
+- staging calibration method;
+- transaction scope;
+- idempotency predicate or key;
+- throttling signal;
+- checkpointing;
+- progress metrics;
+- retry behavior;
+- pause and resume behavior;
+- failed-record quarantine;
+- observability;
+- termination criteria.
+
+Base numerical recommendations on supplied measurements. Otherwise mark them for calibration.
+
+Define reconciliation using:
+
+- candidate count;
+- processed count;
+- success count;
+- skipped count;
+- failure count;
+- remaining count;
+- invariant checks.
+
+Unexplained differences must block progression.
+
+### 8. Design rollback and forward recovery
+
+Separate:
+
+- application rollback;
+- schema rollback;
+- backfill pause;
+- backfill reversal;
+- data restoration;
+- forward-compatible recovery.
+
+Prefer forward recovery when:
+
+- a destructive `down` method would lose data;
+- old code cannot operate against the new schema;
+- a partial backfill has changed business meaning;
+- contract work has already removed compatibility.
+
+Identify:
+
+- the last reversible phase;
+- failure indicators;
+- immediate safe response;
+- data-loss exposure;
+- backup dependencies;
+- restore dependencies;
+- partial-failure handling;
+- approval gates;
+- evidence required before resuming.
+
+A backup claim is insufficient without evidence of:
+
+- scope;
+- freshness;
+- retention;
+- encryption handling;
+- access;
+- restore testing appropriate to the change.
+
+### 9. Define verification and acceptance evidence
+
+Propose repository-appropriate checks. Do not imply that SQL generation or `migrate --pretend` proves online execution safety.
+
+Where applicable, include:
+
+- migration-operation reconciliation;
+- production-schema reconciliation;
+- generated-SQL review;
+- engine-supported DDL validation;
+- duplicate checks;
+- orphan checks;
+- null and range checks;
+- truncation and cast-failure checks;
+- representative query plans;
+- old-version application tests;
+- mixed-version tests;
+- new-version tests;
+- queue-worker compatibility tests;
+- production-like rehearsal;
+- lock-wait observations;
+- blocked-session observations;
+- disk and temporary-space observations;
+- transaction-log or WAL growth;
+- replica-lag observations;
+- backfill reconciliation;
+- post-phase schema and data checks;
+- rollback or forward-recovery rehearsal.
+
+For every proposed command or query, state:
+
+- purpose;
+- target environment;
+- expected observation;
+- failure meaning;
+- safety caveat;
+- work state: proposed, executed, supplied, unavailable, or unverified.
+
+Avoid production-wide scans unless an authorized operator confirms:
+
+- acceptable execution plan;
+- timeout;
+- replica or primary target;
+- impact window;
+- cancellation method.
+
+## Risk classification
+
+Use only these qualitative states:
+
+- Critical — credible risk of data loss, corruption, prolonged outage, irreversible change, uncontrolled production impact, or a release state from which neither old nor new code can recover safely.
+
+- High — material lock, availability, compatibility, integrity, backfill, rollback, or recovery risk requiring correction or explicit evidence before progression.
+
+- Medium — a meaningful but controllable risk requiring defined safeguards, monitoring, ownership, or a phased release condition.
+
+- Low — evidence supports limited blast radius and acceptable behavior within the supplied operational constraints.
+
+- Unknown — available evidence is insufficient to classify the risk defensibly.
+
+Do not rate a risk Low solely because the migration is small, passes locally, or uses a familiar Laravel schema method.
+
+## Output contract: zero-downtime migration review deliverable
+
+Keep the report concise and proportional to the migration scope, risk, and available evidence.
+
+Do not repeat the same evidence or limitation across multiple sections. Use operation IDs, finding IDs, and evidence IDs for cross-reference.
+
+Where a subsection is genuinely not applicable, retain the heading, state `Not applicable`, and explain briefly why.
+
+Never omit:
+
+- evidence and coverage;
+- schema-operation register;
+- blockers;
+- compatibility analysis;
+- recovery;
+- verification;
+- release decision.
+
+### A. Review basis and evidence coverage
+
+Report:
+
+- exact release identity;
+- target environment;
+- database engine and version;
+- migration files and related code inspected;
+- unavailable materials;
+- supplied, observed, missing, ambiguous, and conflicting inputs;
+- zero-downtime acceptance definition;
+- review limitations.
+
+### B. Schema-operation register
+
+For every operation provide:
+
+- operation ID;
+- migration and location;
+- generated or intended DDL;
+- affected object;
+- data touch;
+- engine and version dependency;
+- expected lock or rewrite behavior;
+- rolling-code compatibility;
+- reversibility;
+- supporting evidence;
+- risk state.
+
+### C. Blocking findings and risk register
+
+For every material finding provide:
+
+- finding ID;
+- operation or release phase;
+- failure scenario;
+- triggering condition;
+- impact;
+- risk state;
+- supporting evidence;
+- uncertainty;
+- minimum risk-reducing change;
+- required owner;
+- closure evidence.
+
+Treat these as blockers until resolved:
+
+- unknown engine-specific lock or rewrite behavior for a material operation;
+- unreconciled production-schema drift;
+- unbounded backfills;
+- destructive changes without recovery;
+- incompatible mixed-version operation;
+- missing required acceptance evidence.
+
+### D. Compatible phased migration design
+
+Provide the ordered release plan.
+
+For each phase state:
+
+- migration or code change;
+- compatible application and worker versions;
+- entry evidence;
+- proposed action;
+- monitoring signals;
+- pause thresholds;
+- acceptance criteria;
+- rollback or forward-recovery path;
+- approval gate.
+
+If a single-phase release is sufficient, justify that conclusion using engine-specific, workload, compatibility, and recovery evidence.
+
+### E. Backfill control sheet
+
+State:
+
+- selection predicate;
+- stable cursor;
+- batching method;
+- calibration method;
+- idempotency behavior;
+- transaction boundary;
+- throttle and pause signals;
+- retry handling;
+- checkpoint storage;
+- progress metrics;
+- reconciliation equations;
+- anomaly handling;
+- completion criteria;
+- read-switch and contract prerequisites.
+
+If no backfill is required, state `Not applicable` and explain why.
+
+### F. Mixed-version compatibility record
+
+Report compatibility for:
+
+- old application with expanded schema;
+- new application with intermediate schema;
+- queue workers and delayed jobs;
+- scheduled commands;
+- APIs and integrations;
+- caches and serialized data;
+- feature flags;
+- contract and cleanup timing.
+
+Identify the last point at which old code remains safe.
+
+### G. Recovery matrix
+
+Cover failure:
+
+- before DDL;
+- during DDL;
+- after schema expansion;
+- during backfill;
+- after read switch;
+- during contract;
+- after application rollback.
+
+For each case state:
+
+- observable symptoms;
+- immediate safe response;
+- approval-required action;
+- data-loss exposure;
+- recovery evidence;
+- whether old and new code remain operable.
+
+### H. Verification runbook
+
+List commands, SQL, tests, and observations in release order.
+
+For each item provide:
+
+- check ID;
+- purpose;
+- target environment;
+- command or method;
+- expected result;
+- actual supplied or observed result;
+- evidence;
+- safety limit;
+- status: proposed, executed, supplied, unavailable, or unverified;
+- acceptance result: pass, fail, investigate, or not assessed.
+
+Never fabricate command output.
+
+### I. Release decision record
+
+Choose exactly one status:
+
+- Ready for authorized rehearsal
+- Ready for authorized phased production rollout
+- Changes required
+- Blocked by missing evidence
+- Unsafe as proposed
+
+State:
+
+- zero-downtime feasibility;
+- highest residual risks;
+- required changes;
+- unresolved assumptions;
+- required human approvals;
+- next evidence-producing action.
+
+Do not use “safe to deploy” unless every mandatory acceptance criterion is supported by current, release-bound evidence.
+
+## Final quality gate
+
+Before returning the report, verify that:
+
+1. Every migration operation is accounted for.
+2. The reviewed evidence is bound to the exact release where possible.
+3. Production schema drift is reconciled or explicitly blocking.
+4. Database-engine and version dependencies are addressed.
+5. Lock, rewrite, index, constraint, and transaction behavior are assessed.
+6. Mixed-version application and worker compatibility is evaluated.
+7. Backfills are bounded, resumable, idempotent, observable, and reconciled where required.
+8. Rollback and forward-recovery paths are distinguished.
+9. Proposed commands include expected observations and safety limits.
+10. Acceptance criteria reconcile schema, data, application behavior, workers, and operations.
+11. Zero-downtime feasibility is tied to supplied service constraints.
+12. No execution, verification, approval, deployment, recovery, or completion is claimed without evidence.