DB Guard: antes que a migration de um agente chegue à produção

São verificados os arquivos alterados em caminhos como migrations/, prisma/migrations, db/migrate e Flyway V1__x.sql. Ele lê SQL de Postgres, MySQL e SQLite, e código de migration de Rails, Laravel, Django e ferramentas no estilo Knex ou Sequelize.

• DROP TABLE e DROP COLUMN, TRUNCATE, UPDATE e DELETE sem WHERE.
• CREATE INDEX sem CONCURRENTLY, ALTER TYPE, SET NOT NULL, novas constraints FK, CHECK e UNIQUE.
• Migrations sem passo de down; RunPython sem reverse_code no Django.
• Níveis de risco: nenhum, baixo, médio, alto; perda de dados é sinalizada à parte.

Escolha uma das conexões do seu gerenciador de banco de dados como “production-like” (parecida com produção) e as contagens reais de linhas são lidas, então o risco cresce com o tamanho da tabela. Sem ela, os riscos são avaliados sem saber os tamanhos. Risco alto ou médio, ou perda de dados, dispara uma notificação na área de trabalho.

Todo relatório tem botões para o próximo passo.

• Testar no banco sombra: roda a migration em uma conexão de desenvolvimento ou staging dentro de uma transação que é sempre desfeita.
• Revisar com o Claude: uma revisão do Claude somente leitura.
• Pedir ao agente para deixá-la segura: os achados vão para o agente que escreveu a migration; se ele não existir mais, abre um novo agente Claude “DB Guard düzeltme” (correção do DB Guard).
• Analisar SQL: cole a saída de um migration.sql do Prisma, de artisan migrate --pretend ou de manage.py sqlmigrate para checar.