GBR: Requisitos do Motor de Roteamento P2P (gbrmonitor & gbrets)

*Requisitos Ubíquos (Ubiquitous Requirements)* * *UBQ-01:* O sistema de ingestão de telemetria deve ser agnóstico quanto à fonte ou conteúdo do payload, adotando a arquitetura Hexagonal (Ports and Adapters) com a injeção da lógica de negócio através de Funções Callback Tipadas genéricas, não incorporando regras de mercado ao módulo de rede base.

*Requisitos Orientados a Eventos (Event-Driven Requirements)* * *EVD-01:* Quando a borda (Gateway P2P) ingerir um evento para o gbr_monitor, o sistema deve primeiramente gravá-lo no gbr_disk_log em disco (Write-Ahead Log) via async_log antes de retorná-lo, atuando como backpressure para evitar travamentos de memória. * *EVD-02:* Quando o Roteador pesquisar na tabela ETS e verificar que não existe a chave (Ator alvo ausente), o sistema deve encaminhar a solicitação de forma assíncrona ao Ator Gerenciador (Manager) encarregado da instanciação.

*Requisitos de Estado (State-Driven Requirements)* * *STD-01:* Enquanto o sistema não localizar o Ator no ETS, e a solicitação estiver em processamento pelo Manager, os novos eventos subsequentes do mesmo alvo que impactarem o Roteador deverão ser descartados com erro (Cold-start penalty aceitável) até a transição de estado da tabela ocorrer.

*Requisitos de Comportamento Indesejado (Unwanted Behavior Requirements)* * *UNW-01:* Se a infraestrutura apresentar erros catastróficos no motor do cliente e o Ator alvo for morto pelo Supervisor (Processo Crash), o Supervisor deve ser provido das referências essenciais (MFA) necessárias para reler e repopular a tabela ETS durante o ciclo de recriação. * *UNW-02:* Se uma tentativa de inserção via gbr_ets ocorrer sem a identificação nativa da BEAM correspondente ao PID (Subject), a interface da biblioteca FFI (Gleam -> Erlang) deve emitir uma quebra preventiva e não gravar a memória do banco subjacente em C.