## MG-8 — Paridade verificada: os 234 casos na stack nova

**PRD:** `docs/prd/migracao-firebase.md`

**Como** time, **quero** os mesmos casos de teste passando contra o Firebase,
**para** a migração ter prova e não fé.

**Prioridade:** Must — é a métrica de sucesso do PRD. Sem isso, nada é desligado.

**Critérios de aceite:**

- Dado o plano de cada story de produto, quando executo contra a stack nova, então
  os casos passam **com os mesmos IDs** — comparáveis linha a linha com a execução
  do NestJS.
- Dado um caso que passava no NestJS e falha aqui, então é tratado como **defeito de
  migração**, não como "comportamento novo".
- Dado um caso que não tem tradução (ex: rate limit que agora é do Auth), então ele
  é **reescrito e registrado**, nunca silenciosamente descartado.
- Dado que a suíte roda, então ela fala **só** com emulador — nunca com projeto real.
- Dado o custo, então há uma medição real de leituras/escritas por fluxo, não
  estimativa.

**Tasks:**

_QA_
- [ ] `QA-1` Mapa de cobertura: cada caso existente → onde passa a ser verificado (rule, Function, e2e ou device)
- [ ] `QA-2` Reescrever os casos de autorização como testes de security rule (depende de QA-1)
- [ ] `QA-3` Reexecutar os planos de `PP-*`, `PR-*`, `CC-*`, `CV-*` e `AC-*` na stack nova (depende de QA-1)
- [ ] `QA-4` Registrar as divergências como defeito, com o ID do caso (depende de QA-3)
- [ ] `QA-5` Medir leituras e escritas por fluxo e comparar com o free tier (depende de QA-3)

**Riscos/Dependências:**

- Depende de `MG-3` a `MG-7`.
- **É a story mais fácil de fingir que foi feita.** "Os testes passam" sem o mapa de
  cobertura significa que os casos difíceis foram os descartados — e os difíceis são
  justamente sigilo, prazo e concorrência.
- Casos que mudam de mecanismo mas não de critério: `AC-2-03`/`AC-2-04` (rate limit
  do Auth), `AC-2-09` (deixa de valer com a recuperação de senha), `PR-3-11` (passa a
  medir leituras) e `PP-10-11` (lock em documento).
