DB Guard: bevor die Migration eines Agents in die Produktion gelangt

Geprüft werden geänderte Dateien unter Pfaden wie migrations/, prisma/migrations, db/migrate und Flyway V1__x.sql. Gelesen wird SQL für Postgres, MySQL und SQLite sowie Migrationscode für Rails, Laravel, Django und Tools im Stil von Knex oder Sequelize.

• DROP TABLE und DROP COLUMN, TRUNCATE, UPDATE und DELETE ohne WHERE.
• CREATE INDEX ohne CONCURRENTLY, ALTER TYPE, SET NOT NULL, neue FK-, CHECK- und UNIQUE-Constraints.
• Migrationen ohne Down-Schritt; RunPython ohne reverse_code in Django.
• Risikostufen: none, low, medium, high; Datenverlust wird gesondert markiert.

Wähle eine deiner Verbindungen im Datenbank-Manager als „production-like“, dann werden echte Zeilenzahlen gelesen und das Risiko skaliert mit der Tabellengröße. Ohne eine solche Verbindung werden Risiken ohne Kenntnis der Größen bewertet. Hohes oder mittleres Risiko oder Datenverlust löst eine Desktop-Benachrichtigung aus.

Jeder Bericht hat Buttons für den nächsten Schritt.

• Try on shadow DB: führt die Migration auf einer Entwicklungs- oder Staging-Verbindung in einer Transaktion aus, die immer zurückgerollt wird.
• Review with Claude: ein schreibgeschütztes Claude-Review.
• Have the agent make it safe: die Befunde gehen an den Agent, der die Migration geschrieben hat; ist er weg, öffnet sich ein neuer Claude-Agent „DB Guard düzeltme“.
• Analyse SQL: füge eine Prisma-migration.sql, die Ausgabe von artisan migrate --pretend oder manage.py sqlmigrate ein, um sie zu prüfen.