prometeu-studio/discussion/workflow/agendas/AGD-0060-multi-frontend-frontend-backend-contract.md

id	ticket	title	status	created	resolved	decision	tags
AGD-0060	multi-frontend-frontend-backend-contract	Estabilizar contrato entre frontend e backend comum	open	2026-07-15			compiler compiler-general compiler-pbs ir backend multi-frontend

Agenda - Estabilizar o contrato entre frontend e backend

Objetivo

Domain owner: compiler/general, com impacto em compiler/pbs.

Definir o limite exato entre frontend e backend para garantir que o backend receba IR comum, e nao AST, tokens, simbolos ou objetos semanticos PBS.

Contexto atual

As specs citam IRBackend como handoff executavel em docs/specs/compiler/20. IRBackend to IRVM Lowering Specification.md e docs/specs/compiler-languages/pbs/13. Lowering IRBackend Specification.md. Testes como IRBackendExecutableContractTest e LowerToIRVMServiceTest ja sugerem um contrato backend direto.

Escopo

• Auditar tipos publicos de IRBackend e modelos associados.
• Confirmar se a estrutura atual ja representa uma IR comum.
• Identificar qualquer dependencia em AST ou semantica PBS no backend.

Fora de escopo

• Renomear IRBackend por preferencia estetica.
• Redesenhar o lowering para IRVM.
• Implementar serializacao.

Arquivos e componentes a inspecionar

• prometeu-compiler/prometeu-build-pipeline/src/main/java/p/studio/compiler/models/...
• prometeu-compiler/prometeu-build-pipeline/src/main/java/p/studio/compiler/backend/...
• prometeu-compiler/frontends/prometeu-frontend-pbs/...
• docs/specs/compiler/20. IRBackend to IRVM Lowering Specification.md
• docs/specs/compiler-languages/pbs/13. Lowering IRBackend Specification.md

Alteracoes propostas

Opcao A: manter IRBackend e documentar/adaptar o contrato como Prometeu Frontend IR.

Opcao B: criar um novo nome de dominio quando houver divergencia real entre modelo atual e fronteira desejada.

Recomendacao inicial: auditar antes de renomear; mudar nomes so quando o modelo atual impedir clareza operacional.

Estrategia de implementacao

Listar campos e tipos transitivos da IR, classificar cada item como comum ou especifico de PBS, e planejar extracoes pequenas para qualquer vazamento.

Testes necessarios

• Teste construindo IR comum diretamente sem parser PBS.
• Teste de backend sem imports de packages PBS.
• Teste negativo para tipos AST PBS no contrato publico da IR.

Criterios de aceitacao

• Backend e testavel com IR montada manualmente.
• Contrato contem modulos, funcoes, tipos, blocos, calls, exports, lifecycle, spans, diagnostics e capabilities em termos neutros.
• Contrato nao contem PbsExpression, PbsStatement, PbsToken ou equivalentes.

Riscos

• Confundir IR comum com modelo de lowering interno de PBS.
• Quebrar fixtures existentes por mudanca ampla demais.

Decisoes que devem ser registradas

• Nome normativo do handoff.
• Lista de tipos permitidos no contrato.
• Limite entre spec geral e spec PBS.