prometeu-studio/discussion/workflow/agendas/AGD-0060-multi-frontend-frontend-backend-contract.md
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
multi FE adjustment agendas
2026-07-15 07:58:23 +01:00

79 lines
2.9 KiB
Markdown

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