Gleam.br Wiki

GBR: Requisitos de Qualidade de Software e Isolamento (Refatoração Core) | Wiki

Documentação de engenharia e especificações técnicas da Gleam-BR.

GBR: Requisitos de Qualidade de Software e Isolamento (Refatoração Core)

*Requisitos Ubíquos (Ubiquitous Requirements)* * *UBQ-01:* O código-fonte do ecossistema base deve ser desprovido de avaliações de coerção inseguras (asserts não justificados matematicamente), devendo propagar falhas controladas através da tipagem funcional Result. * *UBQ-02:* Todo Ator (processo OTP) instanciado no sistema deve aderir à estrutura canônica padronizada (Message, State, start, loop), garantindo legibilidade e uniformidade arquitetural.

*Requisitos Orientados a Eventos (Event-Driven Requirements)* * *EVD-01:* Quando um pacote de depuração (debug logs de fluxo de bytes) for submetido durante a execução de ferramentas em nível de produção (como o falconctl), o console do sistema deve omiti-lo, exibindo estritamente metadados de ciclo de vida e mudanças de estado. * *EVD-02:* Quando um socket TCP fechar a conexão de forma inesperada na camada física, o Ator Proxy (Piper) deve capturar o evento e instruir proativamente o fechamento do Stream Yamux associado, liberando os recursos da malha.

*Requisitos Orientados a Estado (State-Driven Requirements)* * *STD-01:* Enquanto o sistema não puder determinar com segurança o tipo e a validade de um pacote injetado na malha, o motor de rede não deve alocar o processamento final da mensagem, repassando o erro para os mecanismos de descarte sem interromper o laço de eventos principal (loop).

*Requisitos de Comportamento Indesejado (Unwanted Behavior Requirements)* * *UNW-01:* Se uma nova funcionalidade introduzir dependências semânticas entre a camada de TCP cru e a camada de multiplexação (Yamux), a revisão arquitetural deve bloquear a mesclagem do código, exigindo a injeção através de contratos genéricos (BitArrays puros).