multi FE adjustment agendas

discussion/index.ndjson

@@ -1,4 +1,16 @@
-{"type":"meta","next_id":{"DSC":54,"AGD":57,"DEC":40,"PLN":103,"LSN":55,"CLSN":1}}
+{"type":"meta","next_id":{"DSC":66,"AGD":69,"DEC":40,"PLN":103,"LSN":55,"CLSN":1}}
+{"type":"discussion","id":"DSC-0065","status":"open","ticket":"multi-frontend-avoid-premature-abstractions","title":"Evitar abstracoes prematuras na preparacao multi-frontend","created_at":"2026-07-15","updated_at":"2026-07-15","tags":["compiler","compiler-general","studio","frontend","architecture","multi-frontend","simplicity"],"agendas":[{"id":"AGD-0068","file":"AGD-0068-multi-frontend-avoid-premature-abstractions.md","status":"open","created_at":"2026-07-15","updated_at":"2026-07-15"}],"decisions":[],"plans":[],"lessons":[]}
+{"type":"discussion","id":"DSC-0064","status":"open","ticket":"multi-frontend-architectural-tests","title":"Testes arquiteturais para fronteiras multi-frontend","created_at":"2026-07-15","updated_at":"2026-07-15","tags":["compiler","compiler-general","studio","frontend","architecture","tests","multi-frontend"],"agendas":[{"id":"AGD-0067","file":"AGD-0067-multi-frontend-architectural-tests.md","status":"open","created_at":"2026-07-15","updated_at":"2026-07-15"}],"decisions":[],"plans":[],"lessons":[]}
+{"type":"discussion","id":"DSC-0063","status":"open","ticket":"multi-frontend-synthetic-test-frontend","title":"Frontend sintetico de teste para provar neutralidade do pipeline","created_at":"2026-07-15","updated_at":"2026-07-15","tags":["compiler","compiler-general","frontend","tests","backend","multi-frontend"],"agendas":[{"id":"AGD-0066","file":"AGD-0066-multi-frontend-synthetic-test-frontend.md","status":"open","created_at":"2026-07-15","updated_at":"2026-07-15"}],"decisions":[],"plans":[],"lessons":[]}
+{"type":"discussion","id":"DSC-0062","status":"open","ticket":"multi-frontend-pvm-neutrality","title":"Neutralidade da PVM e identificacao PBX independente de PBS","created_at":"2026-07-15","updated_at":"2026-07-15","tags":["vm-arch","runtime","pvm","pbx","compiler","multi-frontend"],"agendas":[{"id":"AGD-0065","file":"AGD-0065-multi-frontend-pvm-neutrality.md","status":"open","created_at":"2026-07-15","updated_at":"2026-07-15"}],"decisions":[],"plans":[],"lessons":[]}
+{"type":"discussion","id":"DSC-0061","status":"open","ticket":"multi-frontend-sdk-canonical-definition","title":"Auditoria e centralizacao gradual da definicao canonica do SDK","created_at":"2026-07-15","updated_at":"2026-07-15","tags":["compiler","compiler-general","sdk","stdlib","hostcalls","intrinsics","multi-frontend"],"agendas":[{"id":"AGD-0064","file":"AGD-0064-multi-frontend-sdk-canonical-definition.md","status":"open","created_at":"2026-07-15","updated_at":"2026-07-15"}],"decisions":[],"plans":[],"lessons":[]}
+{"type":"discussion","id":"DSC-0060","status":"open","ticket":"multi-frontend-validation-boundaries","title":"Separar validacoes de linguagem e validacoes de plataforma","created_at":"2026-07-15","updated_at":"2026-07-15","tags":["compiler","compiler-general","compiler-pbs","backend","validation","multi-frontend"],"agendas":[{"id":"AGD-0063","file":"AGD-0063-multi-frontend-validation-boundaries.md","status":"open","created_at":"2026-07-15","updated_at":"2026-07-15"}],"decisions":[],"plans":[],"lessons":[]}
+{"type":"discussion","id":"DSC-0059","status":"open","ticket":"multi-frontend-common-lifecycle","title":"Extrair lifecycle comum das responsabilidades do frontend PBS","created_at":"2026-07-15","updated_at":"2026-07-15","tags":["compiler","compiler-general","compiler-pbs","lifecycle","backend","multi-frontend"],"agendas":[{"id":"AGD-0062","file":"AGD-0062-multi-frontend-common-lifecycle.md","status":"open","created_at":"2026-07-15","updated_at":"2026-07-15"}],"decisions":[],"plans":[],"lessons":[]}
+{"type":"discussion","id":"DSC-0058","status":"open","ticket":"multi-frontend-serializable-ir","title":"Manter a IR comum serializavel por design","created_at":"2026-07-15","updated_at":"2026-07-15","tags":["compiler","compiler-general","ir","backend","serialization","multi-frontend"],"agendas":[{"id":"AGD-0061","file":"AGD-0061-multi-frontend-serializable-ir.md","status":"open","created_at":"2026-07-15","updated_at":"2026-07-15"}],"decisions":[],"plans":[],"lessons":[]}
+{"type":"discussion","id":"DSC-0057","status":"open","ticket":"multi-frontend-frontend-backend-contract","title":"Estabilizar contrato entre frontend e backend comum","created_at":"2026-07-15","updated_at":"2026-07-15","tags":["compiler","compiler-general","compiler-pbs","ir","backend","multi-frontend"],"agendas":[{"id":"AGD-0060","file":"AGD-0060-multi-frontend-frontend-backend-contract.md","status":"open","created_at":"2026-07-15","updated_at":"2026-07-15"}],"decisions":[],"plans":[],"lessons":[]}
+{"type":"discussion","id":"DSC-0056","status":"open","ticket":"multi-frontend-remove-pbs-branches","title":"Remover verificacoes explicitas de PBS do codigo comum","created_at":"2026-07-15","updated_at":"2026-07-15","tags":["compiler","compiler-general","compiler-pbs","studio","frontend","coupling","multi-frontend"],"agendas":[{"id":"AGD-0059","file":"AGD-0059-multi-frontend-remove-pbs-branches.md","status":"open","created_at":"2026-07-15","updated_at":"2026-07-15"}],"decisions":[],"plans":[],"lessons":[]}
+{"type":"discussion","id":"DSC-0055","status":"open","ticket":"multi-frontend-compiler-vs-language-services","title":"Separar compilacao de servicos editoriais de frontend","created_at":"2026-07-15","updated_at":"2026-07-15","tags":["compiler","compiler-general","studio","lsp","editor","frontend","multi-frontend"],"agendas":[{"id":"AGD-0058","file":"AGD-0058-multi-frontend-compiler-vs-language-services.md","status":"open","created_at":"2026-07-15","updated_at":"2026-07-15"}],"decisions":[],"plans":[],"lessons":[]}
+{"type":"discussion","id":"DSC-0054","status":"open","ticket":"multi-frontend-provider-contract","title":"Introduzir provider completo de frontend","created_at":"2026-07-15","updated_at":"2026-07-15","tags":["compiler","compiler-general","studio","frontend","registry","multi-frontend"],"agendas":[{"id":"AGD-0057","file":"AGD-0057-multi-frontend-provider-contract.md","status":"open","created_at":"2026-07-15","updated_at":"2026-07-15"}],"decisions":[],"plans":[],"lessons":[]}
 {"type":"discussion","id":"DSC-0053","status":"open","ticket":"pbs-lsp-call-and-type-hierarchy","title":"PBS LSP Call and Type Hierarchy","created_at":"2026-07-15","updated_at":"2026-07-15","tags":["studio","lsp","vscode","compiler-pbs","editor","call-hierarchy","type-hierarchy"],"agendas":[{"id":"AGD-0056","file":"AGD-0056-pbs-lsp-call-and-type-hierarchy.md","status":"open","created_at":"2026-07-15","updated_at":"2026-07-15"}],"decisions":[],"plans":[],"lessons":[]}
 {"type":"discussion","id":"DSC-0052","status":"open","ticket":"pbs-lsp-document-links","title":"PBS LSP Document Links","created_at":"2026-07-15","updated_at":"2026-07-15","tags":["studio","lsp","vscode","compiler-pbs","editor","document-links","imports"],"agendas":[{"id":"AGD-0055","file":"AGD-0055-pbs-lsp-document-links.md","status":"open","created_at":"2026-07-15","updated_at":"2026-07-15"}],"decisions":[],"plans":[],"lessons":[]}
 {"type":"discussion","id":"DSC-0051","status":"open","ticket":"pbs-lsp-diagnostics-ux","title":"PBS LSP Diagnostics UX","created_at":"2026-07-15","updated_at":"2026-07-15","tags":["studio","lsp","vscode","compiler-pbs","editor","diagnostics","ux"],"agendas":[{"id":"AGD-0054","file":"AGD-0054-pbs-lsp-diagnostics-ux.md","status":"open","created_at":"2026-07-15","updated_at":"2026-07-15"}],"decisions":[],"plans":[],"lessons":[]}

discussion/workflow/agendas/AGD-0057-multi-frontend-provider-contract.md

@@ -0,0 +1,79 @@
+---
+id: AGD-0057
+ticket: multi-frontend-provider-contract
+title: Introduzir provider completo de frontend
+status: open
+created: 2026-07-15
+resolved:
+decision:
+tags: [compiler, compiler-general, studio, frontend, registry, multi-frontend]
+---
+
+# Agenda - Introduzir provider completo de frontend
+
+## Objetivo
+
+Domain owner: `compiler/general`, com impacto em `studio`.
+
+Discutir como consolidar um contrato de `FrontendProvider` que agrupe especificacao, compilador e servicos editoriais opcionais sem transformar o Studio em uma plataforma de plugins.
+
+## Contexto atual
+
+O repositorio ja possui `prometeu-compiler/prometeu-frontend-registry/src/main/java/p/studio/compiler/FrontendRegistryService.java` e superficies relacionadas a `FrontendSpec`, `FrontendPhaseService` e `languageId`. Ainda ha sinais de registro ou uso direto do PBS em composition roots e chamadas comuns.
+
+## Escopo
+
+- Inspecionar o registry atual e seus consumidores.
+- Definir se `FrontendProvider` deve ser novo contrato ou evolucao de contrato existente.
+- Planejar `PBSFrontendProvider` como unico provider inicial.
+- Preservar selecao atual por `languageId`.
+
+## Fora de escopo
+
+- Descoberta dinamica de plugins.
+- Reflection, classpath scanning ou carregamento externo de JARs.
+- Implementar qualquer frontend real alem do PBS.
+
+## Arquivos e componentes a inspecionar
+
+- `prometeu-compiler/prometeu-frontend-registry/src/main/java/p/studio/compiler/FrontendRegistryService.java`
+- `prometeu-compiler/frontends/prometeu-frontend-pbs/...`
+- `prometeu-compiler/prometeu-build-pipeline/...`
+- `prometeu-studio/src/main/java/p/studio/projects/ProjectLanguageCatalogService.java`
+- `prometeu-app/src/main/java/p/studio/AppContainer.java`
+
+## Alteracoes propostas
+
+Opcao A: criar `FrontendProvider` explicito com `specification()`, `compiler()` e `languageService()` opcional.
+
+Opcao B: evoluir o registry para devolver um objeto existente que ja represente provider, adicionando apenas os campos faltantes.
+
+Recomendacao inicial: preferir a menor mudanca que faca o codigo comum resolver `provider = registry.require(languageId)` e pare de conhecer classes PBS fora do composition root.
+
+## Estrategia de implementacao
+
+Comecar por uma auditoria de chamadas atuais ao registry e de instanciacoes diretas do PBS. Introduzir o contrato sem remover APIs antigas no mesmo passo, migrar PBS para o contrato e so entao substituir consumidores comuns.
+
+## Testes necessarios
+
+- Teste do registry exigindo resolucao por `languageId`.
+- Teste de registro unico do PBS como provider inicial.
+- Teste de erro claro para `languageId` desconhecido.
+
+## Criterios de aceitacao
+
+- O codigo comum consulta o provider, nao instancia `PBSFrontendPhaseService`.
+- PBS permanece funcional.
+- Nenhum frontend real novo e criado.
+
+## Riscos
+
+- Criar uma abstracao grande demais antes de mapear os consumidores reais.
+- Misturar contrato de build com contrato editorial.
+
+## Decisoes que devem ser registradas
+
+- Nome final do contrato.
+- Responsabilidades minimas do provider.
+- Onde fica o composition root autorizado a registrar PBS.
+

discussion/workflow/agendas/AGD-0058-multi-frontend-compiler-vs-language-services.md

@@ -0,0 +1,78 @@
+---
+id: AGD-0058
+ticket: multi-frontend-compiler-vs-language-services
+title: Separar compilacao de servicos editoriais de frontend
+status: open
+created: 2026-07-15
+resolved:
+decision:
+tags: [compiler, compiler-general, studio, lsp, editor, frontend, multi-frontend]
+---
+
+# Agenda - Separar compilacao de servicos editoriais
+
+## Objetivo
+
+Domain owner: `compiler/general`, com impacto em `studio/lsp`.
+
+Separar o contrato necessario para build do contrato necessario para IDE, permitindo frontends progressivos: compilacao, diagnostics/highlighting e experiencia editorial completa.
+
+## Contexto atual
+
+O PBS fornece compilacao e varias superficies editoriais. Historicamente o Studio e o LSP podem assumir que semantic tokens, diagnostics e navegação vêm do mesmo servico PBS.
+
+## Escopo
+
+- Identificar interfaces atuais de compilacao e editor.
+- Definir capabilities opcionais para servicos editoriais.
+- Garantir que ausencia de completion, hover, definition ou semantic tokens nao invalide um frontend compilavel.
+
+## Fora de escopo
+
+- Implementar novas features editoriais.
+- Redesenhar todo o LSP.
+- Criar frontend real sem recursos editoriais.
+
+## Arquivos e componentes a inspecionar
+
+- `prometeu-lsp/prometeu-lsp-api/...`
+- `prometeu-lsp/...`
+- `prometeu-studio/src/main/java/p/studio/...editor...`
+- `prometeu-compiler/frontends/prometeu-frontend-pbs/...`
+- `prometeu-compiler/prometeu-build-pipeline/...`
+
+## Alteracoes propostas
+
+Opcao A: `FrontendProvider` entrega `FrontendCompiler` obrigatorio e `Optional<FrontendLanguageService>`.
+
+Opcao B: dividir language service em interfaces menores, como diagnostics, completion, hover, definition e semantic tokens.
+
+Recomendacao inicial: mapear primeiro os consumidores. Se o LSP ja resolve features separadamente, usar interfaces menores; caso contrario, um language service opcional com capabilities pode ser suficiente.
+
+## Estrategia de implementacao
+
+Caracterizar o comportamento PBS atual, definir fallback para recurso ausente e migrar chamadas editoriais para consulta de capability antes de invocar servico.
+
+## Testes necessarios
+
+- Frontend provider compilavel sem language service nao quebra build.
+- LSP/Studio tratam feature ausente como resposta vazia ou unsupported documentado.
+- PBS continua expondo as mesmas respostas editoriais.
+
+## Criterios de aceitacao
+
+- Compilacao nao depende de APIs de IDE.
+- Recursos editoriais ausentes sao opcionais.
+- O contrato permite os niveis 1, 2 e 3 descritos no alinhamento.
+
+## Riscos
+
+- Introduzir `Optional` em excesso sem uma politica consistente de fallback.
+- Acoplar diagnostics de build e diagnostics editoriais sem separar latencia e escopo.
+
+## Decisoes que devem ser registradas
+
+- Granularidade final das interfaces editoriais.
+- Comportamento padrao para capability ausente.
+- Relacao entre diagnostics de compilacao e diagnostics de editor.
+

discussion/workflow/agendas/AGD-0059-multi-frontend-remove-pbs-branches.md

@@ -0,0 +1,78 @@
+---
+id: AGD-0059
+ticket: multi-frontend-remove-pbs-branches
+title: Remover verificacoes explicitas de PBS do codigo comum
+status: open
+created: 2026-07-15
+resolved:
+decision:
+tags: [compiler, compiler-general, compiler-pbs, studio, frontend, coupling, multi-frontend]
+---
+
+# Agenda - Remover verificacoes explicitas de PBS do codigo comum
+
+## Objetivo
+
+Domain owner: `compiler/general`, com impacto em `studio` e `compiler/pbs`.
+
+Definir uma auditoria e remocao incremental de branches, instanciacoes e chamadas estaticas PBS em codigo comum.
+
+## Contexto atual
+
+O documento de alinhamento aponta ocorrencias como `"pbs"`, `PBSDefinitions`, `PBSFrontendPhaseService`, `PBSFrontend`, `PbsParser`, `PbsSemantic` e `languageId`. A primeira busca no repo confirma ocorrencias espalhadas em docs, testes, frontend PBS, build pipeline e Studio.
+
+## Escopo
+
+- Classificar ocorrencias como internas ao PBS, composition root, testes PBS ou referencias indevidas.
+- Substituir referencias indevidas por provider, spec, capability ou servico registrado.
+- Manter excecoes explicitas documentadas.
+
+## Fora de escopo
+
+- Remover constantes PBS internas do proprio frontend.
+- Alterar templates explicitamente PBS.
+- Renomear packages.
+
+## Arquivos e componentes a inspecionar
+
+- `prometeu-app/src/main/java/p/studio/AppContainer.java`
+- `prometeu-studio/src/main/java/p/studio/window/NewProjectWizard.java`
+- `prometeu-studio/src/main/java/p/studio/projects/...`
+- `prometeu-compiler/prometeu-build-pipeline/...`
+- `prometeu-compiler/frontends/prometeu-frontend-pbs/...`
+- testes que importam `p.studio.compiler.pbs...`
+
+## Alteracoes propostas
+
+Opcao A: auditoria textual primeiro, seguida de PRs pequenos por area.
+
+Opcao B: criar teste arquitetural antes e usar falhas para guiar remocao.
+
+Recomendacao inicial: fazer auditoria textual e classificar em tabela curta antes de alterar; em seguida adicionar teste arquitetural para impedir regressao.
+
+## Estrategia de implementacao
+
+Usar `rg` para localizar termos, confirmar nomes reais, registrar classificacao no plano derivado e migrar apenas uma fronteira por vez.
+
+## Testes necessarios
+
+- Teste de dependencia impedindo imports PBS em packages comuns.
+- Testes de build existentes do PBS.
+- Testes de Studio/project wizard para garantir templates PBS ainda funcionam.
+
+## Criterios de aceitacao
+
+- Codigo comum nao decide comportamento por `"pbs"`.
+- Excecoes ficam restritas a composition root, testes PBS, templates PBS e frontend PBS.
+
+## Riscos
+
+- Remover uma referencia valida do PBS por classificacao apressada.
+- Quebrar setup de projeto existente ao mover extensoes e templates para provider.
+
+## Decisoes que devem ser registradas
+
+- Lista de excecoes permitidas.
+- Criterio de ownership para cada pacote comum.
+- Ordem de migracao por area.
+

discussion/workflow/agendas/AGD-0060-multi-frontend-frontend-backend-contract.md

@@ -0,0 +1,78 @@
+---
+id: AGD-0060
+ticket: multi-frontend-frontend-backend-contract
+title: Estabilizar contrato entre frontend e backend comum
+status: open
+created: 2026-07-15
+resolved:
+decision:
+tags: [compiler, compiler-general, compiler-pbs, ir, backend, multi-frontend]
+---
+
+# Agenda - Estabilizar o contrato entre frontend e backend
+
+## Objetivo
+
+Domain owner: `compiler/general`, com impacto em `compiler/pbs`.
+
+Definir o limite exato entre frontend e backend para garantir que o backend receba IR comum, e nao AST, tokens, simbolos ou objetos semanticos PBS.
+
+## Contexto atual
+
+As specs citam `IRBackend` como handoff executavel em `docs/specs/compiler/20. IRBackend to IRVM Lowering Specification.md` e `docs/specs/compiler-languages/pbs/13. Lowering IRBackend Specification.md`. Testes como `IRBackendExecutableContractTest` e `LowerToIRVMServiceTest` ja sugerem um contrato backend direto.
+
+## Escopo
+
+- Auditar tipos publicos de `IRBackend` e modelos associados.
+- Confirmar se a estrutura atual ja representa uma IR comum.
+- Identificar qualquer dependencia em AST ou semantica PBS no backend.
+
+## Fora de escopo
+
+- Renomear `IRBackend` por preferencia estetica.
+- Redesenhar o lowering para IRVM.
+- Implementar serializacao.
+
+## Arquivos e componentes a inspecionar
+
+- `prometeu-compiler/prometeu-build-pipeline/src/main/java/p/studio/compiler/models/...`
+- `prometeu-compiler/prometeu-build-pipeline/src/main/java/p/studio/compiler/backend/...`
+- `prometeu-compiler/frontends/prometeu-frontend-pbs/...`
+- `docs/specs/compiler/20. IRBackend to IRVM Lowering Specification.md`
+- `docs/specs/compiler-languages/pbs/13. Lowering IRBackend Specification.md`
+
+## Alteracoes propostas
+
+Opcao A: manter `IRBackend` e documentar/adaptar o contrato como `Prometeu Frontend IR`.
+
+Opcao B: criar um novo nome de dominio quando houver divergencia real entre modelo atual e fronteira desejada.
+
+Recomendacao inicial: auditar antes de renomear; mudar nomes so quando o modelo atual impedir clareza operacional.
+
+## Estrategia de implementacao
+
+Listar campos e tipos transitivos da IR, classificar cada item como comum ou especifico de PBS, e planejar extracoes pequenas para qualquer vazamento.
+
+## Testes necessarios
+
+- Teste construindo IR comum diretamente sem parser PBS.
+- Teste de backend sem imports de packages PBS.
+- Teste negativo para tipos AST PBS no contrato publico da IR.
+
+## Criterios de aceitacao
+
+- Backend e testavel com IR montada manualmente.
+- Contrato contem modulos, funcoes, tipos, blocos, calls, exports, lifecycle, spans, diagnostics e capabilities em termos neutros.
+- Contrato nao contem `PbsExpression`, `PbsStatement`, `PbsToken` ou equivalentes.
+
+## Riscos
+
+- Confundir IR comum com modelo de lowering interno de PBS.
+- Quebrar fixtures existentes por mudanca ampla demais.
+
+## Decisoes que devem ser registradas
+
+- Nome normativo do handoff.
+- Lista de tipos permitidos no contrato.
+- Limite entre spec geral e spec PBS.
+

discussion/workflow/agendas/AGD-0061-multi-frontend-serializable-ir.md

@@ -0,0 +1,76 @@
+---
+id: AGD-0061
+ticket: multi-frontend-serializable-ir
+title: Manter a IR comum serializavel por design
+status: open
+created: 2026-07-15
+resolved:
+decision:
+tags: [compiler, compiler-general, ir, backend, serialization, multi-frontend]
+---
+
+# Agenda - Manter a IR serializavel por design
+
+## Objetivo
+
+Domain owner: `compiler/general`.
+
+Avaliar se a IR comum pode atravessar futuramente uma fronteira de processo sem redesenho, evitando callbacks, estado global, ciclos e identity equality como parte do contrato.
+
+## Contexto atual
+
+O pipeline atual roda na JVM, mas frontends futuros podem ser externos. O alinhamento proibe escolher JSON, Protobuf, RPC ou processo externo agora; a discussao deve focar no formato dos dados.
+
+## Escopo
+
+- Auditar records/classes da IR comum.
+- Identificar referencias a servicos, objetos mutaveis, ciclos e IDs implicitos.
+- Definir principios de modelagem: IDs explicitos, listas ordenadas, enums e valores primitivos.
+
+## Fora de escopo
+
+- Implementar codec.
+- Serializar a saida do PBS dentro do mesmo processo.
+- Escolher wire format.
+
+## Arquivos e componentes a inspecionar
+
+- `prometeu-compiler/prometeu-build-pipeline/src/main/java/p/studio/compiler/models/...`
+- `prometeu-compiler/prometeu-build-pipeline/src/main/java/p/studio/compiler/backend/...`
+- testes `IRBackendExecutableContractTest` e `LowerToIRVMServiceTest`
+- docs de specs do compiler geral
+
+## Alteracoes propostas
+
+Opcao A: documentar invariantes de serializabilidade e corrigir apenas vazamentos claros.
+
+Opcao B: criar tipos de ID e spans onde hoje houver identidade textual ou referencias diretas instaveis.
+
+Recomendacao inicial: comecar por auditoria e testes de reflexao leves antes de qualquer migracao estrutural.
+
+## Estrategia de implementacao
+
+Gerar uma lista de tipos publicos da IR, revisar construtores e campos, e propor correcoes incrementais para pontos que impediriam um codec futuro.
+
+## Testes necessarios
+
+- Teste de reflexao sobre campos publicos/record components da IR.
+- Teste de determinismo de ordenacao.
+- Teste de ausencia de referencias a AST, servicos ou callbacks.
+
+## Criterios de aceitacao
+
+- A IR pode ser descrita como grafo de dados aciclico ou com referencias por ID.
+- Nenhuma escolha prematura de wire format e introduzida.
+
+## Riscos
+
+- Overengineering de IDs onde o contrato ainda nao exige.
+- Quebrar ergonomia de testes ao tornar todos os objetos verbosos.
+
+## Decisoes que devem ser registradas
+
+- Regras minimas de serializabilidade.
+- Tipos de ID que devem existir agora.
+- Itens explicitamente adiados para codec futuro.
+

discussion/workflow/agendas/AGD-0062-multi-frontend-common-lifecycle.md

@@ -0,0 +1,77 @@
+---
+id: AGD-0062
+ticket: multi-frontend-common-lifecycle
+title: Extrair lifecycle comum das responsabilidades do frontend PBS
+status: open
+created: 2026-07-15
+resolved:
+decision:
+tags: [compiler, compiler-general, compiler-pbs, lifecycle, backend, multi-frontend]
+---
+
+# Agenda - Extrair o lifecycle do frontend PBS
+
+## Objetivo
+
+Domain owner: `compiler/general`, com impacto em `compiler/pbs`.
+
+Separar declaracao de lifecycle feita por uma linguagem da montagem comum de init, frame, module initializers e entrypoint publicado.
+
+## Contexto atual
+
+As lessons e specs antigas indicam que PBS ja trata lifecycle e wrapper/entrypoint. O alinhamento pede que `PBSFrontendPhaseService` deixe de conter regras universais da plataforma.
+
+## Escopo
+
+- Localizar onde PBS sintetiza ou valida lifecycle.
+- Definir contrato comum de `LifecycleDeclaration` ou equivalente.
+- Planejar servico comum para validar, ordenar e montar entrypoint.
+
+## Fora de escopo
+
+- Alterar sintaxe PBS.
+- Mudar comportamento observavel de projetos existentes.
+- Refatorar todo o backend junto da extracao.
+
+## Arquivos e componentes a inspecionar
+
+- `prometeu-compiler/frontends/prometeu-frontend-pbs/...PBSFrontendPhaseService...`
+- `prometeu-compiler/prometeu-build-pipeline/src/main/java/p/studio/compiler/backend/irvm/LowerToIRVMService.java`
+- `docs/specs/compiler/16. Runtime Execution and Initialization Specification.md`
+- `docs/specs/compiler/20. IRBackend to IRVM Lowering Specification.md`
+- `docs/specs/compiler-languages/pbs/13. Lowering IRBackend Specification.md`
+
+## Alteracoes propostas
+
+Opcao A: frontend PBS emite declaracoes neutras de lifecycle e backend/common assembler monta o entrypoint.
+
+Opcao B: manter montagem no PBS por enquanto, mas isolar regras comuns em um servico compartilhado chamado pelo PBS.
+
+Recomendacao inicial: extrair primeiro o servico comum com testes de caracterizacao, depois migrar o PBS para produzir apenas declaracoes.
+
+## Estrategia de implementacao
+
+Identificar fixture positiva atual, proteger com teste, criar contrato comum minimo, mover validacoes universais e manter mensagens PBS onde forem sintaxe/semantica da linguagem.
+
+## Testes necessarios
+
+- Lifecycle valido PBS continua gerando mesmo PBX/IRVM.
+- Lifecycle ausente ou frame invalido falha no nivel comum quando aplicavel.
+- Teste de IR comum com lifecycle sem parser PBS.
+
+## Criterios de aceitacao
+
+- PBS traduz a forma da linguagem para declaracoes neutras.
+- Servico comum valida e monta lifecycle da plataforma.
+
+## Riscos
+
+- Mover validacoes PBS-especificas para camada comum por engano.
+- Alterar ordem de inicializadores sem perceber.
+
+## Decisoes que devem ser registradas
+
+- Nome e ownership do servico comum.
+- Forma canonica das declaracoes de lifecycle.
+- Separacao entre erro de linguagem e erro de plataforma.
+

discussion/workflow/agendas/AGD-0063-multi-frontend-validation-boundaries.md

@@ -0,0 +1,76 @@
+---
+id: AGD-0063
+ticket: multi-frontend-validation-boundaries
+title: Separar validacoes de linguagem e validacoes de plataforma
+status: open
+created: 2026-07-15
+resolved:
+decision:
+tags: [compiler, compiler-general, compiler-pbs, backend, validation, multi-frontend]
+---
+
+# Agenda - Separar validacoes de linguagem e plataforma
+
+## Objetivo
+
+Domain owner: `compiler/general`, com impacto em `compiler/pbs`.
+
+Definir onde cada validacao deve viver: PBS para sintaxe e semantica da linguagem; compiler core/backend para entrypoints, exports, hostcalls, capabilities, layouts, IR e bytecode.
+
+## Contexto atual
+
+O PBS concentra parsing, semantica, lowering e algumas validacoes que podem ser universais. O backend ja possui validadores para IRVM, bytecode e precondicoes de lowering.
+
+## Escopo
+
+- Mapear diagnostics e validacoes atuais.
+- Classificar cada uma como linguagem ou plataforma.
+- Definir regra: colocar a validacao no nivel mais baixo que a compreende sem conhecer a linguagem.
+
+## Fora de escopo
+
+- Reescrever todas as mensagens diagnosticas.
+- Mudar codigos de erro sem necessidade.
+- Transferir validacoes antes de existir contrato comum suficiente.
+
+## Arquivos e componentes a inspecionar
+
+- `prometeu-compiler/frontends/prometeu-frontend-pbs/src/main/java/p/studio/compiler/pbs/semantics/...`
+- `prometeu-compiler/prometeu-build-pipeline/src/main/java/p/studio/compiler/backend/...`
+- `prometeu-compiler/prometeu-build-pipeline/src/test/java/p/studio/compiler/backend/...`
+- `docs/specs/compiler/19. Verification and Safety Checks Specification.md`
+- `docs/specs/compiler-languages/pbs/12. Diagnostics Specification.md`
+
+## Alteracoes propostas
+
+Opcao A: criar matriz de ownership de validacoes antes de mover codigo.
+
+Opcao B: mover validacoes junto com lifecycle/IR quando cada fronteira for tocada.
+
+Recomendacao inicial: matriz primeiro; migracao so quando uma decisao posterior fechar lifecycle e IR.
+
+## Estrategia de implementacao
+
+Auditar testes de erro existentes, agrupar por origem, decidir ownership e adicionar testes de regressao para impedir que o backend importe PBS.
+
+## Testes necessarios
+
+- Testes PBS para erros de sintaxe/semantica continuam no frontend.
+- Testes comuns para IR malformada, hostcall inexistente, export duplicado e lifecycle invalido.
+- Teste arquitetural de ausencia de imports PBS em validadores comuns.
+
+## Criterios de aceitacao
+
+- Validacoes da plataforma sao expressas sem conceitos PBS.
+- Validacoes PBS continuam preservadas e especificas.
+
+## Riscos
+
+- Perder qualidade de diagnostico ao mover validacao para camada comum.
+- Duplicar validacoes em vez de estabelecer ownership.
+
+## Decisoes que devem ser registradas
+
+- Matriz de validacoes e ownership.
+- Politica de diagnosticos quando o erro comum ainda precisa de source span de frontend.
+

discussion/workflow/agendas/AGD-0064-multi-frontend-sdk-canonical-definition.md

@@ -0,0 +1,78 @@
+---
+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.
+

discussion/workflow/agendas/AGD-0065-multi-frontend-pvm-neutrality.md

@@ -0,0 +1,78 @@
+---
+id: AGD-0065
+ticket: multi-frontend-pvm-neutrality
+title: Neutralidade da PVM e identificacao PBX independente de PBS
+status: open
+created: 2026-07-15
+resolved:
+decision:
+tags: [vm-arch, runtime, pvm, pbx, compiler, multi-frontend]
+---
+
+# Agenda - Manter a PVM neutra
+
+## Objetivo
+
+Domain owner: `vm-arch`, com impacto em `compiler/general`.
+
+Garantir que a PVM conheca apenas PBX/IRVM e conceitos runtime neutros, incluindo identificacao correta do formato como `PBX`/`PBX\0`, nao `PBS`.
+
+## Contexto atual
+
+O documento e focado no Studio, mas runtime neutrality e uma fronteira transversal. A PVM nao deve conhecer `PBS service`, `PBS struct`, `PBS optional` ou qualquer conceito de linguagem.
+
+## Escopo
+
+- Auditar nomenclatura e imports runtime/PVM disponiveis no repo.
+- Verificar magic/header de PBX quando o codigo estiver no workspace.
+- Confirmar que linguagem e convertida antes da execucao.
+
+## Fora de escopo
+
+- Modificar a PVM se o acoplamento estiver apenas no Studio ou compiler.
+- Alterar ISA sem necessidade.
+- Adicionar suporte a qualquer linguagem nova.
+
+## Arquivos e componentes a inspecionar
+
+- `docs/vm-arch/ARCHITECTURE.md`
+- `docs/vm-arch/ISA_CORE.md`
+- `docs/specs/compiler/15. Bytecode and PBX Mapping Specification.md`
+- `prometeu-compiler/prometeu-build-pipeline/src/main/java/p/studio/compiler/backend/bytecode/...`
+- runtime/PVM em repositorio ou modulo relacionado, quando presente
+
+## Alteracoes propostas
+
+Opcao A: auditoria documental e de codigo para nomes PBS indevidos em runtime/bytecode.
+
+Opcao B: corrigir imediatamente apenas identificacao `PBS` vs `PBX` se houver bug confirmado e isolado.
+
+Recomendacao inicial: auditar primeiro; corrigir somente caso a fronteira esteja claramente violada e a mudanca seja pequena.
+
+## Estrategia de implementacao
+
+Buscar termos PBS no runtime, bytecode e specs VM; classificar ocorrencias validas de docs historicas vs erros de contrato.
+
+## Testes necessarios
+
+- Teste de magic/header PBX.
+- Teste arquitetural impedindo imports PBS no runtime/PVM.
+- Teste de carregamento/verificacao de programa sem dependencia de linguagem.
+
+## Criterios de aceitacao
+
+- PVM nao depende de conceitos PBS.
+- Formato executavel e tratado como PBX.
+- Qualquer correcao runtime necessaria fica separada de refactors Studio/compiler.
+
+## Riscos
+
+- Confundir nomenclatura documental antiga com acoplamento real.
+- Expandir escopo para VM quando o problema pertence ao compiler.
+
+## Decisoes que devem ser registradas
+
+- Lista de conceitos permitidos na PVM.
+- Politica de nomenclatura PBX/PBS.
+- Onde ficam testes de neutralidade runtime.
+

discussion/workflow/agendas/AGD-0066-multi-frontend-synthetic-test-frontend.md

@@ -0,0 +1,77 @@
+---
+id: AGD-0066
+ticket: multi-frontend-synthetic-test-frontend
+title: Frontend sintetico de teste para provar neutralidade do pipeline
+status: open
+created: 2026-07-15
+resolved:
+decision:
+tags: [compiler, compiler-general, frontend, tests, backend, multi-frontend]
+---
+
+# Agenda - Criar um frontend sintetico de teste
+
+## Objetivo
+
+Domain owner: `compiler/general`.
+
+Discutir um frontend exclusivo de testes que prove que o pipeline comum nao depende implicitamente do PBS.
+
+## Contexto atual
+
+O criterio arquitetural final exige que um frontend sintetico implemente contratos equivalentes a `FrontendProvider`, `FrontendSpec` e `FrontendCompiler`, produza IR comum minima e passe pelo backend ate PBX/verifier.
+
+## Escopo
+
+- Escolher entre frontend totalmente sintetico ou extensao ficticia.
+- Definir fixture de IR minima com `frame` vazio.
+- Garantir isolamento em testes.
+
+## Fora de escopo
+
+- Expor frontend sintetico no Studio.
+- Criar segunda linguagem real.
+- Criar parser completo ou grammar dummy complexa.
+
+## Arquivos e componentes a inspecionar
+
+- `prometeu-compiler/prometeu-frontend-registry/...`
+- `prometeu-compiler/prometeu-build-pipeline/...`
+- testes do build pipeline e backend
+- `prometeu-studio/src/main/java/p/studio/projects/...` apenas se a selecao por extensao for exercitada
+
+## Alteracoes propostas
+
+Opcao A: provider sintetico que ignora arquivos e retorna IR minima diretamente.
+
+Opcao B: extensao `.dummy` reconhecida em fixture, com conteudo ignorado ou trivial.
+
+Recomendacao inicial: preferir Opcao A para provar neutralidade do pipeline sem criar outra superficie de linguagem.
+
+## Estrategia de implementacao
+
+Esperar provider/IR/lifecycle estarem suficientemente definidos, entao adicionar fixture de teste que registra provider sintetico e executa pipeline comum sem PBS.
+
+## Testes necessarios
+
+- Provider registrado e resolvido por `languageId`.
+- Extensao/source handling testado se a opcao B for escolhida.
+- IR comum produzida, lifecycle montado, IRVM gerado, PBX emitido e verificado.
+
+## Criterios de aceitacao
+
+- Teste falha se pipeline comum instanciar PBS implicitamente.
+- Synthetic frontend existe apenas em test fixtures.
+- PBS nao e afetado.
+
+## Riscos
+
+- Fixture sintetica exercitar caminho feliz pequeno demais e nao proteger acoplamentos reais.
+- Virar uma segunda linguagem informal.
+
+## Decisoes que devem ser registradas
+
+- Forma do frontend sintetico.
+- Escopo minimo da IR fixture.
+- Onde o provider de teste pode ser registrado.
+

discussion/workflow/agendas/AGD-0067-multi-frontend-architectural-tests.md

@@ -0,0 +1,79 @@
+---
+id: AGD-0067
+ticket: multi-frontend-architectural-tests
+title: Testes arquiteturais para fronteiras multi-frontend
+status: open
+created: 2026-07-15
+resolved:
+decision:
+tags: [compiler, compiler-general, studio, frontend, architecture, tests, multi-frontend]
+---
+
+# Agenda - Criar testes arquiteturais
+
+## Objetivo
+
+Domain owner: `compiler/general`, com impacto em `studio` e `vm-arch`.
+
+Definir testes que protejam fronteiras: backend comum sem PBS, IR comum sem AST PBS, Studio comum sem instanciacao PBS fora do composition root e runtime neutro.
+
+## Contexto atual
+
+O repo ja tem testes Java para backend, bytecode e IRVM. ArchUnit pode ser util, mas o alinhamento proibe adicionar biblioteca arquitetural quando testes simples bastarem.
+
+## Escopo
+
+- Escolher ferramenta minima.
+- Definir regras por pacote.
+- Adicionar testes que sejam baratos e claros.
+
+## Fora de escopo
+
+- Cobrir toda arquitetura do monorepo.
+- Adicionar ArchUnit sem justificativa concreta.
+- Bloquear referencias PBS em testes PBS ou no frontend PBS.
+
+## Arquivos e componentes a inspecionar
+
+- `build.gradle.kts` e version catalog se houver.
+- `prometeu-compiler/prometeu-build-pipeline/src/test/java/...`
+- `prometeu-compiler/frontends/prometeu-frontend-pbs/src/test/java/...`
+- `prometeu-studio/src/test/java/...`
+- pacotes runtime/PVM quando presentes
+
+## Alteracoes propostas
+
+Opcao A: testes Java/reflection simples para imports, nomes de tipos e packages publicos.
+
+Opcao B: ArchUnit caso a quantidade de regras e modulos justifique.
+
+Recomendacao inicial: comecar com testes simples; reavaliar ArchUnit se as regras virarem frageis.
+
+## Estrategia de implementacao
+
+Definir allowlist de packages PBS, composition root e testes PBS. Escrever verificacoes independentes por dominio para falhas legiveis.
+
+## Testes necessarios
+
+- Backend/common nao importa `frontend.pbs`, `parser.pbs` ou `semantic.pbs`.
+- IR comum nao expoe tipos PBS.
+- Studio comum nao instancia servicos PBS fora da allowlist.
+- Runtime nao usa nomenclatura ou semantica PBS.
+
+## Criterios de aceitacao
+
+- Regras rodam no build local.
+- Falhas apontam arquivo/pacote responsavel.
+- Excecoes autorizadas estao documentadas.
+
+## Riscos
+
+- Teste textual produzir falso positivo por docs ou fixtures.
+- Criar barreira rigida antes de definir provider e lifecycle.
+
+## Decisoes que devem ser registradas
+
+- Ferramenta escolhida.
+- Allowlist de packages.
+- Ordem de introducao das regras.
+

discussion/workflow/agendas/AGD-0068-multi-frontend-avoid-premature-abstractions.md

@@ -0,0 +1,77 @@
+---
+id: AGD-0068
+ticket: multi-frontend-avoid-premature-abstractions
+title: Evitar abstracoes prematuras na preparacao multi-frontend
+status: open
+created: 2026-07-15
+resolved:
+decision:
+tags: [compiler, compiler-general, studio, frontend, architecture, multi-frontend, simplicity]
+---
+
+# Agenda - Evitar abstracoes prematuras
+
+## Objetivo
+
+Domain owner: `compiler/general`, com impacto em `studio`.
+
+Definir limites para a preparacao multi-frontend: remover acoplamento com baixo custo sem construir marketplace, hot reload, RPC, sandbox ou infraestrutura generica antes da necessidade real.
+
+## Contexto atual
+
+O PBS continuara sendo o unico frontend implementado no curto prazo. O objetivo e preparar contratos, fronteiras e testes de neutralidade, nao criar uma plataforma completa de plugins.
+
+## Escopo
+
+- Estabelecer principios para as agendas derivadas.
+- Definir o que e explicitamente proibido nesta fase.
+- Criar criterio para rejeitar abstracoes sem uso real.
+
+## Fora de escopo
+
+- Plugin marketplace.
+- Carregamento dinamico de JARs.
+- RPC, sockets, process supervisor ou version negotiation complexa.
+- Service locator global.
+
+## Arquivos e componentes a inspecionar
+
+- `prometeu-compiler/prometeu-frontend-registry/...`
+- `prometeu-app/src/main/java/p/studio/AppContainer.java`
+- `prometeu-studio/src/main/java/p/studio/...`
+- planos futuros derivados das discussions multi-frontend
+
+## Alteracoes propostas
+
+Opcao A: registrar esta decisao como guardrail transversal antes das demais.
+
+Opcao B: deixar cada agenda repetir suas restricoes locais.
+
+Recomendacao inicial: criar uma decisao curta e transversal apos discussao, para guiar provider, language services, synthetic frontend e testes arquiteturais.
+
+## Estrategia de implementacao
+
+Transformar o alinhamento em criterios de review: interface pequena, registro explicito, DI/composicao, records imutaveis e testes; rejeitar infra que nao seja exigida pelo PBS ou pelo frontend sintetico de teste.
+
+## Testes necessarios
+
+- Nao ha teste direto para simplicidade, mas plans devem incluir criterio de aceite contra reflection/scanning/RPC quando aplicavel.
+- Testes arquiteturais podem proteger contra service locator global ou acoplamentos indevidos.
+
+## Criterios de aceitacao
+
+- Plans derivados nao introduzem infraestrutura de plugin antes da necessidade.
+- Registro manual do PBS e suficiente.
+- O frontend sintetico prova neutralidade sem virar plataforma externa.
+
+## Riscos
+
+- Usar "evitar abstracao" como desculpa para manter acoplamento PBS.
+- Criar contratos tao pequenos que precisem ser quebrados imediatamente.
+
+## Decisoes que devem ser registradas
+
+- Guardrails obrigatorios para esta fase.
+- Lista de mecanismos proibidos.
+- Criterio para aceitar uma nova abstracao.
+