prompt inicial do projeto

prompts/FASE-9-hardening.md

@@ -0,0 +1,126 @@
+# FASE 9 — Hardening e produção
+
+## Objetivo
+
+Provar que o sistema aguenta o mundo real: testes ponta a ponta, carga no SFU, injeção de falhas, revisão de segurança e deploy documentado.
+
+## Pré-requisitos
+
+FASES 0–8 concluídas. Ler `docs/06-LGPD-E-SEGURANCA.md` §5 e `docs/07-REQUISITOS-DE-CAMPO.md`.
+
+## Tarefas
+
+### 1. Testes ponta a ponta
+
+Playwright para os webs, Maestro para os apps. Cenários obrigatórios:
+
+1. Visita completa: QR → aviso → permissões → foto → unidade → morador atende → autoriza → PIN
+2. Entrega em um toque, resolvida pela notificação, em menos de 10s
+3. Escalonamento completo: ninguém atende → outros moradores → fila → operador → autorizado
+4. Recado: ninguém atende, sem módulo de operador → grava → morador resolve depois
+5. Unidade inexistente: visita criada, ninguém notificado, expira — **resposta indistinguível de unidade válida**
+6. Fora do geofence: bloqueado com mensagem acionável
+7. Quiet hours: desvia sem tocar em ninguém
+8. Dois moradores respondendo juntos: um vence, o outro vê quem resolveu
+9. LiveKit fora: degrada para áudio, depois foto+texto
+10. Backend reiniciado no meio de uma visita: escalonamento acontece mesmo assim
+
+O cenário 10 é o que valida o padrão de timeouts persistidos. O 5 valida a busca cega.
+
+### 2. Teste de carga
+
+**SFU:** 50 chamadas simultâneas de 2 participantes, medindo banda, CPU e tempo até o primeiro frame. Confronte com o dimensionamento de `05-INFRA-DOCKER.md` §4.
+
+**API:** 100 visitas/minuto sustentadas — muito acima do real (~0,3 req/s), de propósito.
+
+**Fila:** 10 mil jobs agendados para o mesmo instante, verificando que nenhum é perdido ou executado duas vezes.
+
+**Banco:** tabela de auditoria com 1 milhão de visitas; a tela do admin precisa continuar fluida.
+
+### 3. Injeção de falhas
+
+Derrube cada peça, uma por vez, com uma visita em andamento, e verifique o comportamento:
+
+| Peça derrubada | Comportamento esperado |
+|---|---|
+| LiveKit | Degrada para áudio → foto+texto → operador |
+| Redis | WebSocket degrada para polling; fila continua (está no Postgres) |
+| MinIO | Visita prossegue sem foto, com aviso; upload entra em retry |
+| FCM | WebSocket assume se o app está aberto; falha vai para o dashboard |
+| Uma réplica do backend | Outra assume; jobs pendentes executam |
+| Postgres (breve) | Erro claro ao visitante e contingência física acionada |
+
+**Teste do relógio:** atrase o relógio de uma réplica em 30s e confirme que ShedLock não permite execução dupla.
+
+### 4. Revisão de segurança
+
+Percorra o modelo de ameaças de `06-LGPD-E-SEGURANCA.md` §5 e prove cada mitigação:
+
+- [ ] **A.1 Busca cega** — tempo de resposta constante medido estatisticamente, não no olho. Este é o teste mais importante da fase
+- [ ] **A.2 Geofence** — rejeita fora do raio; GPS falsificado é registrado
+- [ ] **A.3 DoS social** — rate limit e quiet hours funcionam; varredura gera alerta
+- [ ] **A.4 Mídia** — nenhuma URL pública; assinada expira; acesso auditado
+- [ ] **A.5 Auditoria** — `UPDATE`/`DELETE` em `audit_log` falham no banco
+- [ ] **A.6 Tokens** — JWT de visitante não serve para outra visita nem outra portaria
+- [ ] **A.7 QR** — incrementar `qr_version` invalida os códigos antigos
+
+Rode também: `pnpm audit`, `gradle dependencyCheck`, varredura de imagem Docker (Trivy), e headers verificados por observatório de segurança.
+
+**Grep obrigatório:** nenhuma biblioteca de detecção ou reconhecimento facial em `build.gradle.kts` ou `package.json`. A tentação aparece disfarçada de UX ("só para enquadrar o rosto") e tem consequência jurídica direta.
+
+### 5. Checklist de produção
+
+**Infraestrutura**
+- [ ] Faixa UDP 50000–60000 aberta (esquecer isso conecta a chamada e nunca mostra vídeo)
+- [ ] TLS válido e renovação automática testada
+- [ ] Backup automático com **restore testado e cronometrado**
+- [ ] Segredos fora do repositório e fora das imagens
+- [ ] Healthchecks respondendo em todos os serviços
+- [ ] Alertas chegando em canal monitorado de verdade
+
+**Aplicação**
+- [ ] Perfil `prod`, sem stack trace exposto
+- [ ] Rate limits ativos
+- [ ] CORS restrito aos domínios reais
+- [ ] Logs sem dado pessoal (nome, foto, coordenada) — **verificar linha a linha**
+- [ ] Migrations aplicadas em ordem em banco limpo
+
+**Apps**
+- [ ] Builds de release assinados
+- [ ] Testados em dispositivo físico, Android e iOS
+- [ ] Ficha de privacidade da App Store e do Google Play preenchida
+- [ ] Justificativa de VoIP documentada para a App Review
+- [ ] Crash reporting **sem PII**
+
+**Conformidade** — checklist completo de `06-LGPD-E-SEGURANCA.md` §9.
+
+**Campo** — checklist de ativação de `07-REQUISITOS-DE-CAMPO.md` §2 para o condomínio piloto.
+
+### 6. Deploy
+
+`docs/anexos/deploy.md` com provisionamento, primeiro deploy, atualização sem downtime (rolling com healthcheck), rollback, aplicação de migration com dado em produção, e o procedimento de crescer para HA.
+
+### 7. Piloto assistido
+
+Antes da ativação definitiva, **duas semanas com o módulo de operador ligado**, monitoramento diário e reunião semanal com o síndico.
+
+O que se mede: taxa real de atendimento, tempo médio de resolução, abandono de entregador, incidentes, e feedback qualitativo de moradores e entregadores.
+
+**É esse número — não a expectativa comercial — que define se o condomínio fica no plano Autônomo ou no Assistido.**
+
+## Critérios de aceite
+
+- [ ] Os 10 cenários E2E passam em CI
+- [ ] Carga do SFU dentro do dimensionamento previsto
+- [ ] Toda injeção de falha se comporta como na tabela
+- [ ] Todas as mitigações do modelo de ameaças verificadas
+- [ ] Busca cega com tempo constante comprovado estatisticamente
+- [ ] Checklist de produção 100% marcado
+- [ ] Restore de backup executado e cronometrado
+- [ ] Runbooks testados por alguém que não os escreveu
+- [ ] Piloto de duas semanas concluído com métricas coletadas
+
+## Não faça nesta fase
+
+- Novas funcionalidades — se aparecer necessidade, vira v2
+- Otimização sem métrica que a justifique