Projeto-Portaria/prompts/FASE-9-hardening.md

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