# 4 de novembro de 2026: subcondições, histórico de alertas e resposta 503

Esta atualização inclui subcondições e o modo **Só a primeira** nas regras de evento, além de um novo tipo de evento com o histórico de alertas.

## Subcondições

Uma condição de regra de evento passa a admitir subcondições, em até 3 níveis abaixo da regra. As subcondições só são avaliadas quando a expressão da condição é atendida. A nova ação avulsa, sem expressão, é executada sempre que a avaliação chegar até ela. As regras de pagamento continuam sem subcondições.

Por exemplo, a subcondição `valor_alto`, dentro da condição `cartao_estrangeiro`, testa `$amount > 1000` apenas nos eventos com cartão estrangeiro. Veja [Subcondições](/pt/rules/conditions/#subcondições).

## Modo Só a primeira e Senão

O novo **Modo** vale para a regra e para cada condição com subcondições. Em **Todas**, cada condição atendida executa as suas ações. Em **Só a primeira**, a avaliação para na primeira condição atendida. Um nível **Só a primeira** admite um **Senão** no final. O editor avisa quando uma linha desse nível pode nunca ser avaliada.

Por exemplo, as condições `cliente_bloqueado` e `revisao_manual`, seguidas de um **Senão**, produzem uma única decisão por evento. Veja [Modo de avaliação](/pt/rules/conditions/#modo-de-avaliação).

## Comparação e simulação em árvore

A comparação de versões apresenta a regra como uma árvore numerada, com as etiquetas **Adicionada**, **Alterada**, **Removida** e **Reordenada** em cada condição e ação que mudou. A simulação marca as linhas que a regra não avaliou. Na página da regra, a contagem de condições atendidas passa a desconsiderar as execuções em que a condição não foi avaliada.

Veja [Comparação e publicação](/pt/rules/versioning/#comparação-e-publicação) e [Simulação](/pt/rules/simulation/#resultado).

## Tipo de evento de alertas

Todas as contas passam a ter o tipo de evento `_alert`, com um evento a cada abertura e a cada encerramento de alerta dos monitoramentos. O histórico de alertas pode ser consultado em **Explorar**, medido por métricas e acompanhado por monitoramentos, como os demais eventos. O histórico começa nesta atualização e permanece depois que o alerta deixa de ser exibido.

Por exemplo, selecione `_alert` em **Explorar**, no menu **Mais**, e divida por **Monitoramento** para identificar os monitoramentos que mais abriram alertas no mês. Veja [Tipo de evento de alertas](/pt/events/event_types/#tipo-de-evento-de-alertas).

## Resposta 503 na API de eventos

Quando uma indisponibilidade interna impede a regra de decidir, `POST /events` passa a responder `503`, com o cabeçalho `Retry-After`, sem registrar o evento. Reenvie o evento depois do intervalo indicado no cabeçalho, sem risco de duplicidade.

Veja [Erros](/pt/api/technical-integration/#erros).

## Tor e provedores de nuvem no tipo de IP

O enriquecimento de endereço IP passa a identificar os nós de saída da rede Tor (exit relays), com o valor `tor` no tipo do IP, apenas em IPv4. Os endereços de Google Cloud, Oracle Cloud, DigitalOcean e Linode passam a receber o valor `hosting`, como os da AWS.

Veja [Dados do endereço IP](/pt/rules/actions/enrich/#dados-do-endereço-ip).

## Subcondições pelo agente

O agente de IA conectado via MCP passa a ler e a montar regras com subcondições, ações avulsas, **Senão** e o modo de cada nível. Na simulação pelo agente, cada linha não avaliada informa o motivo. O agente também lista os itens de um campo de lista e inclui, altera ou remove itens em lote.

Peça, por exemplo: "No rascunho da regra de cadastros da conta loja-br, coloque as condições de e-mail descartável dentro de uma condição `email_suspeito`, no modo Só a primeira." Veja [Agentes](/pt/admin/agent/#operações).

## Outras melhorias

- **Regras**: o limite de linhas por regra passa de 30 para 50. Condições, ações avulsas e **Senão** contam no limite. Veja [Limites](/pt/limits/#regras-e-listas).