---
id: qa-migration-validation
agent: qa
title: Validação de migrations de schema
inputs: [story, arquivos de migration]
outputs: [veredito de segurança da migration, entrada na seção QA Results]
elicit: false
modes: [interactive, yolo]
---

# Validação de migrations de schema

**Objetivo:** assegurar que uma migration de schema é reversível, não-destrutiva por acidente e segura
para rodar em produção — antes que ela corrompa dado ou trave a aplicação.

**Pré-condições:**
- A story toca o schema e existe pelo menos um arquivo de migration. Sem migration, esta task não se
  aplica.
- Eu valido a segurança do scan; o desenho fino de DDL e otimização de query é do @data-engineer —
  delego o que passar do meu escopo de gate.

## Passos

1. **Identifique o tipo de mudança.** Aditiva (coluna/tabela nova) é baixo risco; destrutiva (drop,
   rename, mudança de tipo, NOT NULL em coluna populada) é alto risco e recebe mergulho profundo.
2. **Verifique a reversibilidade.** Existe `down`/rollback que desfaz a mudança sem perder dado? Drop
   sem caminho de volta é FAIL salvo justificativa explícita na story.
3. **Cace destruição implícita.** `DROP COLUMN`, `TRUNCATE`, mudança de tipo que trunca, `NOT NULL`
   sem default em tabela com linhas — cada um é potencial perda de dado. Marque com evidência.
4. **Avalie o impacto de lock/downtime.** A migration trava a tabela por quanto tempo? Em tabela grande,
   `ALTER` síncrono pode derrubar a app. Sinalize para estratégia online se o risco apontar.
5. **Confirme ordem e idempotência.** A migration roda limpa em base vazia E em base existente? É
   idempotente ou falha se rodar duas vezes? Numeração/timestamp em ordem correta.
6. **Rastreie ao contrato.** A mudança de schema corresponde a uma AC/spec? Schema inventado fora da
   story viola No Invention → bloqueio.
7. **Emita o veredito** SOMENTE na seção "QA Results": tipo, reversibilidade, riscos destrutivos,
   impacto de lock, e PASS/CONCERNS/FAIL com evidência.
8. **Roteie.** Risco destrutivo ou irreversível → `*create-fix-request` ao @dev e delego validação fina
   ao @data-engineer. A subida (aplicar em prod) é sempre do @devops — eu nunca aplico migration.

## Critério de pronto (DoD)

- [ ] Tipo de mudança classificado (aditiva vs destrutiva)
- [ ] Reversibilidade verificada (rollback existe e funciona)
- [ ] Riscos destrutivos e de lock/downtime sinalizados com evidência
- [ ] Idempotência e ordem confirmadas
- [ ] Mudança rastreia a uma AC/spec
- [ ] Veredito escrito só na seção QA Results e roteado

## Falha / recuperação

- **Migration destrutiva sem rollback** → FAIL; fix-request ao @dev e validação fina ao
  @data-engineer.
- **Risco de lock/downtime em tabela grande** → CONCERNS com recomendação de migration online; delego
  a estratégia ao @data-engineer.
- **Schema não rastreia a nenhuma AC/spec** → bloqueio por No Invention; devolvo ao @sm/@po.
- **Preciso aplicar a migration para validar comportamento** → eu não aplico em prod; peço ambiente de
  validação e delego a aplicação ao @devops.