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