[hbgit]

Refs #81

Resumo

A coordenação (o coordenador, só para ACS da própria UBS) ou o administrador pode pedir pelo backoffice a limpeza remota de um aparelho do ACS. O aparelho perde o acesso na hora. No próximo contato com o servidor, ele apaga tudo o que o SinalACS guarda nele, inclusive visitas não enviadas, troca a chave do SQLCipher e o próprio id de instalação, e confirma ao servidor. Pedido, entrega e confirmação ficam na trilha de auditoria. A chave do cache passa a ser trocada por evento (CRIPTO-APP-CACHE): no wipe remoto e no "Limpar este aparelho".

O certificado de cliente MQTT por aparelho (STRIDE-S) não está aqui. Ele depende de uma biblioteca X.509 fora de spec/stack.md e de uma PKI de produção, e foi para a #94. Por isso este PR não fecha a #81, e o R3 continua parcial na auditoria do PRD.

Plano: docs/superpowers/plans/2026-10-17-issue-81-wipe-remoto-e-rotacao-de-chave.md (D1–D8).

Backend

• Tabela nova device_wipe_orders, uma linha por deviceId (índice único). Migração 20261017171640323.
• admin.acsDevices / admin.orderDeviceWipe:
  • Escopo por papel e UBS, como na admin: gestão de ACS e microáreas (cadastro, vínculo, desativação) e reset de MFA #43. Fora do escopo e inexistente recebem a mesma recusa, com uma linha denied gravada antes.
  • O pedido revoga, na mesma transação, os refresh tokens e os tokens de envio daquele aparelho, de todos os donos (D5).
  • Repetir o pedido é idempotente e devolve alreadyOrdered.
  • Não há cancelamento (D4).
• devices.pendingWipe / devices.confirmWipe:
  • São públicos e só devolvem orderId ou nada.
  • A marca de entrega ou de confirmação e a linha de auditoria gravam numa transação só.
• DeviceWipeRequiredException em auth.loginInstitutional, auth.refreshSession e visits.syncDeferred. A checagem roda antes da senha ou da renovação, e um id que já foi marcado fica marcado para sempre.

App do ACS

• VisitDatabase.destroy(): fecha o banco e apaga o arquivo, os sidecars, a cópia .recuperado e a chave. É exclusivo contra open() concorrente.
• RemoteWipeCoordinator:
  • Uma limpeza por vez (single-flight). Antes de apagar, grava um diário (erasing/erased), e só apaga o diário depois que o servidor confirma.
  • Confirma com o id antigo.
  • Um diário preso em erasing não apaga de novo quando a limpeza daquele pedido já terminou.
• Gatilhos: na partida (antes de qualquer abertura do banco), na volta do segundo plano, na volta da rede e na renovação.
• Desmontagem do painel durante o wipe:
  • As filas, o pull e o cache da microárea são selados, para que nenhuma gravação atrasada recrie o banco com dados.
  • Os alertas não são confirmados nem concluídos (INV-03).
  • Com o app em segundo plano, a limpeza não espera frame.
• Tela device_wiped ("Aparelho limpo pela coordenação"), fora do bloqueio por inatividade.
• O "Limpar este aparelho" continua recusando quando há visita não enviada (WipeBlocked) e agora também troca a chave.

Admin

• No cartão do ACS, o botão "Aparelhos" abre a lista de aparelhos com estado e último acesso.
• "Limpar remotamente": escolha do motivo (Perdido, Roubado, Substituído), depois uma confirmação destrutiva que avisa que as visitas não enviadas serão apagadas.

Provas

• Backend dart test: 1438 passando.
• ACS flutter test: 685 passando; flutter analyze limpo.
• Admin flutter test: 473 passando.
• scripts/qa/ci_invariants.sh: ok.
• scripts/qa/acs_remote_wipe_e2e.sh no emulator-5554 (API 36), contra o banco de teste. O teste deixa uma visita pendente com o painel aberto; o coordenador pede a limpeza; o app, ao voltar do segundo plano, mostra a tela de aparelho limpo. No aparelho: o arquivo do banco sumiu, a chave foi trocada, os tokens de envio foram apagados e o id é novo. O ACS entra de novo com o id novo. No banco, as 11 checagens passaram (o pedido foi entregue e confirmado, nenhum token vivo ficou com o id antigo, as três linhas de trilha existem, a visita não chegou ao servidor) e audit_chain_check saiu íntegro. Log em docs/superpowers/plans/2026-10-17-issue-81-e2e.log.
• Regressões: acs_full_e2e.sh (6/6) e admin_acs_gestao_e2e.sh (3/3). O full_journey_e2e.dart foi ajustado à rotação da chave: agora confere que a conexão foi fechada e que a chave mudou, e conta as tabelas num banco reaberto.

Limites conhecidos (detalhe no PROGRESS.md, seção #81)

• Um aparelho que nunca volta a ficar online não é alcançado, e o JWT vivo dura até 15 min depois do pedido (D3).
• "Aparelho limpo" no admin é o que o aparelho afirma, não uma prova: quem tem o deviceId consegue confirmar sem limpar nada. O acesso continua bloqueado.
• O pedido apaga dados de todos os donos daquele aparelho, inclusive ACS de outra UBS (D5). Os dois métodos públicos não têm limite de taxa.
• Só está provado no emulador API 36. API 24–29 e aparelho físico seguem sem prova.
• Falhas que já existiam antes deste branch: o teste de aparelho "banco v6 … migra para v7" (espera user_version 7, mas o schema é 8) e a linha do RNF04 no cobertura_prd.py --final.