Relatório de Arquitetura: Persistência de Estado Distribuído (BPMN/DMN)

Este relatório analisa a viabilidade e o design arquitetural para o armazenamento do ExecutionToken (Estado da Rede de Petri) do motor gbr_bpm, visando a escalabilidade para o ecossistema GBR (Sistema Operacional Distribuído P2P).

A análise foi fundamentada nos documentos internos do projeto (00-Brainstorm/README.md) e nos seguintes trabalhos científicos: 1. Decentralized Control: A Novel Form of Interorganizational Workflow Interoperability (Martinez et al.) 2. Horizontal Scaling of Transaction-Creating Machines (Delzer et al.) 3. Genet: A Quickly Scalable Fat-Tree Overlay for Personal Volunteer Computing using WebRTC (Lavoie et al.)

1. O Desafio do Estado Distribuído no BPMN

Em um fluxo de trabalho orquestrado por um único Agente, o estado (em qual "caixinha" do fluxograma o processo está) pode residir perfeitamente na memória RAM (gbr_ets) ou em um log de disco local (gdisk_log). No entanto, no nosso objetivo final (Fase Final), múltiplos Agentes (Nós) colaboram em uma rede P2P (via WebRTC/Fat-tree) para resolver o mesmo processo. O grande problema técnico aqui é o *Consenso de Estado e Duplo Gasto de Tarefa: Se dois Agentes estão no mesmo *Gateway (Decisão), como garantir que apenas um assuma a tarefa seguinte sem que haja um servidor mestre central ditando as regras?

2. Análise dos Modelos Científicos

A Abordagem Blockchain (Smart Contracts) O paper de Decentralized Control propõe o uso do Ethereum. O BPMN é compilado em um Smart Contract, e cada transição de estado da ficha (ExecutionToken) é uma transação minerada na rede. - *Vantagem:* Confiança zero (Trustless) e rastreabilidade total. - *Problema (Horizontal Scaling):* O paper de Horizontal Scaling expõe a ferida dessa abordagem. Blockchains sofrem gargalos severos de TPS (Transactions Per Second) e gerenciamento de Nonces. Para um Sistema Operacional de Agentes disparando milhares de micro-decisões por minuto, uma blockchain tradicional como o Ethereum seria lenta e financeiramente inviável (Gas fees).

A Abordagem ScyllaDB + Paxos LWT (A Solução Proposta) Conforme idealizado no Brainstorm do GBR, usar o *ScyllaDB* contorna o gargalo da blockchain. ScyllaDB é um banco NoSQL de altíssima performance (milhões de TPS). Mas como garantir o consenso sem blockchain? Através das *Lightweight Transactions (LWT)* baseadas no algoritmo Paxos. - *O Design:* A transição de estado do BPMN é tratada como um Event Sourcing. Quando um Agente tenta mover a ficha da Tarefa A para a Tarefa B, ele executa um UPDATE state SET token = B WHERE token = A IF token = A (Compare and Set). O algoritmo Paxos do ScyllaDB garante atomicidade linear. Se outro Agente tentou no mesmo milissegundo, a transação falha para ele. - *Rastreabilidade Auditação:* Diferente de uma Blockchain permissonless, um cluster ScyllaDB seria mantido por "Oráculos" da rede (Nós Enterprise/PaaS).

A Malha de Comunicação (Genet Fat-Tree P2P) Para que os Agentes conversem sem depender de endpoints centralizados na AWS, a comunicação M2M (Machine-to-Machine) utilizará o overlay P2P Genet. O paper demonstra que construir uma árvore gorda (Fat-tree) via WebRTC permite escalar milhares de nós na borda (Edge) em segundos, com balanceamento probabilístico. Os eventos de mudança de estado do BPMN e os pacotes de pagamento de tokens (GNU Taler) trafegarão de forma criptografada por estes canais P2P (GBR TUNNEL).

3. O Veredito Arquitetural para a Fase 5 e 6

Etapa Inicial (Fase 5 - Agente Code AI MVP) Neste momento não temos ScyllaDB em produção e queremos estabilizar a lógica do Agente Local. - *Solução Imediata:* O estado do ExecutionToken será armazenado usando gdisk_log (Event Sourcing em disco local no formato Write-Ahead Log). - *Por quê?* Ele simula exatamente o comportamento apêndice-único (append-only) que usaremos no futuro. Se o Agente "morrer" no meio de uma tarefa de compilação, ao reiniciar, ele lê o gdisk_log, repõe a ficha na rede de Petri e continua de onde parou.

Etapa Final (Fase 6 - SO Distribuído) - *Motor de Estado Global:* O gdisk_log é substituído por conectores para o ScyllaDB LWT. - *Malha de Execução:* O Agente passa a publicar e consumir diagramas BPMN numa malha P2P. A tecnologia base será a especificação *libp2p, utilizando o recurso de *multistream para multiplexar diferentes transportes. Dessa forma, podemos ter WebRTC (implementando a topologia rápida Genet Fat-Tree para Agentes Web/Edge) rodando simultaneamente com túneis TCP/QUIC para Oráculos Enterprise mais robustos. Outros Agentes da borda "puxam" as tarefas do ScyllaDB, executam o LLM (se necessário) e fazem o Commit do novo estado. - *Pagamento:* Usando a integração GNU Taler (Blind Signatures), a privacidade de quem realizou a tarefa é garantida, mantendo o ScyllaDB focado apenas na veracidade da transição matemática do BPMN.

4. Atualização da Estratégia Híbrida (Comandos Slash) Para atender à necessidade de ter o Agente dinâmico, implementaremos um roteador de intenção (Intent Router) no Orquestrador: 1. *Padrão (Opção A):* O Agente reconhece a requisição e carrega um .bpmn estático da sua memória semântica local. 2. *Dinâmico (Opção B):* Ao interceptar o comando /flow ou /bpmn, o Agente usará o LLM para *escrever* o arquivo BPMN/DMN em memória na hora (usando a ferramenta WriteFile), e em seguida alimentará a máquina gbr_bpm com esta AST recém-criada para a execução determinística em terreno desconhecido.