# PBS Spec Approval TODO

Status: Draft  
Purpose: checklist curto para decidir se a spec da PBS pode ser aprovada para seguir agora

## Blockers

- [X] Fechar o gate de prontidao para implementacao definido no charter para o escopo atual.
  Decisao: a aprovacao atual cobre apenas implementacao faseada de frontend (`parser`, `AST` e `binding` inicial).
  Isso fecha o gate apenas para esse escopo limitado e nao reclassifica a PBS como pronta para implementacao completa.
  Dynamic semantics, memory and lifetime, diagnostics, IR/lowering e conformance permanecem como trabalho aberto para fases posteriores.
  Referencia: `1. Language Charter.md`, secao "Required Spec Set Before Implementation".

- [X] Substituir o antigo modelo publico de `host fn` por `declare host` reservado a SDK/toolchain.
  Resolvido no nivel de charter, sintaxe e semantica estatica: bindings canonicos de host nao sao authorados pelo usuario comum, e superficies SDK usam `declare host` reservado.
  O contrato de PBX/load/runtime continua pendente para a futura Host ABI Binding specification.
  Referencias: `1. Language Charter.md`, `2. Governance and Versioning.md`, `3. Core Syntax Specification.md`, `4. Static Semantics Specification.md`, `5. Manifest, Stdlib, and SDK Resolution Specification.md`.

- [X] Fechar a spec normativa de manifest/module/package/stdlib.
  Resolvido com o modelo normativo de `project` e `module`, enderecamento canonico `@project:path/to/module`, `stdlib` como ambiente efetivo do build, `@sdk:*` e `@core:*` como project spaces reservados, interface modules PBS-like e atributos reservados de compile time como `[Host(...)]`.
  Referencias: `5. Manifest, Stdlib, and SDK Resolution Specification.md`, `6. Host ABI Binding and Loader Resolution Specification.md`.

- [X] Fechar o modelo semantico de `service` no core v1.
  Resolvido com `declare service` como singleton nominal por modulo, exportado via barrel, com metodos sem visibilidade independente e suporte a `implements Contract for Service using s`.
  Referencias: `3. Core Syntax Specification.md`, secao de `ServiceDecl`; `4. Static Semantics Specification.md`, callable categories.

- [X] Remover do core v1 ou especificar completamente as superficies que ja existem na gramatica mas ainda nao tem contrato suficiente.
  Itens visiveis hoje: `BoundedLit`, `GenericType`, `IndexSuffix` (`[]`) e `declare const` top-level.
  Se permanecerem no v1, precisam de semantica estatica/dinamica e diagnosticos claros.
  Referencia: `3. Core Syntax Specification.md`.

## Non-Blockers

- [x] Corrigir exemplos invalidos ou inconsistentes na spec estatica.
  Ha exemplos com `let` em escopo top-level para callbacks, mas top-level `let` e proibido pela sintaxe.
  Isso nao bloqueia a direcao da linguagem, mas deve ser corrigido para evitar ambiguidade.
  Referencias: `3. Core Syntax Specification.md`, `4. Static Semantics Specification.md`.

- [x] Consolidar exemplos canonicos para overload por retorno, `optional`, `result`, `bind`, `apply` e `switch`.
  A base conceitual esta boa; o ajuste aqui e editorial e de conformance, nao arquitetural.

- [X] Decidir se a implementacao pode comecar em modo faseado.
  Decisao tomada: permitir apenas parser/AST/binding inicial nesta etapa.
  Nao liberar ainda lowering, linker, host integration ou runtime behavior final.

## Pautas Dedicadas

- [X] Abrir pauta dedicada para dynamic semantics + memory and lifetime.
  Resolvido com uma pauta guarda-chuva de heap model e tres pautas filhas separando: modelo de execucao, superfices de efeito/controle e memory/lifetime.
  Isso reduz o acoplamento da discussao e permite fechar semantica observavel antes de fixar as regras normativas de heap e lifetime.
  Objetivo: fechar o modelo de execucao observavel, ordem de avaliacao, traps, efeitos sobre `optional`/`result`/`apply`/`bind`/`switch`, baseline GC, fronteira heap VM vs memoria do host e visibilidade de custo/alocacao.
  Resultado esperado: material para futura `Dynamic Semantics Specification` e `Memory and Lifetime Specification`.
  Referencias: `Heap Model - Agenda.md`, `Dynamic Semantics - Execution Model Agenda.md`, `Dynamic Semantics - Effect Surfaces Agenda.md`, `Memory and Lifetime - Agenda.md`.

- [X] Abrir pauta dedicada para validar se a `Host ABI Binding and Loader Resolution Specification` atual ja satisfaz o gate da fase seguinte ou se ainda precisa deixar de ser "Temporary".
  Decisao: suficiente para a proxima fase. O contrato atual de `declare host` -> metadata PBX -> loader -> syscall numerico ja esta estavel o bastante para nao bloquear a etapa posterior.
  Os pontos ainda abertos sao endurecimentos de formato/integracao, nao lacunas do contrato semantico principal.
  Referencias: `Host ABI Gate Validation Agenda.md`, `6. Host ABI Binding and Loader Resolution Specification.md`.

- [ ] FUTURO: abrir pauta de backend.
  Objetivo: tratar IR/lowering, linker, host integration, runtime behavior final e conformance somente depois de fechar o frontend e aparar as arestas da linguagem/spec.
  Resultado esperado: backlog da etapa de backend com precondicoes claras.
  Esta pauta nao bloqueia o frontend faseado atual.

## Decision Rule

Pode aprovar a PBS para seguir agora somente se a aprovacao significar:

- seguir com parser/frontend parcial, ou
- seguir com fechamento das specs faltantes antes de runtime/lowering/linking.

Nao aprovar como spec fechada para implementacao completa enquanto houver blockers abertos.