prometeu-studio/discussion/workflow/agendas/AGD-0064-multi-frontend-sdk-canonical-definition.md
bQUARKz 35b65bb524
All checks were successful
JaCoCo Coverage #### Project Overview No changes detected, that affect the code coverage. * Line Coverage: 61.37% (17351/28272) * Branch Coverage: 52.31% (6722/12850) * Lines of Code: 28272 * Cyclomatic Complexity: 11325 #### Quality Gates Summary Output truncated.
Test / Build skipped: 15, passed: 601
Intrepid/Prometeu/Studio/pipeline/head This commit looks good
multi FE adjustment agendas
2026-07-15 07:58:23 +01:00

79 lines
2.6 KiB
Markdown

---
id: AGD-0064
ticket: multi-frontend-sdk-canonical-definition
title: Auditoria e centralizacao gradual da definicao canonica do SDK
status: open
created: 2026-07-15
resolved:
decision:
tags: [compiler, compiler-general, sdk, stdlib, hostcalls, intrinsics, multi-frontend]
---
# 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.csv`
- `docs/specs/compiler/18. Standard Library Surface Specification.md`
- `docs/specs/compiler-languages/pbs/5. Manifest, Stdlib, and SDK Resolution Specification.md`
- `docs/specs/compiler-languages/pbs/6.1. Intrinsics and Builtin Types Specification.md`
- `prometeu-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.