# 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`
- `005-runtime-edge-test-plan.md`
- `009-filesystem-surface-and-semantics.md`
- `010-input-intrinsics-surface.md`
- `011-input-frame-semantics-and-portability.md`
- `012-asset-fault-semantics-and-surface.md`
- `013-audio-fault-semantics-and-surface.md`
- `014-gfx-fault-semantics-and-command-contract.md`
- `015-system-fault-semantics-and-control-surface.md`
- `016-filesystem-fault-semantics.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. `012-asset-fault-semantics-and-surface.md`
5. `013-audio-fault-semantics-and-surface.md`
6. `014-gfx-fault-semantics-and-command-contract.md`
7. `001-system-run-cart.md`
8. `015-system-fault-semantics-and-control-surface.md`
9. `009-filesystem-surface-and-semantics.md`
10. `016-filesystem-fault-semantics.md`
11. `010-input-intrinsics-surface.md`
12. `011-input-frame-semantics-and-portability.md`
13. `005-runtime-edge-test-plan.md`
14. `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.
- a decisao `003` ja fechou o contrato base para trafego de bytes VM-owned e agora deve ser consumida, nao rediscutida aqui.
- a decisao `004` ja fechou a taxonomia base de falhas host-backed e agora deve ser consumida pelos dominios.
- `012`, `013` e `014` quebram o refactor de fault semantics por dominio onde a dor ja esta visivel no codigo.
- `001` vem antes de `015` porque `run_cart` ainda nao tem semantica funcional fechada.
- `015` fecha a taxonomia do dominio `system` depois de `001`.
- `009` usa as decisoes `003` e `004` para fechar o dominio de filesystem sem texto improvisado.
- `016` fica explicitamente depois de `009`, para nao classificar falhas de uma surface que ainda pode mudar.
- `010` e `011` isolam o dominio maior de input fora de syscall, tratando `pad` e `touch` como superfícies centrais, `button` como parte de `pad`, e explicitando a migracao da leitura de input para intrinsics.
- `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`
- `009` depende das decisoes `003` e `004`
- `012` depende da decisao `004`
- `013` depende da decisao `004`
- `014` depende da decisao `004`
- `015` depende da decisao `004` e `001`
- `016` depende das decisoes `003`, `004` e da `009`
- `010` depende de `007`
- `011` depende de `010`
- `001` depende de `007`, das decisoes `003` e `004`, de `005` e deve alinhar com `009` quando usar `fs`
- `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.