prometeu-runtime/docs/runtime/agendas/README.md

Agendas

Este diretório reúne agendas de discussão arquitetural para itens pendentes ou frágeis do runtime.

Objetivo:

• explicitar a dor real do sistema;
• delimitar o que precisa ser decidido antes de codar;
• servir de base para futuras PRs de implementação JVM-grade.

As agendas atuais são:

• 001-system-run-cart.md
• 002-packed-cartridge-loader-pmc.md
• 003-structured-runtime-abi.md
• 004-syscall-fault-classification.md
• 005-runtime-edge-test-plan.md
• 006-break-monolith-runtime.md
• 007-single-canonical-architecture.md
• 008-hardware-specs-reorganization.md

Sequenciamento Recomendado

Ordem sugerida para discussão e futura execução:

1. 007-single-canonical-architecture.md
2. 008-hardware-specs-reorganization.md
3. 006-break-monolith-runtime.md
4. 003-structured-runtime-abi.md
5. 004-syscall-fault-classification.md
6. 005-runtime-edge-test-plan.md
7. 001-system-run-cart.md
8. 002-packed-cartridge-loader-pmc.md

Justificativa curta:

• 007 vem primeiro porque elimina ambiguidade sobre qual documento manda.
• 008 vem em seguida porque reorganiza o terreno documental onde specs e arquitetura se apoiam.
• 006 entra depois porque refactor estrutural grande sem documentação estável tende a cristalizar decisões erradas.
• 003 e 004 formam o núcleo de contrato da borda do runtime.
• 005 fecha a barra de qualidade antes das implementações mais arriscadas.
• 001 e 002 dependem mais fortemente de contrato de sistema, ABI e documentação estáveis.

Dependências principais:

• 008 depende de 007
• 006 depende de 007
• 001 depende de 007, 003, 004 e 005
• 002 depende de 007 e deve ser alinhada com a reorganização documental de 008

Regra de uso:

• se a implementação exigir decisão estrutural, ela deve nascer daqui antes de virar PR de código;
• se uma agenda já estiver resolvida, a PR derivada deve citar explicitamente qual decisão foi tomada;
• se a agenda revelar ambiguidade demais, ela não deve ser convertida em PR até o alvo ficar preciso.