---
id: AGD-0063
ticket: multi-frontend-validation-boundaries
title: Separar validacoes de linguagem e validacoes de plataforma
status: open
created: 2026-07-15
resolved:
decision:
tags: [compiler, compiler-general, compiler-pbs, backend, validation, multi-frontend]
---

# Agenda - Separar validacoes de linguagem e plataforma

## Objetivo

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

Definir onde cada validacao deve viver: PBS para sintaxe e semantica da linguagem; compiler core/backend para entrypoints, exports, hostcalls, capabilities, layouts, IR e bytecode.

## Contexto atual

O PBS concentra parsing, semantica, lowering e algumas validacoes que podem ser universais. O backend ja possui validadores para IRVM, bytecode e precondicoes de lowering.

## Escopo

- Mapear diagnostics e validacoes atuais.
- Classificar cada uma como linguagem ou plataforma.
- Definir regra: colocar a validacao no nivel mais baixo que a compreende sem conhecer a linguagem.

## Fora de escopo

- Reescrever todas as mensagens diagnosticas.
- Mudar codigos de erro sem necessidade.
- Transferir validacoes antes de existir contrato comum suficiente.

## Arquivos e componentes a inspecionar

- `prometeu-compiler/frontends/prometeu-frontend-pbs/src/main/java/p/studio/compiler/pbs/semantics/...`
- `prometeu-compiler/prometeu-build-pipeline/src/main/java/p/studio/compiler/backend/...`
- `prometeu-compiler/prometeu-build-pipeline/src/test/java/p/studio/compiler/backend/...`
- `docs/specs/compiler/19. Verification and Safety Checks Specification.md`
- `docs/specs/compiler-languages/pbs/12. Diagnostics Specification.md`

## Alteracoes propostas

Opcao A: criar matriz de ownership de validacoes antes de mover codigo.

Opcao B: mover validacoes junto com lifecycle/IR quando cada fronteira for tocada.

Recomendacao inicial: matriz primeiro; migracao so quando uma decisao posterior fechar lifecycle e IR.

## Estrategia de implementacao

Auditar testes de erro existentes, agrupar por origem, decidir ownership e adicionar testes de regressao para impedir que o backend importe PBS.

## Testes necessarios

- Testes PBS para erros de sintaxe/semantica continuam no frontend.
- Testes comuns para IR malformada, hostcall inexistente, export duplicado e lifecycle invalido.
- Teste arquitetural de ausencia de imports PBS em validadores comuns.

## Criterios de aceitacao

- Validacoes da plataforma sao expressas sem conceitos PBS.
- Validacoes PBS continuam preservadas e especificas.

## Riscos

- Perder qualidade de diagnostico ao mover validacao para camada comum.
- Duplicar validacoes em vez de estabelecer ownership.

## Decisoes que devem ser registradas

- Matriz de validacoes e ownership.
- Politica de diagnosticos quando o erro comum ainda precisa de source span de frontend.