prometeu-studio/docs/pbs/agendas/13.3. Conformance Workshop 3 - Artifact-Level Conformance and Fixtures.md

PBS Conformance Workshop 3

Status: Active

Purpose

Run the third focused discussion for 13. Conformance Test Specification.md on artifact-level testing and fixtures:

• when artifact goldens become mandatory,
• which invariants are asserted,
• and how stdlib, host-registry, capability, and runtime fixtures are modeled.

Why This Slice Third

This slice should come after the source-level oracle is stable and after lowering discussions have progressed enough to identify meaningful artifact obligations.

Proposed Meeting Order

1. Reconfirm the claim taxonomy and source-level baseline.
2. Decide when artifact-level conformance becomes required.
3. Decide which artifact invariants are testable at conformance level.
4. Decide the minimum fixture model for stdlib and host-backed scenarios.
5. Record regression and compatibility consequences for Workshop 4.

Decisions To Produce

1. The role of artifact-level conformance in PBS v1.
2. The minimum fixture model for reserved stdlib and host-backed scenarios.
3. The artifact oracle boundary between 13, 12, and 15.
4. The runtime-line assumptions fixtures must encode.

Candidate Decisions

1. Artifact-Level Conformance Belongs Only To Full Toolchain Claims

Candidate direction:

• frontend-only and source-runtime claims do not require artifact goldens,
• full toolchain claims do.

Rationale:

• This keeps staged conformance honest and tractable.

2. Conformance Should Assert Invariants, Not One Entire Binary Snapshot

Candidate direction:

• artifact tests should assert stable invariants such as presence, dedup, ordering rules, and canonical identity mappings,
• not one complete opaque binary image unless later needed.

Rationale:

• This is more robust across legitimate implementation variation.

3. Fixtures Must Model Real Resolved Environments

Candidate direction:

• conformance fixtures must explicitly model: selected stdlib environment, host registry line, granted capabilities, and runtime line where relevant.

Rationale:

• These affect observable acceptance and lowering behavior.

Questions To Resolve In The Room

1. Does full conformance need binary goldens or only invariant checks?
2. What is the smallest honest fixture model for host-backed tests?
3. Should stdlib fixtures be versioned as part of the conformance corpus?
4. How much loader behavior must be simulated in conformance?
5. Which artifact guarantees are stable enough today to test?

Expected Outputs

1. a decision record for artifact-level conformance scope,
2. a fixture model draft for 13,
3. and integration tasks for 12, 15, and 17.

Explicit Deferrals For Workshop 4

• regression policy over time,
• compatibility-matrix assertions,
• and published behavior preservation.

Inputs

• docs/pbs/specs/12. IR and Lowering Specification.md
• docs/pbs/specs/13. Conformance Test Specification.md
• docs/pbs/specs/15. Bytecode and PBX Mapping Specification.md
• docs/pbs/specs/17. Compatibility and Evolution Policy.md
• docs/pbs/agendas/12.4. IR and Lowering Workshop 4 - Builtins, Host Bindings, and Artifact Invariants.md
• docs/pbs/agendas/13.2. Conformance Workshop 2 - Source-Level Oracle and Diagnostic Oracle.md