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

id	ticket	title	status	created	resolved	decision	tags
AGD-0057	multi-frontend-provider-contract	Introduzir provider completo de frontend	accepted	2026-07-15			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.