2026-03-24 13:40:47 +00:00

53 lines
1.9 KiB
Markdown

# 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`
## 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.