Alertas e Ações

Preview — funcionalidade em desenvolvimento. Comportamento, telas e contratos podem mudar sem aviso entre versões.

A triagem já sabe o que está errado em cada processo — quem regra disparou, com que urgência, com que evidência e o que fazer. Antes, esse conhecimento ficava preso dentro do laudo de um processo específico, gravado como JSON na propriedade analisesPorRegra. Para saber "o que precisa da minha atenção hoje", só abrindo laudo por laudo.

A tela Alertas e Ações (menu → Investigação → Alertas) é esse mesmo conhecimento publicado como fila consultável.

O que é um alerta

Um alerta é uma regra que apontou irregularidade em um processo. Ele não é criado à mão: é derivado do laudo. Não existe tela nem endpoint de criação, e isso é deliberado — um caminho de criação manual abriria uma segunda fonte da verdade, que divergiria da primeira no primeiro reprocessamento.

Só análise com anomalia vira alerta. "Conforme" e "sem contexto" continuam no laudo e não entram na fila: se entrassem, cada triagem em lote despejaria milhares de registros que não pedem ação, e a lista deixaria de significar "isto precisa de alguém".

Severidade

Vem da urgência que a própria triagem atribuiu, não de uma segunda escala:

Reaproveitar a escala existente evita o sintoma clássico de duas escalas para o mesmo julgamento: um alerta "alto" sobre uma análise de urgência baixa, sem que ninguém consiga dizer qual das duas está certa.

O ciclo de vida

Descartar é a única transição que tira um achado da fila sem resolvê-lo. Por isso é a única que exige justificativa: sem ela, a fila vira lixeira silenciosa e ninguém consegue reconstruir por que aquele alerta sumiu. O botão fica desabilitado enquanto o campo estiver vazio, e o servidor recusa a transição mesmo que alguém chame a API diretamente.

Reprocessar não desfaz o seu trabalho

Uma triagem é reprocessada com frequência — pelo botão "Reprocessar só os erros", pela troca do modelo de embedding, por edição de regra. A identidade do alerta é (processo, regra, versão da regra), e a reprojeção separa criação de atualização: ela atualiza os campos derivados do laudo e nunca devolve para "Novo" um alerta que alguém já moveu.

A versão da regra faz parte da identidade de propósito: regra editada é outra regra do ponto de vista do achado. O alerta antigo descreve o que a versão anterior encontrou, e sobrescrevê-lo apagaria histórico.

A aba Ações

Cada transição vira um registro próprio, com quem moveu, quando, de qual estado para qual, e a justificativa.

Isso existe porque guardar só o estado corrente responde "onde está o alerta", e a pergunta que a auditoria faz é outra: "quem o moveu, quando e por quê". Sem o registro, a justificativa exigida no descarte durava até a transição seguinte, que a sobrescrevia — e a regra que a torna obrigatória existe justamente para que ela seja recuperável depois.

Alertas dos processos triados ANTES

A projeção roda no caminho de escrita da triagem, então cobre o que for triado daí em diante. Todo laudo anterior continua com os achados presos como JSON.

Um administrador reprojeta o acervo inteiro do contexto pela ação Reprojetar alertas do contexto, na barra acima da lista. Ela só aparece para quem tem a permissão de backfill — quem não a tem não vê o botão.

A ação pede confirmação (ela varre todas as triagens já concluídas do contexto) e, ao terminar, mostra os números: quantos alertas foram projetados, quantos laudos foram lidos e quantos não puderam ser lidos. Para automação, a mesma operação está na referência de endpoints, na seção "Triagem & Regras".

A operação reprojeta, não recalcula: não há LLM nem embedding envolvidos, porque a análise já foi feita e está gravada. Recalcular seria caro, lento e — pior — poderia produzir um veredito diferente do laudo que o usuário já leu.

Ela é idempotente: vale a mesma chave e a mesma separação entre criar e atualizar, então rodar duas vezes não duplica nem reverte estado. A resposta traz as contagens (laudosLidos, alertasProjetados, laudosSemAnomalia, laudosIlegiveis, duracaoMs) — nunca só "ok". Backfill que responde sucesso sem número é indistinguível de backfill que não fez nada.

Permissões

VIEW é separado de MANAGE porque ver a fila é trabalho de analista e mover a fila é decisão — quem lê nem sempre é quem decide. E BACKFILL é separado de MANAGE porque varre todos os laudos do contexto: é manutenção de plataforma, não operação de fila.

ALERT_VIEW e ALERT_MANAGE estão nas roles padrão de quem dispara triagem. ALERT_BACKFILL é sensível e fica apenas com administradores.

Onde os dados moram

Os alertas vivem no banco Neo4j do contexto, junto do laudo que os originou — não em um banco de sistema. Na primeira projeção de cada contexto, o serviço cria a constraint de identidade e os índices de status e severidade.

Isso não é só integridade: a chave é composta, e sem índice o MERGE percorre o label inteiro a cada regra de cada processo. Numa triagem em lote o custo é quadrático — funciona na demonstração e mata a carga real no meio, depois de horas, sem dizer o motivo.

Limitação conhecida

O protótipo do redesign desenhava, na aba Ações, um formulário para criar vínculos entre entidades do grafo (RELATED_TO, SAME_AS, MEMBER_OF, DERIVED_FROM) e para solicitar documento ou encaminhar para análise.

Isso não está implementado. Exige duas capacidades que hoje não existem: busca de entidades pela tela e um caminho de escrita de relacionamento a partir da UI. A aba Ações entrega o que a plataforma sabe registrar de verdade — as transições de estado, com autor e justificativa — em vez de um formulário que não gravaria nada.