added PRs

docs/pbs/pull-requests/INDEX.md

@@ -92,3 +92,14 @@ Esta trilha organiza as PRs por ondas para execucao incremental com rollback sim
 6. `PR-O4.6-strict-bytecode-precheck-unknown-opcode-rejection.md`
 7. `PR-O4.7-gate-i-runtime-backed-execution-adapter.md`
 8. `PR-O4.8-jvm-grade-regression-matrix-and-golden-artifacts.md`
+
+### Onda O5 - JVM-Grade Score Evolution (5.6 -> 8.5+)
+
+1. `PR-05.1-pbs-frontend-semantic-executable-lowering-cfg.md`
+2. `PR-05.2-irbackend-callsite-classification-by-semantic-identity.md`
+3. `PR-05.3-irvm-deterministic-function-id-and-entrypoint-policy.md`
+4. `PR-05.4-irvm-program-coherence-without-bypass.md`
+5. `PR-05.5-irvm-validator-real-stack-effects-hostcall-intrinsic.md`
+6. `PR-05.6-optimize-irvm-real-deterministic-passes.md`
+7. `PR-05.7-gate-i-runtime-backed-mandatory-in-ci.md`
+8. `PR-05.8-backend-spec-to-test-conformance-matrix.md`

docs/pbs/pull-requests/PR-05.1-pbs-frontend-semantic-executable-lowering-cfg.md

@@ -0,0 +1,67 @@
+# PR-05.1 - PBS Frontend Semantic Executable Lowering (CFG)
+
+## Briefing
+
+O frontend PBS ainda gera `IRBackendExecutableFunction` por varredura de callsites no AST, o que perde semântica de execução real.
+
+Esta PR substitui esse caminho por lowering semântico baseado em fluxo de controle (CFG), preservando ordem de execução, terminadores e formas de desvio.
+
+## Motivation
+
+### Dor atual que esta PR resolve
+
+1. Execução divergente entre programa fonte e artefato gerado em cenários com `if`, `while`, `for`, `switch`, `handle` e `return` antecipado.
+2. Impossibilidade de elevar o backend para JVM-grade porque o contrato executável nasce semanticamente incompleto.
+3. Falsos positivos de conformidade: testes passam para casos lineares, mas o modelo quebra em fluxo real.
+
+## Target
+
+Esta PR altera o frontend PBS para que `IRBackendExecutableFunction.instructions` represente fluxo executável real, não apenas uma lista de chamadas encontradas.
+
+## Scope
+
+1. Gerador de IR executável no frontend PBS.
+2. Emissão de labels e jumps para estruturas de controle.
+3. Recalculo de `maxStackSlots` com base no fluxo emitido.
+4. Testes de fidelidade semântica do FE para IR executável.
+
+## Non-Goals
+
+1. Não introduz otimizações.
+2. Não altera formato binário PBX.
+3. Não altera runtime.
+
+## Method
+
+### O que deve ser feito explicitamente
+
+1. Substituir o mecanismo de `collectCallsFrom*` por lowering orientado a nós semânticos de statements/expressions.
+2. Emitir instruções de controle (`LABEL`, `JMP`, `JMP_IF_TRUE`, `JMP_IF_FALSE`, `RET`) para cada forma de fluxo suportada.
+3. Garantir que `return` termine bloco/caminho e que caminhos alcançáveis terminem em instrução terminadora.
+4. Preservar spans de origem em cada instrução emitida para diagnóstico.
+5. Manter validação fail-fast quando existir forma semântica não lowerável em v1.
+6. Atualizar análise de stack para operar sobre o programa realmente emitido.
+
+## Acceptance Criteria
+
+1. `IRBackendExecutableFunction` deixa de ser construído por varredura cega de callsites.
+2. Para casos com ramificação e laço, a ordem de execução no IR executável é semanticamente equivalente ao AST validado.
+3. Funções com `return` antecipado não emitem execução espúria após ponto de saída.
+4. `maxStackSlots` calculado bate com programa emitido e passa em validação backend.
+5. Diagnósticos de lowering preservam fase e span corretamente.
+
+## Tests
+
+1. Testes positivos com fixtures de `if/else`, `while`, `for`, `switch`, `handle`, `return` antecipado.
+2. Testes negativos para caminhos sem terminador, labels inválidos e formas não suportadas.
+3. Teste de regressão comparando resultado anterior vs novo para provar correção em casos não lineares.
+
+## Affected Documents
+
+1. `docs/pbs/specs/13. Lowering IRBackend Specification.md`
+2. `docs/general/specs/20. IRBackend to IRVM Lowering Specification.md`
+3. `docs/general/specs/19. Verification and Safety Checks Specification.md`
+
+## Open Questions
+
+Sem bloqueios arquiteturais. Implementação deve seguir decisões já fechadas na Agenda 18.

docs/pbs/pull-requests/PR-05.2-irbackend-callsite-classification-by-semantic-identity.md

@@ -0,0 +1,62 @@
+# PR-05.2 - IRBackend Callsite Classification by Semantic Identity
+
+## Briefing
+
+A classificação de callsites no frontend executável ainda depende de heurística textual de callee.
+
+Esta PR torna obrigatória a classificação por identidade semântica resolvida no binding, eliminando inferência por nome/forma textual.
+
+## Motivation
+
+### Dor atual que esta PR resolve
+
+1. Risco de classificar callsite no bucket errado (`CALL_FUNC`, `CALL_HOST`, `CALL_INTRINSIC`).
+2. Ambiguidade em member/bind/group callee com nome coincidente.
+3. Falta de robustez em evolução de sintaxe semântica do FE.
+
+## Target
+
+Fronteira `PBS FE -> IRBackend` com identidade de callsite estável e sem heurística textual para decisão de categoria.
+
+## Scope
+
+1. Resultado de resolução semântica para chamadas.
+2. Estrutura de lowering para carregar identidade resolvida.
+3. Diagnósticos quando identidade não estiver resolvida no ponto exigido.
+
+## Non-Goals
+
+1. Não muda política de overload além do já definido em semântica.
+2. Não introduz novas categorias de callsite.
+
+## Method
+
+### O que deve ser feito explicitamente
+
+1. Propagar do analisador semântico para lowering um descritor explícito de destino de chamada.
+2. Remover dependência de `extractSimpleCalleeName` para classificação.
+3. Exigir que cada callsite emitido em `IRBackend` esteja em exatamente uma categoria válida.
+4. Emitir erro determinístico quando o FE não possuir identidade semântica suficiente para classificar o callsite.
+5. Validar compatibilidade de metadados obrigatórios por categoria no ato de emissão.
+
+## Acceptance Criteria
+
+1. Classificação de callsite não depende de parsing textual de callee.
+2. Cada callsite em `IRBackend` possui categoria única e metadados obrigatórios.
+3. Casos ambíguos geram diagnóstico estável em fase correta, sem fallback heurístico.
+4. Não há regressão em casos já válidos.
+
+## Tests
+
+1. Testes positivos para chamadas de função, host e intrínseco com diferentes formas sintáticas.
+2. Testes negativos de ambiguidade e callee não resolvido.
+3. Testes de estabilidade diagnóstica (code/phase/span).
+
+## Affected Documents
+
+1. `docs/pbs/specs/13. Lowering IRBackend Specification.md`
+2. `docs/general/specs/20. IRBackend to IRVM Lowering Specification.md`
+
+## Open Questions
+
+Sem bloqueios arquiteturais.

docs/pbs/pull-requests/PR-05.3-irvm-deterministic-function-id-and-entrypoint-policy.md

@@ -0,0 +1,61 @@
+# PR-05.3 - IRVM Deterministic Function-ID and Entrypoint Policy
+
+## Briefing
+
+A regra de indexação de funções e seleção de entrypoint precisa ficar estritamente alinhada ao contrato normativo para evitar divergência entre builds equivalentes.
+
+Esta PR fecha política determinística de `func_id` e entrypoint único explícito.
+
+## Motivation
+
+### Dor atual que esta PR resolve
+
+1. Possível variação de `func_id` quando ordem de merge muda.
+2. Risco de entrypoint implícito ou ambíguo.
+3. Dificuldade para gerar artefatos reproduzíveis e goldens estáveis.
+
+## Target
+
+`LowerToIRVMService` com regra única e testável de ordenação/indexação/entrypoint.
+
+## Scope
+
+1. Ordenação determinística de funções.
+2. Política explícita de entrypoint.
+3. Diagnóstico para ausência ou ambiguidade de entrypoint.
+
+## Non-Goals
+
+1. Não altera ABI de chamada.
+2. Não altera layout binário do bytecode.
+
+## Method
+
+### O que deve ser feito explicitamente
+
+1. Definir ordenação canônica apenas pelos campos normativos aprovados.
+2. Exigir exatamente um entrypoint válido no grafo admitido.
+3. Atribuir `func_id=0` ao entrypoint e indexar demais por ordem canônica.
+4. Rejeitar determinísticamente casos sem entrypoint ou com entrypoint múltiplo.
+5. Cobrir cenários de permutação de entrada com mesma saída de indexação.
+
+## Acceptance Criteria
+
+1. Mesma entrada admitida gera mesma tabela de `func_id` em execuções repetidas.
+2. Mudança na ordem de merge dos módulos não altera indexação final.
+3. Ausência ou ambiguidade de entrypoint falha com diagnóstico estável.
+
+## Tests
+
+1. Teste de determinismo com permutação de ordem de merge.
+2. Teste de entrypoint único válido.
+3. Testes negativos para zero entrypoint e múltiplos entrypoints.
+
+## Affected Documents
+
+1. `docs/general/specs/20. IRBackend to IRVM Lowering Specification.md`
+2. `docs/general/specs/19. Verification and Safety Checks Specification.md`
+
+## Open Questions
+
+Sem bloqueios arquiteturais.

docs/pbs/pull-requests/PR-05.4-irvm-program-coherence-without-bypass.md

@@ -0,0 +1,61 @@
+# PR-05.4 - IRVM Program Coherence Without Bypass
+
+## Briefing
+
+Existe bypass de coerência no `IRVMProgram` em presença de `RAW_SYSCALL` e derivação com placeholders (`__unknown__`).
+
+Esta PR remove esses atalhos do fluxo canônico e endurece o contrato de coerência `IRVM <-> EmissionPlan`.
+
+## Motivation
+
+### Dor atual que esta PR resolve
+
+1. Programa pode aparentar coerente e mesmo assim carregar informação inválida para emissão.
+2. Brecha para mascarar erro estrutural antes do Gate de emissão/verificação.
+3. Diagnóstico tardio e pouco preciso para falhas de marshaling.
+
+## Target
+
+`IRVMProgram` com coerência obrigatória, sem exceção silenciosa para formas proibidas no pipeline canônico.
+
+## Scope
+
+1. Regras de coerência no construtor e no `coherentEmissionPlan()`.
+2. Eliminação de placeholder de syscall desconhecida em caminho de derivação canônico.
+3. Taxonomia de erro para incoerência estrutural.
+
+## Non-Goals
+
+1. Não muda verificador runtime.
+2. Não muda decisão de proibir `RAW_SYSCALL` em pre-load.
+
+## Method
+
+### O que deve ser feito explicitamente
+
+1. Remover condição que pula validação de coerência quando detecta `RAW_SYSCALL`.
+2. Tornar inválido no caminho canônico qualquer plano com operação proibida para pre-load.
+3. Remover geração de `HOSTCALL` com `SyscallDecl("__unknown__",...)` em derivação automática.
+4. Falhar cedo com erro determinístico e mensagem orientada a ação.
+
+## Acceptance Criteria
+
+1. `IRVMProgram` nunca retorna plano incoerente no fluxo canônico.
+2. Não existe mais derivação com placeholders desconhecidos para hostcall.
+3. Erros de coerência aparecem antes da emissão binária.
+
+## Tests
+
+1. Testes negativos para `RAW_SYSCALL` no plano e para hostcall sem metadado válido.
+2. Testes de regressão para caminhos válidos existentes.
+3. Testes de estabilidade de códigos de erro.
+
+## Affected Documents
+
+1. `docs/general/specs/15. Bytecode and PBX Mapping Specification.md`
+2. `docs/general/specs/20. IRBackend to IRVM Lowering Specification.md`
+3. `docs/general/specs/19. Verification and Safety Checks Specification.md`
+
+## Open Questions
+
+Sem bloqueios arquiteturais.

docs/pbs/pull-requests/PR-05.5-irvm-validator-real-stack-effects-hostcall-intrinsic.md

@@ -0,0 +1,61 @@
+# PR-05.5 - IRVM Validator Real Stack Effects for HOSTCALL and INTRINSIC
+
+## Briefing
+
+O validador IRVM hoje modela `HOSTCALL` e `INTRINSIC` com efeito de stack genérico insuficiente para rigor JVM-grade.
+
+Esta PR passa a validar efeitos reais de stack por assinatura (`arg_slots`/`ret_slots`) nessas operações.
+
+## Motivation
+
+### Dor atual que esta PR resolve
+
+1. Possíveis underflow/overflow não detectados em chamadas host/intrínseco.
+2. Retorno efetivo divergente sem falha no precheck.
+3. Confiança excessiva na emissão sem validação semântica de pilha completa.
+
+## Target
+
+`IRVMValidator` e metadados de operação com informação suficiente para calcular efeito real de stack.
+
+## Scope
+
+1. Modelo de metadados para chamadas host e intrínseco no estágio IRVM.
+2. Regras de validação de stack baseadas em assinatura.
+3. Diagnósticos determinísticos de mismatch.
+
+## Non-Goals
+
+1. Não define política de otimização.
+2. Não altera opcode wire format.
+
+## Method
+
+### O que deve ser feito explicitamente
+
+1. Introduzir acesso a `arg_slots`/`ret_slots` efetivos durante validação de `HOSTCALL`.
+2. Introduzir contrato equivalente para `INTRINSIC` (a partir de tabela canônica no pipeline).
+3. Aplicar stack effect real no data-flow do validador.
+4. Rejeitar mismatch de altura de retorno em joins e `RET` final.
+5. Preservar mensagens de erro estáveis na taxonomia `MARSHAL_VERIFY_PRECHECK_*`.
+
+## Acceptance Criteria
+
+1. `HOSTCALL` e `INTRINSIC` participam do cálculo real de pilha no validador.
+2. Casos de mismatch de assinatura falham no precheck com erro determinístico.
+3. Casos válidos seguem aprovando sem regressão.
+
+## Tests
+
+1. Testes positivos com combinações de arg/ret slots para host e intrínsecos.
+2. Testes negativos para underflow, overflow e retorno incompatível.
+3. Testes de join mismatch com chamadas em blocos ramificados.
+
+## Affected Documents
+
+1. `docs/general/specs/20. IRBackend to IRVM Lowering Specification.md`
+2. `docs/general/specs/19. Verification and Safety Checks Specification.md`
+
+## Open Questions
+
+Sem bloqueios arquiteturais.

docs/pbs/pull-requests/PR-05.6-optimize-irvm-real-deterministic-passes.md

@@ -0,0 +1,67 @@
+# PR-05.6 - OptimizeIRVM Real Deterministic Passes
+
+## Briefing
+
+A etapa `OptimizeIRVM` está corretamente posicionada no pipeline, mas ainda opera como `NoOp`.
+
+Esta PR introduz o primeiro conjunto de passes reais, seguros e determinísticos, mantendo equivalência semântica e compatibilidade de perfil.
+
+## Motivation
+
+### Dor atual que esta PR resolve
+
+1. Etapa de otimização existe formalmente, mas não entrega valor técnico.
+2. Difícil sustentar evolução de performance e limpeza de IRVM sem regressão.
+3. Falta de contrato de execução de pass manager com evidência forte.
+
+## Target
+
+`OptimizeIRVMService` com pass manager produtivo e baseline de passes v1.
+
+## Scope
+
+1. Pass manager determinístico com ordem estável.
+2. Passes iniciais semânticamente conservadores.
+3. Validação antes/depois de cada pass.
+
+## Non-Goals
+
+1. Não inclui otimizações agressivas interprocedurais.
+2. Não inclui JIT/runtime optimization.
+
+## Method
+
+### O que deve ser feito explicitamente
+
+1. Implementar baseline de passes v1:
+   - eliminação de bloco inalcançável,
+   - normalização de labels redundantes,
+   - simplificação de salto para próximo PC.
+2. Manter invariantes obrigatórias:
+   - sem mudança de `vm_profile`,
+   - sem introdução de opcode fora do perfil,
+   - sem alteração de contratos de slots/retorno observáveis.
+3. Validar programa antes e após cada pass.
+4. Registrar nome/ordem de pass para rastreabilidade de regressão.
+
+## Acceptance Criteria
+
+1. `OptimizeIRVM` deixa de ser apenas `NoOp` no caminho padrão.
+2. Mesma entrada produz mesma saída otimizada (determinismo).
+3. Testes de equivalência semântica passam para fixtures representativas.
+4. Nenhum pass viola perfil de VM ou contrato de emissão.
+
+## Tests
+
+1. Testes unitários por pass com entradas mínimas e edge cases.
+2. Testes de pipeline comparando saída otimizada vs não otimizada para equivalência.
+3. Testes negativos para pass que tenta alterar perfil/semântica.
+
+## Affected Documents
+
+1. `docs/general/specs/21. IRVM Optimization Pipeline Specification.md`
+2. `docs/general/specs/19. Verification and Safety Checks Specification.md`
+
+## Open Questions
+
+Sem bloqueios arquiteturais para baseline v1.

docs/pbs/pull-requests/PR-05.7-gate-i-runtime-backed-mandatory-in-ci.md

@@ -0,0 +1,60 @@
+# PR-05.7 - Gate I Runtime-Backed Mandatory in CI
+
+## Briefing
+
+O harness de compatibilidade runtime-backed pode cair para `local-fallback` quando comando não está configurado.
+
+Esta PR separa modo dev e modo CI, tornando obrigatório runtime-backed real em CI para suportar claim forte de conformidade.
+
+## Motivation
+
+### Dor atual que esta PR resolve
+
+1. Falsa sensação de conformidade quando ambiente cai para fallback local.
+2. Regressões de integração com runtime real podem passar despercebidas.
+3. Evidência de Gate I fica fraca para suporte externo.
+
+## Target
+
+Pipeline de testes com política explícita: em CI, fallback local não é aceito para Gate I.
+
+## Scope
+
+1. Política de execução do adapter runtime-backed.
+2. Configuração de CI para `PROMETEU_RUNTIME_CHECK_CMD`.
+3. Diagnóstico claro quando runtime-backed obrigatório não está ativo.
+
+## Non-Goals
+
+1. Não altera runtime.
+2. Não remove adapter local para uso de desenvolvimento.
+
+## Method
+
+### O que deve ser feito explicitamente
+
+1. Introduzir flag de modo estrito para Gate I em CI.
+2. Em modo estrito, falhar teste se adapter entrar em `local-fallback`.
+3. Publicar comando e contrato mínimo do check runtime em pipeline.
+4. Preservar modo permissivo local para desenvolvimento fora de CI.
+
+## Acceptance Criteria
+
+1. CI falha se Gate I não executar em modo runtime-backed real.
+2. Execução local mantém fallback disponível quando não for modo estrito.
+3. Resultado de Gate I reporta claramente `adapterMode` e motivo.
+
+## Tests
+
+1. Teste de modo estrito com comando ausente deve falhar.
+2. Teste de modo estrito com comando válido deve passar.
+3. Regressão local em modo não estrito permanece funcional.
+
+## Affected Documents
+
+1. `docs/general/specs/19. Verification and Safety Checks Specification.md`
+2. `docs/general/specs/13. Conformance Test Specification.md`
+
+## Open Questions
+
+Sem bloqueios arquiteturais.

docs/pbs/pull-requests/PR-05.8-backend-spec-to-test-conformance-matrix.md

@@ -0,0 +1,65 @@
+# PR-05.8 - Backend Spec-to-Test Conformance Matrix
+
+## Briefing
+
+Falta uma matriz única ligando cada MUST normativo de backend aos testes que provam conformidade.
+
+Esta PR cria a matriz de rastreabilidade para `18.1`, `18.2`, `18.3`, specs `19`, `20`, `21` e Gate I/S-U.
+
+## Motivation
+
+### Dor atual que esta PR resolve
+
+1. Dificuldade de provar cobertura de conformidade por requisito.
+2. Buracos de teste ficam escondidos por ausência de rastreabilidade.
+3. Evolução de arquitetura sem visão clara de impacto em evidência.
+
+## Target
+
+Artefato de conformidade auditável que mapeia requisito -> teste positivo -> teste negativo -> status.
+
+## Scope
+
+1. Matriz normativa de backend FE/BE.
+2. Classificação de status por requisito (`pass`, `missing`, `partial`, `deferred`).
+3. Regra de atualização obrigatória da matriz em toda PR backend relevante.
+
+## Non-Goals
+
+1. Não cria nova semântica de linguagem.
+2. Não substitui specs normativas.
+
+## Method
+
+### O que deve ser feito explicitamente
+
+1. Criar documento de matriz em `docs/general/specs` ou `docs/pbs/specs` com tabela por requisito normativo.
+2. Para cada MUST, vincular explicitamente:
+   - teste(s) positivo(s),
+   - teste(s) negativo(s),
+   - módulo/classe de teste,
+   - status atual.
+3. Adicionar quality gate de revisão: PR backend sem atualização da matriz deve ser rejeitada quando impactar conformidade.
+4. Definir procedimento de manutenção para não deixar entradas órfãs.
+
+## Acceptance Criteria
+
+1. Todo MUST de `19`, `20`, `21` e addendum executável de `13` aparece na matriz.
+2. Cada item tem referência concreta a teste ou marcação explícita de ausência.
+3. Revisão de PR consegue identificar rapidamente gaps de conformidade.
+
+## Tests
+
+1. Não exige testes executáveis novos por si só.
+2. Exige checagem de integridade da matriz em revisão CI/lint documental.
+
+## Affected Documents
+
+1. `docs/general/specs/19. Verification and Safety Checks Specification.md`
+2. `docs/general/specs/20. IRBackend to IRVM Lowering Specification.md`
+3. `docs/general/specs/21. IRVM Optimization Pipeline Specification.md`
+4. `docs/pbs/specs/13. Lowering IRBackend Specification.md`
+
+## Open Questions
+
+Sem bloqueios arquiteturais.