GBR: ADR-002 Motor de Processos de Negócio (gbr_bpm) baseado em Topologia Algébrica e Efeitos Gerenciados

• *Status:* Aceito
• *Data:* 2026-05-01

*Contexto:*

Sistemas corporativos de monitoramento e automação (como o projeto "Horus Falcon 2.0") tradicionalmente codificam regras de negócio ("Triggers") de forma imperativa (ex: se CPU > 90 então envie e-mail). Isso gera alto acoplamento, dificuldade de testes isolados e vulnerabilidades a condições de corrida (Race Conditions) quando milhões de eventos são avaliados simultaneamente. Precisávamos de um motor (BPE) capaz de orquestrar tarefas (Serviços Externos, LLMs, Alertas) com previsibilidade matemática e zero efeitos colaterais indesejados.

*Decisão:*

1. *Topologia Algébrica e Redes de Petri:* Adoção de Tipos de Dados Algébricos (ADTs) no pacote gbr_bpm. Processos de negócio (BPMN) são modelados como Grafos Imutáveis (ProcessDef). O estado de execução é representado por um ExecutionToken.
2. *Cálculo Lambda (AST):* A avaliação de condições de roteamento (ex: Losangos de Decisão/Gateways) não utiliza avaliação de strings imperativa (eval()). Foi implementado um interpretador próprio de Árvore Sintática Abstrata (AST) que realiza a redução lógico-matemática injetando as variáveis de telemetria diretamente no contexto.
3. *Efeitos Gerenciados (Arquitetura Hexagonal Funcional):* A função de transição de estado da máquina (machine.step) é matematicamente pura. Ela não executa chamadas de rede ou gravações em disco. Em vez disso, ela retorna o novo ExecutionToken acompanhado de uma lista de Intenções/Efeitos (Effect, ex: TriggerAlert). O Ator OTP externo (casca imperativa) é quem recebe esses Efeitos e "suja as mãos" no mundo real.

*Consequências:*

• *Positivas:* Previsibilidade absoluta (Zero Race Conditions na avaliação de regras). Possibilidade de testar processos de negócio complexos inteiros apenas verificando as listas de Effects resultantes, sem a necessidade de Mocks de rede ou banco de dados. Preparação do terreno para a futura implementação de IAs executando inferência e gerando fluxogramas sem risco de injeção de código arbitrário.
• *Negativas/Riscos:* Exige que a modelagem dos processos seja feita em uma linguagem estritamente tipada antes de ser traduzida para os Atores OTP. A equipe precisará desenvolver parsers (ex: XML do Camunda -> AST Gleam) para facilitar a adoção por usuários finais que não programam em Gleam.