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