Missão e Governança Global

A FVideen, em parceria com as comunidades Gleam Lang BR e Gleam Dev BR, estabelece este documento como a diretriz de governança e fundação para o desenvolvimento de soluções resilientes, descentralizadas e de alto desempenho no ecossistema BEAM (Erlang/OTP).

Nossa missão principal é prover uma infraestrutura que alie a flexibilidade de redes Peer-to-Peer (P2P), a segurança de sistemas Zero-Trust e o determinismo de regras de negócios orientadas a agentes e fluxos de trabalho (BPMN), operando tanto na Borda (Edge) quanto na Nuvem.

Requisitos Fundacionais Globais (EARS)

O desenvolvimento de qualquer componente ou aplicação dentro do ecossistema Gleam-BR obedece aos seguintes requisitos estruturados sob a abordagem EARS (Easy Approach to Requirements Syntax):

1. Requisitos Ubíquos (Ubiquitous Requirements)

  • UBQ-01 (Offline-First): O sistema deve operar sob um modelo Offline-First na borda (Edge), garantindo a continuidade do estado em instâncias gbr_mnesia independentemente da conectividade de rede upstream.
  • UBQ-02 (Sem Portas Inbound): O sistema não deve expor portas de entrada (inbound ports) para a internet pública, utilizando exclusivamente canais reversos multiplexados via Yamux para toda a comunicação.

2. Requisitos Orientados a Eventos (Event-Driven Requirements)

  • EVD-01 (Telemetria Yamux): Quando a infraestrutura gerar logs ou métricas de telemetria, o componente gbr_telemetry deve formatá-los em Influx Line Protocol (ILP) e enviá-los exclusivamente através do Stream 0 do túnel Yamux.
  • EVD-02 (Roteamento Semântico Local): Quando um agente de IA invocar uma ferramenta via Model Context Protocol (MCP), o sistema deve acionar o roteador semântico local para tentar a resolução em nós P2P adjacentes antes de escalar a requisição para a nuvem.

3. Requisitos Orientados a Estado (State-Driven Requirements)

  • STD-01 (Nuvem Stateless): Enquanto implantados no ambiente de nuvem (Google Kubernetes Engine - GKE), os nós de processamento (gbr_p2p_mcp, gbr_bpm) devem permanecer puramente sem estado (stateless workers).
  • STD-02 (Bootstrap e NAT): Enquanto a DHT do Kademlia estiver em fase de convergência (Bootstrap), as assinaturas de segurança e identificação de nós (gbr_crypto) devem basear-se no protocolo Identify para viabilizar a travessia de NAT.

4. Requisitos de Comportamento Indesejado (Unwanted Behavior Requirements)

  • UNW-01 (Particionamento de Rede): Se ocorrer o particionamento da rede entre a Borda e a Nuvem, o componente gbr_disk_log deve atuar em conjunto com uma máquina de estados finitos para persistir o estado localmente de forma comprimida/criptografada, enfileirando os dados para o Bridge Service na reconexão.
  • UNW-02 (Evitar starvation da BEAM): Se o sistema processar pacotes pesados de Protobuf/GossipSub, a decodificação deve ser delegada para NIFs em Rust, a fim de evitar o bloqueio (starvation) do agendador (scheduler) da BEAM.

5. Requisitos Opcionais (Optional Feature Requirements)

  • OPT-01 (DuckDB Local): Onde a arquitetura do hardware de borda permitir, o sistema deve integrar o DuckDB via Rust NIF para viabilizar processamento vetorial em memória (VSS/HNSW) sem delegar consultas semânticas à nuvem.