prometeu-studio/docs/specs/pbs/TODO.md

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

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

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

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

• 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

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

• 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. Decisao tomada: permitir apenas parser/AST/binding inicial nesta etapa. Nao liberar ainda lowering, linker, host integration ou runtime behavior final.

Pautas Dedicadas

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

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