prompt inicial do projeto completo

docs/06-LGPD-E-SEGURANCA.md

@@ -93,6 +93,7 @@ Prazos são configuráveis por tenant, com **teto** definido pela plataforma. Um
 - Visita criada mesmo com `unit_id` nulo, preservando `unit_input`
 - Resposta idêntica em corpo, código e headers
 - **Tempo de resposta constante** (delay artificial iguala os caminhos — sem isso o ataque vira timing attack)
+- **Linha do tempo de estados idêntica** — a visita-sombra percorre os mesmos estados nos mesmos tempos, sem notificar ninguém (`03-FLUXOS-E-CONTRATOS.md` §2). Sem isso, o atacante distingue os casos observando a sequência no WebSocket, e o tempo constante da resposta HTTP não protege nada
 - Nome do morador nunca aparece antes do atendimento
 - Rate limit por IP e por dispositivo, com bloqueio progressivo
 
@@ -128,9 +129,11 @@ REVOKE UPDATE, DELETE ON audit_log FROM portaria_app;
 
 Nem a aplicação comprometida altera o log. Somado ao `sha256` da mídia, isso é o que dá valor probatório ao registro.
 
+**Só funciona se a aplicação não for dona do schema** — dono ignora `REVOKE` e RLS. A aplicação conecta como `portaria_app`; o Flyway, como `portaria` (dono). Ver `02-MODELO-DE-DADOS.md` §8.
+
 ### A.6 — Roubo de token
 
-**Mitigação:** JWT de visitante com 15 min, escopo de uma visita, atado ao `gateId` e ao IP de origem. Refresh do morador no Keystore/Keychain com biometria de dispositivo. Rotação de refresh token e revogação por dispositivo no admin.
+**Mitigação:** JWT de visitante com 15 min, escopo de uma visita, atado ao `gateId` e à sessão — **não ao IP de origem**: IP de celular muda no meio da sessão (troca de torre, CGNAT) e a amarração derrubaria visitante legítimo no meio do fluxo. A defesa é a posse do token somada à validade curta e ao escopo mínimo. Refresh do morador no Keystore/Keychain com biometria de dispositivo. Rotação de refresh token e revogação por dispositivo no admin.
 
 ### A.7 — QR vazado ou clonado