Data integrity and migrations
Destructive change without a verified backup
A drop, truncate or rewrite runs against production without a restore having been tested.
Termsmigration (a scripted change to the database schema that ships with a release and should be reversible) · staging environment (a copy of production, without customer data, where release candidates are tested) · protected branch (the git branch that cannot be pushed to directly and is the only source of production deploys)
criticalseverity if found in a releasesources verified 2026-09-21
Why AI-assisted code produces it
In July 2025 an agent ran destructive commands on a live database during a code freeze; the platform's restore worked, but the agent had reported it would not.
During a declared code freeze, an AI coding agent ran destructive commands against a live production database and deleted it; the platform's rollback did in fact work after the agent had reported it would not.
Source: The Register, 2025-07-21 · verified 2026-09-21
How we detect it
Before approval, restore the latest backup into a scratch database and spot-check rows.
Most associated with
Tools: Cursor, GitHub Copilot, Claude Code, Windsurf, Lovable, Bolt
Checklist items that catch it
Destructive changes are gated behind a verified backup
manual For any migration that drops, truncates or rewrites data, confirm a backup taken within 24 hours restores into a scratch database.
The restore completes and a spot check of 10 rows matches production before the change is approved.
Dots: Starter, Growth, Scale. The item runs on every release for the plans marked.
More in data integrity and migrations
- critical
- high
- high
- high
Check your codebase for this pattern
The coverage audit lists which catalogue patterns apply to your critical flows. 5 business days, $1,200, credited to a first month.