[hbgit]

Fecha #88. Plano: docs/superpowers/plans/2026-10-27-issue-88-ack-idempotente-acsid.md.

O que mudou

• OrmAlertStore.acknowledge decide o desfecho pelo número de linhas de um UPDATE alerts … WHERE status IN ('pending','escalated') RETURNING …, dentro da transação do ACK, e não por um SELECT anterior. Uma linha → acknowledged (só esse ACK grava acsId, receivedAt, acknowledgedAt). Zero linhas → SELECT … FOR UPDATE decide alreadyAcknowledged/alreadyResolved (ou null fora do território) sem escrever em alerts.
• alerts.acsId passa a ser quem confirmou primeiro (era o último ACS a confirmar).
• A entrega em alert_deliveries vira INSERT … ON CONFLICT ("alertId","acsId") DO NOTHING: a reentrega é caso esperado decidido pelo índice único do par, sem leitura prévia. O segundo ACS entra com a própria linha.
• Resposta ao app, regras de transição de status e result da trilha (ack_already_acknowledged/ack_already_resolved, desde a ACK de alerta já concluído devolve "acknowledged" e o botão de concluir reaparece (RF05) #86) inalterados. Nenhuma linha de auditoria é editada ou apagada; nenhuma migração.

Matriz (status lido × ACK)

status lido	mesmo ACS	outro ACS	escreve alerts?
pending / escalated	acknowledged, grava acsId	idem	sim
acknowledged	alreadyAcknowledged	alreadyAcknowledged, acsId intacto, entrega do segundo registrada	não
resolved	alreadyResolved	alreadyResolved, acsId/resolvedAt intactos, entrega registrada	não

Decisão (#88, comentário de 2026-10-27)

Opção 1: registrar o ACK do segundo ACS (entrega + trilha com o userId dele) e manter a resposta. O aviso ao app ("Outro ACS já confirmou") e a coluna resolvedBy são a #111. Sem correção retroativa dos dados (consulta de reconstrução por alert_deliveries no PROGRESS.md).

Os cinco pontos do dono

1. ON CONFLICT sobre o par (alertId, acsId) — índice confirmado na migração e pelo teste o índice único de alert_deliveries é sobre o par (alertId, acsId) (#88); a reentrega não duplica e o segundo ACS entra.
2. Desfecho pelo rowcount do UPDATE condicional, na mesma transação da entrega — matriz #88, ACK repetido pelo mesmo ACS não escreve alerts, corrida dois ACS confirmam o mesmo pendente (5 rodadas; trilha na ordem da trava; os dois devolvem o carimbo do vencedor).
3. Consulta que distingue reentrega própria de ACK de outro ACS (audit_logs.userId × alerts.acsId) — backend/CLAUDE.md, com a observação sobre o CSV da admin: trilha de auditoria completa (paginação, filtros, busca, exportação e verificação da cadeia) #45.
4. ack_already_resolved não oferece "Concluir" — apps/acs/test/alert_resolve_test.dart (já da ACK de alerta já concluído devolve "acknowledged" e o botão de concluir reaparece (RF05) #86) e ./scripts/qa/acs_ack_concluido_e2e.sh reexecutado no emulador, verde.
5. resolve não toca acsId — resolve por outro ACS não toca acsId (#88, regressão); a trilha é o único registro de quem concluiu (resolvedBy na ACK de um segundo ACS: avisar o app que outro ACS já confirmou (continuação da #88) #111).

Provas

• Backend: dart test -j 1 → 1557 pass; test/integration/alert_escalation_store_test.dart 29 (grupo #86 + corrida); test/unit/red_alert_service_test.dart (dois ACS no serviço); red_alert_discard_paths_test.dart (inventário de escritores de alerts atualizado).
• ACS: flutter analyze limpo, flutter test → 760 pass (nada mudou no app).
• Emulador (emulator-5554, API 36): ./scripts/qa/acs_ack_segundo_acs_e2e.sh (novo, com guarda _test.sh) falhou antes da correção em acsId segue o ACS A (docs/superpowers/plans/2026-10-27-issue-88-reproducao.log) e passou depois (…-issue-88-e2e.log: acsId do A, acknowledgedAt intacto, 2 entregas, 1 ack_already_acknowledged do B, 0 acknowledged, 0 no outbox).

Fora deste PR

• ACK de um segundo ACS: avisar o app que outro ACS já confirmou (continuação da #88) #111: acknowledgedByOther na resposta e aviso no app; resolvedBy.
• O ACK por MQTT segue sem autenticação (admin: ações operacionais sobre alertas (escalonar, anotar) e atualização em tempo real #44): "primeiro ACS" pelo broker é o que o payload disser.