GBR: Requisitos do Teletransporte e Roteamento Universal (P2P Mesh & Tunnel)

*Requisitos Ubíquos (Ubiquitous Requirements)*

*UBQ-01:* O framework de base de rede (gbr_p2p) deve ser estritamente agnóstico, de modo que lógicas de chat, telemetria, ou tunelamento Reverso não estejam presentes nas suas bibliotecas core, mas providenciadas através de submissão de handlers (register_protocol).
*UBQ-02:* A análise de vetores de rede padronizados (Multiaddrs) deve proibir a utilização de expressões regulares e utilizar rotinas Puras e Tail-Recursive para mitigar gargalos no agendador Erlang (Scheduler Starvation).

*Requisitos Orientados a Eventos (Event-Driven Requirements)*

*EVD-01:* Quando a Máquina BPE transacionar um Fato que defina o Efeito OpenReverseTunnel, o Gateway (gbr_monitor) deve invocar sua tabela OTP interna para recuperar a conexão P2P viva subjacente do alvo, abrir a porta solicitada na interface local com spawn assíncrono, e vincular a escuta TCP à comunicação Yamux (piper_bridge).
*EVD-02:* Quando um agente remoto se interconecta no Host via negociação Multistream, o seletor subjacente deve analisar os bytes iniciais identificando o nome estrito do protocolo (ex: /horus/telemetry/1.0.0) e delegar a continuidade do tráfego ao Actor registrado no ETS correspondente de maneira Lock-free.

*Requisitos Orientados a Estado (State-Driven Requirements)*

*STD-01:* Enquanto o Daemon Horus (falconctl start) estiver retido em seu loop operacional infinito (sleep_forever), a malha P2P deverá manter os fluxos Heartbeat e as atualizações na Tabela de Roteamento Kademlia de forma silenciosa e resiliente a quebras parciais.
*STD-02:* Enquanto a conexão de telemetria falhar em seu protocolo formal por incompatibilidade léxica dos tipos (como Integers vindos do ambiente PowerShell mapeados como Floats no DTO), o decodificador Ingress JSON deverá normalizar coercivamente as topologias numéricas de inteiros para precisão dupla, não impedindo a aprovação do roteamento na porta gbr_p2p.

*Requisitos de Funcionalidades Opcionais / Futuras (Optional Feature Requirements)*

*OPT-01:* No momento da instanciação (Bootstrap), se houverem Bootstrap Nodes pré-configurados (Ex: instâncias de rastreio em GKE via Kademlia), o nó da borda deverá invocar imediatamente o comando RPC FIND_NODE utilizando a sua própria chave pública local para estimular as tabelas de roteamento geograficamente próximas a repovoarem as entradas K-Bucket.
*OPT-02:* O sistema poderá incorporar futuramente um módulo para orquestração semântica remota, na qual LLMs rodando no GKE possam formular Scripts Reativos, transmiti-los via a malha P2P agnóstica para a Borda e executá-los em modo Sandbox via Erlang Ports no Agente.

Realidade em Níveis: Operações P2P

*O Ótimo Teórico:* Uma arquitetura de malha onde os agentes na borda operam com instâncias plenas do Kademlia DHT, roteando comandos e telemetria geograficamente entre si sem depender de Gateways centrais de nuvem para transitar pacotes de suporte (DBeaver).
*O Caminho Pragmático (Executado):* O Agente Edge funciona em modo "Fantasma". Ele abre ativamente a sessão Yamux contra o Gateway Central (GKE). O túnel reverso é invocado de dentro do Data Center para o cliente, suportando Firewalls restritivos e simplificando a auditoria de acessos Zero-Trust.