bQUARKz
35b65bb524
All checks were successful
JaCoCo Coverage #### Project Overview
No changes detected, that affect the code coverage.
* Line Coverage: 61.37% (17351/28272)
* Branch Coverage: 52.31% (6722/12850)
* Lines of Code: 28272
* Cyclomatic Complexity: 11325
#### Quality Gates Summary
Output truncated.
Test / Build skipped: 15, passed: 601
Intrepid/Prometeu/Studio/pipeline/head This commit looks good
80 lines
3.0 KiB
Markdown
80 lines
3.0 KiB
Markdown
---
|
|
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.
|
|
|