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

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
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.