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
78 lines
2.7 KiB
Markdown
78 lines
2.7 KiB
Markdown
---
|
|
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.
|
|
|