Skip to main content
1

Identifique o padrão entre sessões

Sua equipe vem usando o playbook !db-migration há algumas semanas. Ele lidou com renomear colunas e adicionar índices sem problemas — mas as duas últimas sessões travaram no meio da migração quando tentaram remover uma coluna referenciada por outras tabelas.Abra cada sessão e observe o ponto de falha. Neste caso, as sessões 3 e 4 apresentaram erro na mesma etapa:
ERROR: cannot drop column "account_id" because other objects depend on it
DETAIL: constraint fk_orders_account_id on table orders depends on column account_id
HINT: Use DROP ... CASCADE to drop dependent objects too.
Agora você tem um sinal claro: o playbook não tem uma etapa para verificar dependências de chave estrangeira antes de operações destrutivas. Duas sessões tiveram sucesso porque atuaram em tabelas independentes; duas falharam porque não atuaram.
2

Abra a aba Improve Playbook com links de sessão

Vá para app.devin.ai e clique em Advanced abaixo da caixa de entrada. Selecione a aba Improve Playbook.Escolha !db-migration no menu suspenso de playbooks e então selecione todas as quatro sessões no session multi-dropdown — tanto as bem-sucedidas quanto as que falharam. Incluir sessões bem-sucedidas permite que o Devin veja o que o playbook faz bem, não apenas onde ele quebra.O que torna esse prompt eficaz:
  • Nomeia exatamente a falha — “foreign key constraints” em vez de “às vezes falha”
  • Contrasta sucessos e falhas — o Devin pode comparar as transcrições das sessões para ver onde elas divergem
  • Lista correções concretas, deixando espaço para o Devin apontar problemas que você não percebeu
3

Revise o diff do playbook

O Devin lê as transcrições das quatro sessões, identifica onde as falhas divergiram dos sucessos e propõe edições específicas. A saída parece um changelog para o seu playbook:
## Analysis

Sessions 1-2 succeeded because they only modified tables with no
incoming foreign keys. Sessions 3-4 failed at step 4 ("Drop the
old column") because the orders and invoices tables had FK
references to the target column.

## Changes to !db-migration

Added step 3a: "Before any DROP or ALTER that removes a column,
  query information_schema.key_column_usage to list dependent FKs.
  If any exist, generate ALTER TABLE ... DROP CONSTRAINT statements
  and execute them first. Save the original constraint DDL for
  rollback."

Added step 7: "Rollback procedure — if any step after FK removal
  fails, re-create the dropped constraints using the saved DDL
  from step 3a."

Updated Advice section: "Always run the migration against a staging
  database first. FK chains can be deeper than expected — a column
  in table A may be referenced by B, which is referenced by C.
  Query recursively."
O playbook é salvo automaticamente. Se algo estiver errado, responda na mesma sessão — por exemplo: “Também adicione uma etapa para notificar o canal #database no Slack antes de executar migrações destrutivas.”
4

Verifique a correção em uma nova migração

Você não precisa sair da sessão atual do Devin. Depois que a atualização do playbook for salva, use a mesma sessão para iniciar uma sessão padrão do Devin que teste o playbook atualizado no exato cenário que falhou antes:Se essa sessão tiver sucesso, a correção funciona. Se encontrar um novo edge case (por exemplo, referências de chave estrangeira circulares), envie essa sessão de volta para a aba Improve Playbook para outra rodada.