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.md002-packed-cartridge-loader-pmc.md005-runtime-edge-test-plan.md009-filesystem-surface-and-semantics.md012-asset-fault-semantics-and-surface.md013-audio-fault-semantics-and-surface.md014-gfx-fault-semantics-and-command-contract.md015-system-fault-semantics-and-control-surface.md016-filesystem-fault-semantics.md017-vm-owned-builtins-protocol-and-system-services.md
Sequenciamento Recomendado
Ordem sugerida para discussão e futura execução:
007-single-canonical-architecture.md008-hardware-specs-reorganization.md006-break-monolith-runtime.md017-vm-owned-builtins-protocol-and-system-services.md012-asset-fault-semantics-and-surface.md013-audio-fault-semantics-and-surface.md014-gfx-fault-semantics-and-command-contract.md001-system-run-cart.md015-system-fault-semantics-and-control-surface.md009-filesystem-surface-and-semantics.md016-filesystem-fault-semantics.md005-runtime-edge-test-plan.md002-packed-cartridge-loader-pmc.md
Justificativa curta:
007vem primeiro porque elimina ambiguidade sobre qual documento manda.008vem em seguida porque reorganiza o terreno documental onde specs e arquitetura se apoiam.006entra depois porque refactor estrutural grande sem documentação estável tende a cristalizar decisões erradas.017entra cedo para fechar um protocolo VM-owned unico (input/random/window/builtins) sem contaminar a fronteira de syscall host-backed.- a decisao
003ja fechou o contrato base para trafego de bytes VM-owned e agora deve ser consumida, nao rediscutida aqui. - a decisao
004ja fechou a taxonomia base de falhas host-backed e agora deve ser consumida pelos dominios. 012,013e014quebram o refactor de fault semantics por dominio onde a dor ja esta visivel no codigo.001vem antes de015porquerun_cartainda nao tem semantica funcional fechada.015fecha a taxonomia do dominiosystemdepois de001.009usa as decisoes003e004para fechar o dominio de filesystem sem texto improvisado.016fica explicitamente depois de009, para nao classificar falhas de uma surface que ainda pode mudar.- as discussoes de input v1 foram encerradas e migradas para a decisao
005. 005fecha a barra de qualidade antes das implementações mais arriscadas.001e002dependem mais fortemente de contrato de sistema, ABI e documentação estáveis.
Dependências principais:
008depende de007006depende de007017depende de007e deve alinhar com16/16a, alem das decisoes003e004009depende das decisoes003e004012depende da decisao004013depende da decisao004014depende da decisao004015depende da decisao004e001016depende das decisoes003,004e da009001depende de007, das decisoes003e004, de005e deve alinhar com009quando usarfs002depende de007e deve ser alinhada com a reorganização documental de008
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.