prometeu-studio/discussion/workflow/agendas/AGD-0068-multi-frontend-avoid-premature-abstractions.md

id	ticket	title	status	created	resolved	decision	tags
AGD-0068	multi-frontend-avoid-premature-abstractions	Evitar abstracoes prematuras na preparacao multi-frontend	open	2026-07-15			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.