implements PLN-0117

discussion/index.ndjson

@@ -7,7 +7,7 @@
 {"type":"discussion","id":"DSC-0060","status":"open","ticket":"multi-frontend-validation-boundaries","title":"Separar validacoes de linguagem e validacoes de plataforma","created_at":"2026-07-15","updated_at":"2026-07-15","tags":["compiler","compiler-general","compiler-pbs","backend","validation","multi-frontend"],"agendas":[{"id":"AGD-0063","file":"AGD-0063-multi-frontend-validation-boundaries.md","status":"open","created_at":"2026-07-15","updated_at":"2026-07-15"}],"decisions":[],"plans":[],"lessons":[]}
 {"type":"discussion","id":"DSC-0059","status":"open","ticket":"multi-frontend-common-lifecycle","title":"Extrair lifecycle comum das responsabilidades do frontend PBS","created_at":"2026-07-15","updated_at":"2026-07-15","tags":["compiler","compiler-general","compiler-pbs","lifecycle","backend","multi-frontend"],"agendas":[{"id":"AGD-0062","file":"AGD-0062-multi-frontend-common-lifecycle.md","status":"open","created_at":"2026-07-15","updated_at":"2026-07-15"}],"decisions":[],"plans":[],"lessons":[]}
 {"type":"discussion","id":"DSC-0058","status":"open","ticket":"multi-frontend-serializable-ir","title":"Manter a IR comum serializavel por design","created_at":"2026-07-15","updated_at":"2026-07-15","tags":["compiler","compiler-general","ir","backend","serialization","multi-frontend"],"agendas":[{"id":"AGD-0061","file":"AGD-0061-multi-frontend-serializable-ir.md","status":"open","created_at":"2026-07-15","updated_at":"2026-07-15"}],"decisions":[],"plans":[],"lessons":[]}
-{"type":"discussion","id":"DSC-0057","status":"in_progress","ticket":"multi-frontend-frontend-backend-contract","title":"Estabilizar contrato entre frontend e backend comum","created_at":"2026-07-15","updated_at":"2026-07-15","tags":["compiler","compiler-general","compiler-pbs","ir","backend","multi-frontend"],"agendas":[{"id":"AGD-0060","file":"AGD-0060-multi-frontend-frontend-backend-contract.md","status":"accepted","created_at":"2026-07-15","updated_at":"2026-07-15"}],"decisions":[{"id":"DEC-0043","file":"DEC-0043-common-irbackend-frontend-backend-handoff.md","status":"accepted","created_at":"2026-07-15","updated_at":"2026-07-15","ref_agenda":"AGD-0060"}],"plans":[{"id":"PLN-0117","file":"PLN-0117-common-irbackend-contract-specs.md","status":"open","created_at":"2026-07-15","updated_at":"2026-07-15","ref_decisions":["DEC-0043"]},{"id":"PLN-0118","file":"PLN-0118-common-irbackend-backend-guardrails.md","status":"open","created_at":"2026-07-15","updated_at":"2026-07-15","ref_decisions":["DEC-0043"]}],"lessons":[]}
+{"type":"discussion","id":"DSC-0057","status":"in_progress","ticket":"multi-frontend-frontend-backend-contract","title":"Estabilizar contrato entre frontend e backend comum","created_at":"2026-07-15","updated_at":"2026-07-15","tags":["compiler","compiler-general","compiler-pbs","ir","backend","multi-frontend"],"agendas":[{"id":"AGD-0060","file":"AGD-0060-multi-frontend-frontend-backend-contract.md","status":"accepted","created_at":"2026-07-15","updated_at":"2026-07-15"}],"decisions":[{"id":"DEC-0043","file":"DEC-0043-common-irbackend-frontend-backend-handoff.md","status":"accepted","created_at":"2026-07-15","updated_at":"2026-07-15","ref_agenda":"AGD-0060"}],"plans":[{"id":"PLN-0117","file":"PLN-0117-common-irbackend-contract-specs.md","status":"done","created_at":"2026-07-15","updated_at":"2026-07-15","ref_decisions":["DEC-0043"]},{"id":"PLN-0118","file":"PLN-0118-common-irbackend-backend-guardrails.md","status":"open","created_at":"2026-07-15","updated_at":"2026-07-15","ref_decisions":["DEC-0043"]}],"lessons":[]}
 {"type":"discussion","id":"DSC-0056","status":"done","ticket":"multi-frontend-remove-pbs-branches","title":"Generalizar o contrato LSP/editorial para frontends","created_at":"2026-07-15","updated_at":"2026-07-15","tags":["compiler","compiler-general","compiler-pbs","studio","frontend","coupling","multi-frontend"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0058","file":"discussion/lessons/DSC-0056-multi-frontend-remove-pbs-branches/LSN-0058-generic-frontend-editorial-contract-for-lsp.md","status":"done","created_at":"2026-07-15","updated_at":"2026-07-15"}]}
 {"type":"discussion","id":"DSC-0055","status":"done","ticket":"multi-frontend-compiler-vs-language-services","title":"Separar compilacao de servicos editoriais de frontend","created_at":"2026-07-15","updated_at":"2026-07-15","tags":["compiler","compiler-general","studio","lsp","editor","frontend","multi-frontend"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0056","file":"discussion/lessons/DSC-0055-multi-frontend-compiler-vs-language-services/LSN-0056-compile-first-frontends-with-optional-editorial-capabilities.md","status":"done","created_at":"2026-07-15","updated_at":"2026-07-15"}]}
 {"type":"discussion","id":"DSC-0054","status":"done","ticket":"multi-frontend-provider-contract","title":"Introduzir provider completo de frontend","created_at":"2026-07-15","updated_at":"2026-07-15","tags":["compiler","compiler-general","studio","frontend","registry","multi-frontend"],"agendas":[],"decisions":[],"plans":[],"lessons":[{"id":"LSN-0055","file":"discussion/lessons/DSC-0054-multi-frontend-provider-contract/LSN-0055-static-frontend-providers-before-plugin-architecture.md","status":"done","created_at":"2026-07-15","updated_at":"2026-07-15"}]}

discussion/workflow/plans/PLN-0117-common-irbackend-contract-specs.md

@@ -2,7 +2,7 @@
 id: PLN-0117
 ticket: multi-frontend-frontend-backend-contract
 title: Common IRBackend contract specs
-status: open
+status: done
 created: 2026-07-15
 ref_decisions: [DEC-0043]
 tags: [compiler, compiler-general, compiler-pbs, ir, backend, multi-frontend]
@@ -77,12 +77,12 @@ Included:
 
 ## Acceptance Criteria
 
-- [ ] Compiler-general specs state that `IRBackend` is the common frontend-to-backend executable handoff.
+- [x] Compiler-general specs state that `IRBackend` is the common frontend-to-backend executable handoff.
-- [ ] Compiler-general specs do not describe common backend behavior as PBS-owned.
+- [x] Compiler-general specs do not describe common backend behavior as PBS-owned.
-- [ ] PBS lowering specs describe how PBS emits `IRBackend` and defer common backend obligations to compiler-general specs.
+- [x] PBS lowering specs describe how PBS emits `IRBackend` and defer common backend obligations to compiler-general specs.
-- [ ] Forbidden coupling is explicit for PBS AST, tokens, parser structures, semantic objects, editorial objects, and future frontend equivalents.
+- [x] Forbidden coupling is explicit for PBS AST, tokens, parser structures, semantic objects, editorial objects, and future frontend equivalents.
-- [ ] Lifecycle, published entrypoint, boot guard, spans, and capabilities are written in neutral terms when they are backend obligations.
+- [x] Lifecycle, published entrypoint, boot guard, spans, and capabilities are written in neutral terms when they are backend obligations.
-- [ ] Conformance matrix maps DEC-0043 obligations to tests or planned tests without weakening existing coverage.
+- [x] Conformance matrix maps DEC-0043 obligations to tests or planned tests without weakening existing coverage.
 
 ## Tests
 

docs/specs/compiler-languages/pbs/13. Lowering IRBackend Specification.md

@@ -1,13 +1,13 @@
 # PBS Lowering IRBackend Specification
 
-Status: Draft v1 (Frontend Scope + Backend Handoff Addendum)  
+Status: Draft v1 (PBS Frontend Scope + Common Handoff Emission)  
-Applies to: first lowering boundary from bound PBS frontend model into `IRBackend`/`IRBackendFile`, plus executable-backend handoff obligations at this boundary
+Applies to: first lowering boundary from bound PBS frontend model into the common `IRBackend`/`IRBackendFile` handoff
 
 ## 1. Purpose
 
-This document defines the normative frontend lowering contract from PBS source semantics to `IRBackend`.
+This document defines the normative frontend lowering contract from PBS source semantics to the common `IRBackend` handoff.
 
-Its purpose is to keep the first lowering deterministic and shared across implementations while PBS and backend design evolve.
+Its purpose is to keep PBS lowering deterministic while preserving the common frontend-to-backend contract owned by compiler-general backend specs.
 
 ## 2. Scope
 
@@ -18,7 +18,7 @@ This document defines:
 - semantic obligations preserved in `IRBackend`,
 - deterministic rejection behavior for unsupported frontend-lowering forms,
 - diagnostics attribution obligations for lowering failures in frontend scope,
-- executable-backend handoff obligations at the `IRBackend` boundary,
+- PBS obligations for emitting the common executable `IRBackend` handoff,
 - and backend-owned symbolic lowering obligations for asset-facing references.
 
 This document does not define:
@@ -26,7 +26,8 @@ This document does not define:
 - VM lowering (`IRVM`),
 - bytecode/PBX mapping,
 - runtime execution behavior,
-- verifier/loader internals.
+- verifier/loader internals,
+- or common backend ownership of the `IRBackend -> IRVM` contract.
 
 Those concerns belong to shared acceptance specs under `docs/specs/compiler`.
 
@@ -75,9 +76,9 @@ When the active source slice depends on a backend-owned symbolic surface such as
 - the frontend must not query domain services directly to discover operational assets;
 - and lowering must preserve enough identity for the backend to complete final operational resolution.
 
-## 6. IRBackend Preserved Obligations
+## 6. PBS IRBackend Emission Obligations
 
-For each admitted source unit and callable in the current lowering slice, `IRBackend` must preserve at minimum:
+For each admitted PBS source unit and callable in the current lowering slice, PBS lowering must emit `IRBackend` that preserves at minimum:
 
 1. callable identity (name/category as applicable),
 2. callable arity,
@@ -93,6 +94,8 @@ Lowering must not collapse source categories in a way that erases required decla
 
 The normative contract is obligation-based, not tied to one mandatory in-memory class graph.
 
+`IRBackend` itself is the common frontend-to-backend executable handoff. This PBS spec owns only the PBS-specific admission and translation path into that handoff. Common backend rules for consuming `IRBackend` are owned by `docs/specs/compiler/20. IRBackend to IRVM Lowering Specification.md`.
+
 ## 7. Deterministic Rejection Policy
 
 If a source form is outside current frontend-lowering support:
@@ -111,7 +114,7 @@ For multi-module builds, lowering admission must apply dependency-scoped fail-fa
 
 ## 8. Conformance Boundary
 
-`IRBackend` is the first lowering boundary (frontend responsibility).
+PBS emission into `IRBackend` is the first PBS lowering boundary (frontend responsibility).
 
 Conformance-valid claims at this boundary require Gate U evidence from `docs/specs/compiler/13. Conformance Test Specification.md`.
 
@@ -148,9 +151,9 @@ This document is healthy when:
 3. deterministic rejection policy is explicit and test-backed,
 4. and scope boundaries with general/backend acceptance specs are explicit.
 
-## 12. Executable Backend Handoff Addendum (v1)
+## 12. PBS Executable Handoff Emission Obligations (v1)
 
-For executable backends, the `IRBackend` output from this frontend boundary must satisfy the additional handoff obligations below.
+For executable backends, PBS lowering must emit `IRBackend` satisfying the additional handoff obligations below before common backend lowering starts.
 
 ### 12.1 Callable obligations
 
@@ -170,7 +173,7 @@ Each executable callsite in `IRBackend` must be classified into exactly one cate
 2. `CALL_HOST`,
 3. `CALL_INTRINSIC`.
 
-Backend lowering must not infer this category by textual heuristics.
+PBS lowering must not leave this category for backend inference by textual heuristics.
 
 ### 12.3 Host-backed metadata obligations
 
@@ -187,11 +190,11 @@ When a host-backed callsite also depends on backend-owned symbolic asset lowerin
 - the frontend boundary MUST preserve which callsite argument is asset-facing;
 - for PBS v1 this asset-facing designation is carried by reserved host metadata `[AssetLowering(param = N)]`;
 - the preserved symbolic operand MUST remain attributable to a backend-provided `Addressable` identity;
-- backend stages MUST be able to rewrite that symbolic operand into runtime-facing `asset_id` before the final low-level host path is emitted.
+- common backend stages MUST be able to rewrite that symbolic operand into runtime-facing `asset_id` before the final low-level host path is emitted.
 
 When an expression statement leaves a materialized runtime value on the stack:
 
-- `IRBackend` lowering MUST emit explicit discard behavior rather than relying on implicit backend stack cleanup;
+- PBS lowering into `IRBackend` MUST emit explicit discard behavior rather than relying on implicit backend stack cleanup;
 - for single-slot materialized values this discard is represented by `POP`;
 - and the discard path MUST preserve stack-accounting validity for subsequent backend lowering stages.
 
@@ -220,7 +223,7 @@ It does not replace:
 
 ### 12.7 Executable Lifecycle and Published Wrapper Obligation
 
-For executable PBS frontends, backend handoff must preserve the compiler-selected published wrapper rather than a frontend-declared nominal entrypoint.
+For executable PBS frontends, PBS lowering must preserve the compiler-selected published wrapper rather than a frontend-declared nominal entrypoint.
 
 At `IRBackend` emission time:
 
@@ -230,8 +233,8 @@ At `IRBackend` emission time:
    - module init,
    - project init when present,
    - and the published frame wrapper,
-2. the published frame wrapper must be the effective entrypoint identity handed to backend stages,
+2. the published frame wrapper must be the effective entrypoint identity handed to common backend stages,
 3. the userland callable marked with `[Frame]` must remain distinguishable as the logical frame root,
 4. the wrapper must own final `FRAME_RET`,
-5. backend stages must not reintroduce manifest-owned or `FrontendSpec`-owned nominal entrypoint authority,
+5. common backend stages must not reintroduce manifest-owned or `FrontendSpec`-owned nominal entrypoint authority,
 6. and hidden compiler-owned lifecycle state such as the boot guard must remain structurally distinguishable from user globals.

docs/specs/compiler/20. IRBackend to IRVM Lowering Specification.md

@@ -1,7 +1,7 @@
-# PBS IRBackend to IRVM Lowering Specification
+# IRBackend to IRVM Lowering Specification
 
 Status: Draft v1 (Backend Baseline)  
-Applies to: executable-backend lowering from `IRBackend` handoff into `IRVM`
+Applies to: executable-backend lowering from the common `IRBackend` handoff into `IRVM`
 
 ## 1. Purpose
 
@@ -9,11 +9,14 @@ This document defines the normative lowering contract from executable `IRBackend
 
 Its purpose is to make backend lowering deterministic, reviewable, and compatible with runtime ISA/verification authority.
 
+`IRBackend` is the common frontend-to-backend executable handoff. It is emitted by frontends and consumed by common backend stages. Backend lowering MUST NOT require PBS AST nodes, PBS tokens, PBS parser structures, PBS semantic objects, PBS editorial objects, or equivalent language-owned objects from future frontends.
+
 ## 2. Scope
 
 This document defines:
 
 - required backend preconditions before `IRBackend -> IRVM` starts,
+- allowed language-neutral `IRBackend` contract concepts at the backend boundary,
 - `IRVM` structural obligations needed before optimization/emission,
 - deterministic function-id assignment and control-flow lowering obligations,
 - callsite lowering obligations across function, host-backed, and VM-owned intrinsic paths,
@@ -25,7 +28,8 @@ This document does not define:
 - binary PBX layout details,
 - loader patching internals,
 - runtime execution internals,
-- or one mandatory optimizer implementation.
+- one mandatory optimizer implementation,
+- or frontend-specific lowering rules before `IRBackend` emission.
 
 ## 3. Authority and Precedence
 
@@ -33,8 +37,8 @@ Normative precedence:
 
 1. Runtime authority (`docs/specs/hardware/topics/chapter-2.md`, `chapter-3.md`, `chapter-9.md`, `chapter-12.md`, `chapter-16.md`)
 2. Bytecode authority (`docs/specs/bytecode/ISA_CORE.md`)
-3. `docs/specs/compiler-languages/pbs/13. Lowering IRBackend Specification.md`
+3. This document
-4. This document
+4. Frontend-specific lowering specifications, including `docs/specs/compiler-languages/pbs/13. Lowering IRBackend Specification.md`
 
 If a rule here conflicts with higher-precedence authorities, it is invalid.
 
@@ -42,12 +46,38 @@ If a rule here conflicts with higher-precedence authorities, it is invalid.
 
 This document depends on:
 
-- `docs/specs/compiler-languages/pbs/13. Lowering IRBackend Specification.md`
 - `docs/specs/compiler-languages/pbs/6.1. Intrinsics and Builtin Types Specification.md`
 - `docs/specs/compiler-languages/pbs/6.2. Host ABI Binding and Loader Resolution Specification.md`
+- frontend-specific lowering specifications that emit the common `IRBackend` handoff
 - `15. Bytecode and PBX Mapping Specification.md`
 - `21. IRVM Optimization Pipeline Specification.md`
 
+## 4.1 Common IRBackend Contract
+
+At this boundary, `IRBackend` may contain only language-neutral compiler concepts required by executable backend lowering:
+
+1. source identity and spans,
+2. modules and module identifiers,
+3. callable identities, signatures, names, arity, and type-shape surfaces,
+4. executable functions,
+5. instruction kinds and instruction metadata,
+6. globals and global origins,
+7. synthetic executable functions and synthetic origins,
+8. host-call metadata,
+9. intrinsic metadata,
+10. reserved metadata required for backend lowering,
+11. and required runtime or platform capabilities.
+
+The common backend contract MUST express these concepts as backend obligations, not as PBS syntax or PBS semantic rules. When a concept currently originates from PBS, the backend contract still owns only the language-neutral obligation carried by `IRBackend`.
+
+The common backend contract MUST NOT expose or require:
+
+1. `PbsExpression`, `PbsStatement`, `PbsToken`, or equivalent PBS-owned syntax objects,
+2. PBS parser cursors, parse contexts, parse nodes, or token kinds,
+3. PBS semantic validator internals,
+4. PBS editorial or language-service objects,
+5. or any type under a language frontend package as part of the public backend handoff.
+
 ## 5. Backend Entry Preconditions
 
 Lowering from `IRBackend` to `IRVM` may start only when:
@@ -104,6 +134,8 @@ For PBS executable lowering:
 - the wrapper path must contain final `FRAME_RET`,
 - and lowering must preserve that distinction through `IRVM`.
 
+These PBS-facing names describe the current frontend source of the lifecycle structure. The backend-owned obligation is the neutral requirement that the compiler-selected published wrapper be the physical entrypoint and that lifecycle state remain explicit in `IRBackend`.
+
 ## 9. Callsite Lowering Obligations
 
 ### 9.1 Function calls
@@ -150,7 +182,7 @@ Before bytecode emission, backend must run structural pre-verification on lowere
 7. and structural validity of host/intrinsic call forms.
 8. and structural validity of backend-owned symbolic-to-operational rewrites such as `Addressable -> asset_id`.
 
-For PBS host-backed asset calls in v1, this validation includes the rewrite selected by preserved host metadata such as `[AssetLowering(param = N)]`.
+For host-backed asset calls in v1, this validation includes backend-owned symbolic-to-operational rewrites selected by preserved host metadata. PBS currently emits this designation from metadata such as `[AssetLowering(param = N)]`, but final operational resolution is a common backend obligation.
 
 This pre-verification does not replace runtime verifier authority.
 
@@ -184,4 +216,6 @@ This document is healthy when:
 1. `IRBackend -> IRVM` obligations are explicit and testable,
 2. deterministic function/call/control-flow lowering rules are explicit,
 3. mandatory pre-verification boundary is explicit,
-4. and scope boundaries with optimization/emission specs are explicit.
+4. common backend obligations are not described as owned by PBS,
+5. frontend-specific lowering specs only own emission into `IRBackend`,
+6. and scope boundaries with optimization/emission specs are explicit.

docs/specs/compiler/22. Backend Spec-to-Test Conformance Matrix.md

@@ -3,7 +3,7 @@
 Status: Draft v1 (Traceability Baseline)  
 Applies to: compiler/backend conformance traceability for canonical stage order and entrypoint-specific contracts
 
-Last Updated: 2026-03-30
+Last Updated: 2026-07-15
 
 ## 1. Purpose
 
@@ -13,7 +13,7 @@ This matrix maps each normative backend MUST from:
 2. `docs/specs/compiler/20. IRBackend to IRVM Lowering Specification.md`
 3. `docs/specs/compiler/21. IRVM Optimization Pipeline Specification.md`
 4. `docs/specs/compiler/23. Compiler Pipeline Entry Points Specification.md`
-5. `docs/specs/compiler-languages/pbs/13. Lowering IRBackend Specification.md` (Section 12 addendum only)
+5. `docs/specs/compiler-languages/pbs/13. Lowering IRBackend Specification.md` (PBS lowering obligations only)
 
 to concrete positive/negative test evidence and current status.
 
@@ -56,6 +56,9 @@ to concrete positive/negative test evidence and current status.
 | G20-11.1 | Lowering rejection MUST be deterministic. | `BackendSafetyGateSUTest#lowerStageMustExposeDeterministicFailureCodeForSameInvalidInput` | same | pass |  |
 | G20-11.2 | Diagnostics identity/phase MUST remain stable. | `BackendSafetyGateSUTest#lowerStageMustExposeDeterministicFailureCodeForSameInvalidInput` | `BackendSafetyGateSUTest#emitStageMustExposeMarshalingLinkageFailureDeterministically` | pass | Stable rejection families are exercised. |
 | G20-11.3 | Source attribution MUST be preserved when source-actionable. | `LowerToIRVMPipelineStageTest#runMustAttachSourceAttributionForLoweringFailure`; `LowerToIRVMServiceTest#lowerMustMapHostAndIntrinsicCallsites` | `LowerToIRVMServiceTest#lowerMustRejectMissingCallee` | pass | Stage-level failure now carries explicit `file/start/end` attribution for lowering errors. |
+| G20-4.1.1 | `IRBackend` MUST be the common frontend-to-backend executable handoff. | `LowerToIRVMServiceTest#lowerMustAcceptManuallyConstructedCommonIRBackend` | N/A | missing | Required by DEC-0043; PLN-0118 adds the named evidence. |
+| G20-4.1.2 | Common backend code MUST NOT depend on `p.studio.compiler.pbs`. | `CommonBackendArchitectureTest#commonBackendMustNotImportPbsFrontendPackages` | N/A | missing | Required by DEC-0043; PLN-0118 adds the named evidence. |
+| G20-4.1.3 | Public `IRBackend` contract MUST NOT expose PBS AST, token, parser, semantic, or editorial types. | `IRBackendExecutableContractTest#publicIRBackendContractMustNotExposePbsTypes` | N/A | missing | Required by DEC-0043; PLN-0118 adds the named evidence. |
 | G21-5 | `OptimizeIRVM` MUST NOT be skipped in canonical pipeline order. | `BuilderPipelineServiceOrderTest#canonicalOrderMustContainOptimizeBetweenLowerAndEmit` | N/A | pass | Canonical stage order is enforced. |
 | G21-6.1 | Optimize input MUST satisfy lowering obligations/profile/structural validity. | `OptimizeIRVMPipelineStageTest#runMustAcceptSupportedNonDefaultVmProfile` | `OptimizeIRVMPipelineStageTest#runMustRejectUnsupportedVmProfile` | pass | Input validation occurs before pass execution. |
 | G21-6.2 | Optimize output MUST preserve semantics/contracts and remain emission-valid. | `OptimizeIRVMEquivalenceHarnessTest#optimizeOnOffMustPreserveObservableTraceForLoweredHostIntrinsicFixture`; `OptimizeIRVMEquivalenceHarnessTest#optimizeOnOffMustPreserveObservableTraceForConditionalJoinFixture`; `OptimizeIRVMEquivalenceHarnessTest#optimizeOnOffMustPreserveObservableTraceForSimpleLoopFixture`; `OptimizeIRVMEquivalenceHarnessTest#optimizeOnOffMustPreserveObservableTraceForLinearCallFixture`; `EmitBytecodePipelineStageTest#runMustEmitBytecodeWhenPreconditionsAreSatisfied` | `OptimizeIRVMServiceTest#optimizeMustRejectPassThatMutatesVmProfile` | pass | Equivalence harness now validates on/off semantics and emission validity over CFG corpus with host/intrinsic paths. |
@@ -74,7 +77,7 @@ to concrete positive/negative test evidence and current status.
 | G23-7.1 | `AnalysisSnapshot` MUST expose the minimum shared analysis contract. | `MainProjectPipelineIntegrationTest#analyzeShouldNotWriteProgramBytecode`; `BuilderPipelinePublicSurfaceTest#analysisSnapshotMustExposeMinimumSharedContract` | N/A | pass | Both executable and structural contract checks now cover the shared minimum analysis payload. |
 | G23-8.1 | Caller-specific configs/contexts MUST NOT redefine canonical stage semantics. | N/A | N/A | missing | Requires explicit multi-entrypoint composition tests once non-filesystem contexts are implemented. |
 | G23-9.1 | Legacy public `run` MUST be removed as the normative entrypoint and filesystem-default behavior MUST be expressed through `build`. | `BuilderPipelinePublicSurfaceTest#publicServiceSurfaceMustExposeExplicitEntrypointsAndNoPublicRun`; `MainProjectPipelineIntegrationTest#buildShouldWriteProgramBytecode` | N/A | partial | Public service coverage now proves `run` is no longer public and `build` is the filesystem artifact path, but the CLI composition path is not yet exercised by a dedicated automated test. |
-| PBS13-12.0 | Executable backend handoff MUST satisfy addendum obligations. | `IRBackendExecutableContractTest` suite; `PBSFrontendPhaseServiceTest#shouldSynthesizePositiveTopic19FixtureAcrossFileInitProjectInitAndFrame` | `LowerToIRVMServiceTest#lowerMustRejectWhenSyntheticWrapperEntrypointIsMissing`; `LowerToIRVMServiceTest#lowerMustRejectWhenHiddenBootGuardIsMissing`; `LowerToIRVMServiceTest#lowerMustRejectWhenSyntheticCallableOriginIsMissing` | pass | Row group `PBS13-12.x` details each obligation; topic 19 closure now includes lifecycle wrapper/guard/origin evidence. |
+| PBS13-12.0 | PBS executable lowering MUST emit `IRBackend` satisfying frontend handoff obligations before common backend lowering. | `IRBackendExecutableContractTest` suite; `PBSFrontendPhaseServiceTest#shouldSynthesizePositiveTopic19FixtureAcrossFileInitProjectInitAndFrame` | `LowerToIRVMServiceTest#lowerMustRejectWhenSyntheticWrapperEntrypointIsMissing`; `LowerToIRVMServiceTest#lowerMustRejectWhenHiddenBootGuardIsMissing`; `LowerToIRVMServiceTest#lowerMustRejectWhenSyntheticCallableOriginIsMissing` | pass | Row group `PBS13-12.x` verifies PBS emission into the common handoff; common backend ownership is covered by G20 rows. |
 | PBS13-12.1.1 | Callable identity MUST be preserved at handoff. | `IRBackendExecutableContractTest#aggregatorMustPreserveExecutableFunctionOrderDeterministically` | N/A | pass |  |
 | PBS13-12.1.2 | Observable callable signature MUST be preserved at handoff. | `IRBackendExecutableContractTest#functionContractMustRejectInvalidSlotAndSpanBounds` | N/A | pass |  |
 | PBS13-12.1.3 | Callable category MUST be preserved at handoff. | `PbsFrontendCompilerTest#shouldLowerExecutableFunctionsWithCallsiteCategories` | N/A | pass |  |
@@ -103,7 +106,7 @@ to concrete positive/negative test evidence and current status.
 
 1. Any backend PR that changes conformance-relevant behavior in FE/BE pipeline MUST update this matrix.
 2. If requirement coverage changes, update: mapped tests, status, and `Last Updated` date.
-3. New normative MUSTs in specs `19/20/21` or PBS `13` addendum MUST add a new matrix row before merge.
+3. New normative MUSTs in specs `19/20/21` or PBS `13` lowering obligations MUST add a new matrix row before merge.
 4. Conformance-relevant FE/BE code paths for hard-gate are:
    - `prometeu-compiler/prometeu-build-pipeline/`
    - `prometeu-compiler/frontends/prometeu-frontend-pbs/`