---
id: db-predeploy-checklist
kind: checklist
agent: data-engineer
gate: Database Pre-Deploy
decision: "qualquer CRÍTICO falho → BLOQUEADO; senão APROVADO (ALTO falho exige mitigação registrada)"
---

# Database Pre-Deploy Checklist (Database Pre-Deploy)

> A Dara roda isto antes de qualquer migration tocar o banco-alvo. Valida o `migration-plan-tmpl`, o
> `schema-design-tmpl` e o `rls-policies-tmpl` que alimentam o deploy. Veredito: **APROVADO** ou
> **BLOQUEADO**. Migration que entra sem passar aqui é incidente esperando para acontecer.

## Critérios

### Reversibilidade (CRÍTICO — qualquer falha bloqueia)

- [ ] 1. **Snapshot baseline criado** — ponto de rollback existe antes de aplicar (`*snapshot {label}`).
- [ ] 2. **Rollback script pronto** — cada passo forward tem reverso idempotente; restauração de snapshot documentada. Se não sei desfazer, não aplico.
- [ ] 3. **Ponto de não-retorno identificado** — perdas irreversíveis (DROP com dados) estão explícitas e autorizadas.

### Integridade (CRÍTICO — qualquer falha bloqueia)

- [ ] 4. **Baseline em toda tabela nova** — `id` (PK), `created_at`, `updated_at` presentes; `deleted_at` onde há auditoria.
- [ ] 5. **FKs explícitas com ON DELETE definido** — toda relação tem foreign key e ação de delete declarada.
- [ ] 6. **Constraints de negócio no banco** — CHECK/UNIQUE/NOT NULL fazem cumprir as regras; integridade não delegada só à aplicação.

### Segurança RLS (CRÍTICO — qualquer falha bloqueia)

- [ ] 7. **RLS habilitada em toda tabela pública** — nenhuma tabela exposta sem Row Level Security.
- [ ] 8. **Testes RLS positivos E negativos passam** — quem pode acessa, quem não pode é barrado (`*test-as-user`).
- [ ] 9. **service_role justificado** — todo bypass de RLS tem motivo registrado; nenhum segredo vaza em log.

### Procedimento (ALTO — falha exige mitigação registrada)

- [ ] 10. **Ordem do DDL validada** — dependências primeiro; dry-run sem erro (`*verify-order` + `*dry-run`).
- [ ] 11. **Idempotência verificada** — `IF NOT EXISTS`/`IF EXISTS`/merges; rodar duas vezes é seguro.
- [ ] 12. **Aplicação em transação** — migration roda atômica; falha no meio não deixa schema parcial.
- [ ] 13. **Revisão CodeRabbit limpa** — sem achado CRÍTICO aberto; ALTO mitigado ou com rollback comprovado.

### Performance (ALTO — falha exige mitigação registrada)

- [ ] 14. **Índices justificados por query real** — cada índice serve a um padrão de acesso; nenhuma FK quente sem índice.
- [ ] 15. **Impacto de lock/downtime avaliado** — locks de tabela e janela de aplicação dimensionados por evidência, não palpite.

## Decisão

**Veredito:** APROVADO / BLOQUEADO
**Críticos falhos:** {lista — itens 1-9 reprovados}
**Altos falhos (com mitigação):** {lista — itens 10-15 reprovados e como serão mitigados}
**Correções obrigatórias (se BLOQUEADO):**
- {item — o que falta para liberar o deploy}

> Regra: **qualquer CRÍTICO falho → BLOQUEADO**, sem exceção. ALTO falho não bloqueia por si só, mas
> exige mitigação ou rollback script comprovado registrado acima. BLOQUEADO não é reprovação — é a
> lista exata do que a Dara ajusta antes de a migration tocar produção.