Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Processo de Engenharia e Fluxo de Trabalho

O PAEBIRU (Protocolo Assíncrono de Ecossistemas Biológicos para Infraestruturas Recursivas Universais) opera como uma malha P2P soberana onde a integridade e a previsibilidade são fundamentais. O desenvolvimento segue regras estritas para garantir que o “cérebro descentralizado” permaneça resiliente.

1. Ciclo de Vida do Desenvolvimento (RSE)

Todo novo recurso ou correção segue o ciclo Research -> Strategy -> Execution.

Pesquisa (Research)

  • Validação de Hipóteses: Antes de codificar, deve-se validar o impacto arquitetural.
  • Mapeamento de Dependências: Identificar como a mudança afeta os Bounded Contexts (Kernel, Biologia, Economia).
  • Referência Normativa: Toda pesquisa deve estar alinhada com as RFCs ratificadas (Standards Track 001-022).

Estratégia (Strategy)

  • Design Doc: Para mudanças significativas, um documento de design deve ser submetido para discussão.
  • Plano de Verificação: Definir como a mudança será provada correta (Testes Unitários, Integração, Fuzzing ou TLA+).

Execução (Execution)

  • Implementação Cirúrgica: Foco na simplicidade e remoção de lógica redundante.
  • GALS Compliance: Garantir que comunicações inter-nós sejam estritamente assíncronas.

2. Automação e Infraestrutura (A Linha de Montagem)

Conforme a RFC 050, a esteira de desenvolvimento é automatizada para garantir reprodutibilidade e qualidade:

  • Provisionamento Determinístico: O ambiente de desenvolvimento é gerido via Nix (infra/flake.nix e shell.nix), garantindo que todos os engenheiros operem em ambientes idênticos.
  • Orquestração via Makefile: O Makefile na raiz é o ponto de entrada canônico para todas as operações (build, lint, test, release). O uso do proxy rtk (ex: rtk make test) é obrigatório para eficiência operacional.
  • Muralha de Qualidade: Gates de CI rígidos em .github/workflows/ validam cada submissão antes da integração na branch principal.

3. Regras de Submissão (Pull Requests)

A malha P2P soberana não aceita mudanças arbitrárias.

  • Rastreabilidade: Toda alteração deve citar uma Especificação Normativa (RFC) correspondente no corpo do PR.
  • Peer Review (Revisão P2P):
    • O código deve ser revisado considerando seu impacto no Metabolismo da rede (Consumo de Memória, CPU e IO).
    • Lógicas bloqueantes (blocking calls) em loops de Atores resultarão em rejeição automática da submissão.
  • Paradigma GALS: Todo novo recurso que dependa de rede ou I/O deve utilizar passagem de mensagens assíncronas; o estado não pode ser mutado diretamente de fora do ator.

3. Prova de Verificação (PoV)

Uma contribuição é considerada incompleta sem a sua prova de correção.

Verificação Formal & Simulação

  • TLA+: Alterações no Kernel ou protocolos de consenso exigem modelos TLA+ para verificar a ausência de deadlocks e violações de invariantes.
  • Simulações de Hardware: Recursos embarcados devem passar por simulações em apps/simulations para validar o comportamento em restrições de tempo real.

Testes e Qualidade

  • Fuzz Testing: Protocolos de rede e serialização (como C.A.P.I.B.A.) devem ser submetidos a testes de fuzzing.
  • Metabolismo Check: Validação de que a mudança não introduz vazamentos de memória ou picos injustificados de CPU que possam desestabilizar nós menores (Edge/Microcontroladores).

4. Lançamentos Multi-linguagem (Release)

O PAEBIRU suporta 13 linguagens via paebiru-sdk. O fluxo de release é orquestrado para manter a paridade funcional e de segurança.

  • Orquestração de Bindings: As alterações no Core (Rust) disparam automaticamente a atualização dos bindings (C, Python, Java, Dart, TS, etc.).
  • Sincronização de Plasmídeos: Garante que os Contratos ZK e Plasmídeos funcionem unissonamente em todo o ecossistema, independentemente da linguagem hospedeira.
  • Workflows Automatizados: Geração de pacotes nativos (NPM, PyPI, Maven, Crates.io) via GitHub Actions, seguindo versionamento semântico estrito.

5. Convenções de Naming e Estilo

  • Nomes Informativos: Evitar abreviações obscuras. O nome deve refletir o propósito a longo prazo (ex: network_mesh_resilience.rs em vez de net_fix.rs).
  • Documentação Inline: Todo Trait e Função Pública deve conter documentação em RustDoc explicando não apenas o quê, mas o porquê daquela abstração.