---
id: AGD-0060
ticket: multi-frontend-frontend-backend-contract
title: Estabilizar contrato entre frontend e backend comum
status: open
created: 2026-07-15
resolved:
decision:
tags: [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.