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