58 lines
3.1 KiB
Markdown
58 lines
3.1 KiB
Markdown
# 025-spec-cartridge-entrypoint-removal-and-boot-protocol
|
|
|
|
## Briefing
|
|
|
|
Propagar a [`decision 025`](../decisions/025-cartridge-manifest-entrypoint-removal-and-runtime-protocol.md) para o contrato normativo de cartridge, removendo `entrypoint` de `manifest.json` e publicando boot fixo em `func_id = 0`.
|
|
|
|
Esta PR e editorial e normativa. Ela existe para fechar o contrato antes ou em paralelo a qualquer remocao de codigo, evitando dividir runtime e spec sobre a mesma autoridade de boot.
|
|
|
|
## Decisions de Origem
|
|
|
|
- [`025-cartridge-manifest-entrypoint-removal-and-runtime-protocol.md`](../decisions/025-cartridge-manifest-entrypoint-removal-and-runtime-protocol.md)
|
|
|
|
## Alvo
|
|
|
|
Atualizar as specs que ainda descrevem `entrypoint` como parte do contrato do cartucho, com foco principal em [`../specs/13-cartridge.md`](../specs/13-cartridge.md).
|
|
|
|
## Escopo
|
|
|
|
- remover `entrypoint` do exemplo de `manifest.json`;
|
|
- remover `entrypoint` da lista de campos requeridos do cartucho;
|
|
- publicar explicitamente que o boot do cartucho e protocolar em `func_id = 0`;
|
|
- esclarecer que exports nominais nao exercem autoridade de boot;
|
|
- alinhar referencias em specs adjacentes caso ainda impliquem boot orientado por metadata textual.
|
|
|
|
## Fora de Escopo
|
|
|
|
- implementar a remocao em loader, system ou VM;
|
|
- discutir estrategia de compatibilidade em runtime;
|
|
- redefinir semantica de exports nominais fora do boot;
|
|
- qualquer redesign mais amplo de `manifest.json`.
|
|
|
|
## Plano de Execucao
|
|
|
|
1. Atualizar [`../specs/13-cartridge.md`](../specs/13-cartridge.md) para remover `entrypoint` do contrato normativo.
|
|
2. Incluir secao ou texto normativo explicitando que o entrypoint executavel do cartucho e sempre `func_id = 0`.
|
|
3. Revisar [`../specs/12-firmware-pos-and-prometeuhub.md`](../specs/12-firmware-pos-and-prometeuhub.md) e [`../specs/14-boot-profiles.md`](../specs/14-boot-profiles.md) para garantir que o fluxo de boot nao sugira metadado textual de entrypoint.
|
|
4. Validar consistencia editorial entre decision e spec final.
|
|
|
|
## Criterios de Aceite
|
|
|
|
- nenhuma spec normativa ativa descreve `entrypoint` como campo requerido de `manifest.json`;
|
|
- [`../specs/13-cartridge.md`](../specs/13-cartridge.md) afirma sem ambiguidade que o boot do cartucho ocorre em `func_id = 0`;
|
|
- as specs nao deixam espaco para interpretar exports nominais como autoridade de boot;
|
|
- a PR nao reabre a discussao arquitetural ja fechada na decision.
|
|
|
|
## Tests / Validacao
|
|
|
|
- revisao editorial cruzada entre [`../decisions/025-cartridge-manifest-entrypoint-removal-and-runtime-protocol.md`](../decisions/025-cartridge-manifest-entrypoint-removal-and-runtime-protocol.md) e as specs afetadas;
|
|
- busca textual por `entrypoint` nas specs para confirmar remocao do contrato antigo;
|
|
- validacao manual de coerencia entre exemplos JSON e listas de campos requeridos.
|
|
|
|
## Riscos
|
|
|
|
- remover `entrypoint` da spec sem linguagem normativa suficientemente explicita sobre `func_id = 0` pode deixar lacuna contratual;
|
|
- editar apenas `spec 13` e esquecer referencias em firmware/boot pode preservar ambiguidade documental;
|
|
- misturar guidance transitoria de tooling com texto normativo de runtime pode enfraquecer o contrato final.
|
|
|