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

95 lines
3.9 KiB
Markdown

---
id: AGD-0057
ticket: multi-frontend-provider-contract
title: Introduzir provider completo de frontend
status: accepted
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.
## Resolucao aceita
O contrato deve ser introduzido como `FrontendProvider`.
Responsabilidades minimas:
- expor a especificacao do frontend por `specification()`;
- expor o compilador ou fase de compilacao equivalente por `compiler()`;
- expor servicos editoriais por `languageService()` somente como capacidade opcional, quando necessaria para o Studio.
O contrato nao deve incluir descoberta dinamica de plugins, reflection, classpath scanning ou carregamento externo de JARs.
O registro inicial deve continuar explicito no composition root da aplicacao, com `prometeu-app/src/main/java/p/studio/AppContainer.java` como ponto preferencial de composicao. Codigo comum deve consumir o provider via `registry.require(languageId)` e nao deve instanciar diretamente classes PBS, incluindo `PBSFrontendPhaseService`.
PBS permanece o unico provider inicial. Nenhum frontend real novo deve ser criado por esta frente.