# PBS Spec Approval TODO

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

## Blockers

- [ ] Fechar o gate de prontidao para implementacao definido no charter.
  Hoje o charter exige specs adicionais antes de iniciar implementacao: dynamic semantics, memory and lifetime, host ABI binding, module/package, diagnostics, IR/lowering e conformance.
  Referencia: `1. Language Charter.md`, secao "Required Spec Set Before Implementation".

- [ ] Definir a identidade normativa de `host fn`.
  A governanca exige versionamento por `(module, name, version)`, mas a sintaxe e a semantica atual tratam `host fn` apenas por nome e assinatura.
  Isso precisa de contrato claro de binding, capability gating e linking.
  Referencias: `2. Governance and Versioning.md`, `3. Core Syntax Specification.md`, `4. Static Semantics Specification.md`.

- [ ] Fechar o modelo semantico de `service` ou remover `service` do core v1.
  A gramatica aceita `service Identifier (':' Identifier)?`, mas a spec nao define o significado do `: Identifier`, o ciclo de vida do servico, como ele e resolvido nem como participa do runtime.
  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.

- [ ] Decidir se a implementacao pode comecar em modo faseado.
  Recomendacao: permitir apenas parser/AST/binding inicial enquanto os blockers acima nao forem fechados.
  Nao liberar ainda lowering, linker, host integration ou runtime behavior final.

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