---
id: db-smoke-test
agent: data-engineer
title: Bateria de smoke-test do banco pós-migração
inputs: [versão/migration alvo, story/spec de origem]
outputs: [relatório de smoke-test (verde/vermelho por checagem)]
elicit: false
modes: [interactive, yolo]
---

# Bateria de smoke-test do banco pós-migração

**Objetivo:** provar rapidamente que o banco está saudável depois de uma migration/seed — estruturas,
integridade, RLS e queries de caminho crítico — antes de declarar a operação pronta.

**Pré-condições:**
- A migration/seed da versão-alvo já foi aplicada.
- As checagens rastreiam aos ACs/padrões de acesso da story/spec — não invento teste fora do escopo.

## Passos

1. **Estrutura:** confirme que as tabelas, colunas, FKs, constraints e índices esperados pela versão
   existem, e que toda tabela tem o baseline (`id`, `created_at`, `updated_at`).
2. **Integridade:** rode checagens de FK órfã, constraints `CHECK`/`NOT NULL` e unicidade nas chaves
   que importam. Nada de linha violando o contrato do schema.
3. **RLS:** para tabelas públicas, confirme que o RLS está ativo e teste um caso **positivo** (usuário
   autorizado lê o que deve) e um **negativo** (usuário não-autorizado é barrado). RLS sem teste
   negativo é RLS não-verificado.
4. **Queries de caminho crítico:** execute as principais leituras/escritas dos padrões de acesso da
   story e confirme que retornam o esperado, com explain plan sem regressão grosseira (ex.: seq scan
   onde havia índice).
5. **Idempotência operacional:** confirme que reaplicar a migration/seed não quebra (replay seguro).
6. **Emita o relatório:** verde/vermelho por checagem, com o detalhe de qualquer falha. Verde em tudo
   → operação pronta. Qualquer vermelho → bloqueia o "pronto".

## Critério de pronto (DoD)

- [ ] Estrutura e baseline verificados
- [ ] Integridade (FKs, constraints, unicidade) sem violação
- [ ] RLS ativo com caso positivo E negativo passando
- [ ] Queries de caminho crítico verdes, sem regressão de plano
- [ ] Relatório emitido com veredito claro

## Falha / recuperação

- **Qualquer checagem vermelha** → a operação **não** está pronta. Reporto a falha e, se for regressão
  da migration aplicada, aciono `db-rollback {snapshot}` para o ponto anterior.
- **RLS falha no caso negativo** (vaza dado para quem não devia) → trato como CRÍTICO, bloqueio e
  corrijo a política antes de qualquer outra coisa.
- **Regressão de performance num caminho crítico** → registro com explain plan e devolvo para ajuste de
  índice/query; não declaro pronto com regressão conhecida.