2.6 KiB
| id | ticket | title | status | created | resolved | decision | tags | |||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| AGD-0064 | multi-frontend-sdk-canonical-definition | Auditoria e centralizacao gradual da definicao canonica do SDK | open | 2026-07-15 |
|
Agenda - Centralizar a definicao do SDK
Objetivo
Domain owner: compiler/general, com referencias a compiler/pbs e vm-arch.
Auditar onde hostcalls, intrinsics, tipos fundamentais e APIs do console sao definidos hoje antes de propor uma fonte canonica do SDK.
Contexto atual
Existem specs em docs/vm-arch/INTRINSICS.csv, docs de stdlib em docs/specs/compiler/18. Standard Library Surface Specification.md, specs PBS de stdlib e host ABI, alem de possiveis registries em codigo e fixtures.
Escopo
- Mapear fontes atuais da verdade.
- Identificar definicoes geradas, duplicadas e manuais.
- Propor caminho gradual para um schema canonico.
Fora de escopo
- Migracao grande do SDK.
- Gerar bindings para C#, Kotlin, TypeScript ou outras linguagens.
- Escolher formato definitivo antes da auditoria.
Arquivos e componentes a inspecionar
docs/vm-arch/INTRINSICS.csvdocs/specs/compiler/18. Standard Library Surface Specification.mddocs/specs/compiler-languages/pbs/5. Manifest, Stdlib, and SDK Resolution Specification.mddocs/specs/compiler-languages/pbs/6.1. Intrinsics and Builtin Types Specification.mdprometeu-compiler/...registries de hostcalls/intrinsics/stdlib- runtime/PVM quando presente no workspace ou submodulos relacionados
Alteracoes propostas
Opcao A: agenda de auditoria pura, produzindo mapa de fontes e duplicacoes.
Opcao B: criar schema canonico minimo depois da auditoria, sem migrar todos os consumidores.
Recomendacao inicial: primeiro fechar auditoria; so uma decision posterior deve escolher formato e migracao.
Estrategia de implementacao
Listar cada hostcall/intrinsic/tipo fundamental em suas fontes atuais, comparar assinatura, capability, versao e docs, e classificar divergencias.
Testes necessarios
- Testes de paridade entre registry runtime/backend e specs existentes, se ja houver fonte estruturada.
- Testes de nao divergencia para IDs e assinaturas apos qualquer centralizacao.
Criterios de aceitacao
- Existe mapa claro de fonte real da verdade.
- Duplicacoes e divergencias ficam registradas.
- Nenhuma migracao ampla e iniciada sem nova decisao.
Riscos
- Tratar docs como fonte real quando o codigo ja diverge.
- Iniciar geracao antes de saber quem consome cada definicao.
Decisoes que devem ser registradas
- Fonte canonica proposta.
- Campos obrigatorios do SDK.
- Sequencia de migracao segura.