From 35b65bb524c36a887671aaf2acbfdb8ac262ebde Mon Sep 17 00:00:00 2001 From: bQUARKz Date: Wed, 15 Jul 2026 07:58:23 +0100 Subject: [PATCH] multi FE adjustment agendas --- discussion/index.ndjson | 14 +++- ...D-0057-multi-frontend-provider-contract.md | 79 +++++++++++++++++++ ...-frontend-compiler-vs-language-services.md | 78 ++++++++++++++++++ ...0059-multi-frontend-remove-pbs-branches.md | 78 ++++++++++++++++++ ...ulti-frontend-frontend-backend-contract.md | 78 ++++++++++++++++++ ...AGD-0061-multi-frontend-serializable-ir.md | 76 ++++++++++++++++++ ...GD-0062-multi-frontend-common-lifecycle.md | 77 ++++++++++++++++++ ...63-multi-frontend-validation-boundaries.md | 76 ++++++++++++++++++ ...multi-frontend-sdk-canonical-definition.md | 78 ++++++++++++++++++ .../AGD-0065-multi-frontend-pvm-neutrality.md | 78 ++++++++++++++++++ ...-multi-frontend-synthetic-test-frontend.md | 77 ++++++++++++++++++ ...0067-multi-frontend-architectural-tests.md | 79 +++++++++++++++++++ ...i-frontend-avoid-premature-abstractions.md | 77 ++++++++++++++++++ 13 files changed, 944 insertions(+), 1 deletion(-) create mode 100644 discussion/workflow/agendas/AGD-0057-multi-frontend-provider-contract.md create mode 100644 discussion/workflow/agendas/AGD-0058-multi-frontend-compiler-vs-language-services.md create mode 100644 discussion/workflow/agendas/AGD-0059-multi-frontend-remove-pbs-branches.md create mode 100644 discussion/workflow/agendas/AGD-0060-multi-frontend-frontend-backend-contract.md create mode 100644 discussion/workflow/agendas/AGD-0061-multi-frontend-serializable-ir.md create mode 100644 discussion/workflow/agendas/AGD-0062-multi-frontend-common-lifecycle.md create mode 100644 discussion/workflow/agendas/AGD-0063-multi-frontend-validation-boundaries.md create mode 100644 discussion/workflow/agendas/AGD-0064-multi-frontend-sdk-canonical-definition.md create mode 100644 discussion/workflow/agendas/AGD-0065-multi-frontend-pvm-neutrality.md create mode 100644 discussion/workflow/agendas/AGD-0066-multi-frontend-synthetic-test-frontend.md create mode 100644 discussion/workflow/agendas/AGD-0067-multi-frontend-architectural-tests.md create mode 100644 discussion/workflow/agendas/AGD-0068-multi-frontend-avoid-premature-abstractions.md diff --git a/discussion/index.ndjson b/discussion/index.ndjson index abde7b95..339be458 100644 --- a/discussion/index.ndjson +++ b/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":[]} diff --git a/discussion/workflow/agendas/AGD-0057-multi-frontend-provider-contract.md b/discussion/workflow/agendas/AGD-0057-multi-frontend-provider-contract.md new file mode 100644 index 00000000..d193aeae --- /dev/null +++ b/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. + diff --git a/discussion/workflow/agendas/AGD-0058-multi-frontend-compiler-vs-language-services.md b/discussion/workflow/agendas/AGD-0058-multi-frontend-compiler-vs-language-services.md new file mode 100644 index 00000000..8ee45c2e --- /dev/null +++ b/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`. + +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. + diff --git a/discussion/workflow/agendas/AGD-0059-multi-frontend-remove-pbs-branches.md b/discussion/workflow/agendas/AGD-0059-multi-frontend-remove-pbs-branches.md new file mode 100644 index 00000000..966bf7e9 --- /dev/null +++ b/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. + diff --git a/discussion/workflow/agendas/AGD-0060-multi-frontend-frontend-backend-contract.md b/discussion/workflow/agendas/AGD-0060-multi-frontend-frontend-backend-contract.md new file mode 100644 index 00000000..2ba5ade4 --- /dev/null +++ b/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. + diff --git a/discussion/workflow/agendas/AGD-0061-multi-frontend-serializable-ir.md b/discussion/workflow/agendas/AGD-0061-multi-frontend-serializable-ir.md new file mode 100644 index 00000000..88ab15b8 --- /dev/null +++ b/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. + diff --git a/discussion/workflow/agendas/AGD-0062-multi-frontend-common-lifecycle.md b/discussion/workflow/agendas/AGD-0062-multi-frontend-common-lifecycle.md new file mode 100644 index 00000000..c9fdb893 --- /dev/null +++ b/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. + diff --git a/discussion/workflow/agendas/AGD-0063-multi-frontend-validation-boundaries.md b/discussion/workflow/agendas/AGD-0063-multi-frontend-validation-boundaries.md new file mode 100644 index 00000000..3859831d --- /dev/null +++ b/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. + diff --git a/discussion/workflow/agendas/AGD-0064-multi-frontend-sdk-canonical-definition.md b/discussion/workflow/agendas/AGD-0064-multi-frontend-sdk-canonical-definition.md new file mode 100644 index 00000000..e9a9545b --- /dev/null +++ b/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. + diff --git a/discussion/workflow/agendas/AGD-0065-multi-frontend-pvm-neutrality.md b/discussion/workflow/agendas/AGD-0065-multi-frontend-pvm-neutrality.md new file mode 100644 index 00000000..c023f48c --- /dev/null +++ b/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. + diff --git a/discussion/workflow/agendas/AGD-0066-multi-frontend-synthetic-test-frontend.md b/discussion/workflow/agendas/AGD-0066-multi-frontend-synthetic-test-frontend.md new file mode 100644 index 00000000..14de0a7e --- /dev/null +++ b/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. + diff --git a/discussion/workflow/agendas/AGD-0067-multi-frontend-architectural-tests.md b/discussion/workflow/agendas/AGD-0067-multi-frontend-architectural-tests.md new file mode 100644 index 00000000..6e47d875 --- /dev/null +++ b/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. + diff --git a/discussion/workflow/agendas/AGD-0068-multi-frontend-avoid-premature-abstractions.md b/discussion/workflow/agendas/AGD-0068-multi-frontend-avoid-premature-abstractions.md new file mode 100644 index 00000000..a7033734 --- /dev/null +++ b/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. +