added agendas

docs/pbs/agendas/11. Diagnostics Agenda.md

@@ -36,6 +36,61 @@ This agenda should keep the diagnostics contract narrow, deterministic, and impl
 4. Which backend-originated failures remain PBS diagnostics versus artifact-tool diagnostics?
 5. Are warnings part of the normative contract at all in v1, and if so which ones?
 
+## Proposed Workshop Sequence
+
+### Workshop 1: Diagnostic Identity and Attribution
+
+Purpose:
+
+- close the minimum diagnostic identity model,
+- close required source-attribution fields,
+- and decide cross-file attribution for import and linking failures.
+
+Expected decisions:
+
+- phase-only versus stable code model,
+- required file/span/note package,
+- and minimum cross-file reporting rules.
+
+### Workshop 2: Wording, Notes, and Help Surface
+
+Purpose:
+
+- decide what human-facing wording is normative,
+- whether notes/help are required anywhere,
+- and where implementation freedom should remain.
+
+Expected decisions:
+
+- wording stability boundary,
+- note/help obligations,
+- and illustrative versus normative examples policy.
+
+### Workshop 3: Cost Diagnostics and Warning Policy
+
+Purpose:
+
+- decide whether warnings are part of v1 conformance at all,
+- and, if yes, which qualitative cost warnings become mandatory.
+
+Expected decisions:
+
+- warning-in-conformance yes or no,
+- mandatory versus optional cost notes,
+- and boundary between diagnostics and profiling/tooling.
+
+### Workshop 4: Backend-Originated Diagnostic Mapping
+
+Purpose:
+
+- decide how lowering, verifier, and load-facing failures map back to the PBS-facing contract.
+
+Expected decisions:
+
+- PBS-facing versus artifact-facing boundary,
+- source-mapping obligations for backend failures,
+- and inputs needed from `12` and `15`.
+
 ## Expected Spec Material
 
 The resulting spec work should be able to add or close sections for:
@@ -68,4 +123,3 @@ The resulting spec work should be able to add or close sections for:
 - `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/agendas/11.1. Diagnostics Workshop 1 - Diagnostic Identity and Attribution.md

@@ -0,0 +1,145 @@
+# PBS Diagnostics Workshop 1
+
+Status: Active
+
+## Purpose
+
+Run the first focused discussion for `11. Diagnostics Specification.md` on the minimum diagnostic contract:
+
+- diagnostic identity,
+- phase attribution,
+- source attribution,
+- and cross-file attribution for import and linking failures.
+
+## Why This Slice First
+
+This slice should come first because every later diagnostics discussion depends on a stable answer to:
+
+- what one diagnostic fundamentally is,
+- what metadata is guaranteed,
+- and what conformance is even allowed to assert.
+
+It should stay narrow and avoid wording or warning policy for now.
+
+## Proposed Meeting Order
+
+1. Reconfirm already-settled rejection and phase facts.
+2. Close the minimum diagnostic identity model.
+3. Close the minimum source-attribution package.
+4. Close cross-file attribution for import, barrel, and linking failures.
+5. Record carry-forward items for wording and warning workshops.
+
+## Already-Settled Inputs To Reconfirm
+
+The meeting should explicitly reaffirm:
+
+- syntax and static semantics already define required rejection classes,
+- manifest/import failures are deterministic compile-time failures,
+- load-facing malformed or unauthorized host usage is deterministic,
+- traps are fatal runtime outcomes rather than ordinary diagnostics,
+- and stable source spans are already required at token and AST level.
+
+These should not be reopened here.
+
+## Decisions To Produce
+
+1. The minimum normative identity of a diagnostic.
+2. The minimum mandatory attribution fields.
+3. Cross-file attribution rules for import and barrel failures.
+4. The smallest stable phase vocabulary diagnostics must expose.
+
+## Candidate Decisions
+
+### 1. Diagnostic Identity Is Phase Plus Stable Class, Not Mandatory Numeric Code
+
+Candidate direction:
+
+- v1 requires deterministic phase attribution and a stable rejection class.
+- A machine-readable code is allowed but not yet mandatory.
+- Human wording is not the identity of the diagnostic.
+
+Rationale:
+
+- This keeps the contract stable without overfitting to one toolchain code system.
+- It leaves room to add codes later without making v1 blocked on taxonomy design.
+
+Alternative to discuss:
+
+- require stable codes now because conformance and tooling benefit from them.
+
+### 2. Minimum Attribution Package Is File, Primary Span, and Message Class
+
+Candidate direction:
+
+- every source-attributable diagnostic must expose:
+  primary file,
+  primary source span or location,
+  stable phase,
+  and enough human-readable content to distinguish the rejection class.
+- secondary notes are optional unless another rule explicitly requires them.
+
+Rationale:
+
+- This matches the current draft while making the required payload explicit.
+
+### 3. Cross-File Failures Need At Least One Primary Site And Optional Related Sites
+
+Candidate direction:
+
+- import failure must point primarily to the importing site,
+- barrel-entry mismatch must point primarily to the barrel site,
+- tools may additionally point to the unresolved or conflicting declaration site when known,
+- but v1 does not require one exact note shape yet.
+
+Rationale:
+
+- This keeps source-facing diagnostics actionable without freezing one multi-span presentation format.
+
+### 4. Keep A Small Stable Phase Vocabulary
+
+Candidate direction:
+
+- the minimum stable external vocabulary is:
+  syntax,
+  static semantics,
+  manifest/import resolution,
+  linking,
+  and host-binding/capability admission.
+- tools may subdivide internally if they map back deterministically.
+
+Rationale:
+
+- This gives `13` enough oracle structure without forcing one compiler pipeline.
+
+## Questions To Resolve In The Room
+
+1. Is phase plus stable class enough, or should v1 require diagnostic codes now?
+2. Must every cross-file failure include more than one source location?
+3. Should `linking` be a diagnostics phase name directly, or only a broader `resolution` bucket?
+4. Are secondary spans purely optional, or mandatory for some classes such as conflicting imports?
+5. What is the minimum conformance-friendly diagnostic payload that is still implementation-neutral?
+
+## Expected Outputs
+
+This workshop should produce:
+
+1. a decision record for diagnostic identity,
+2. a decision record for required attribution fields,
+3. a cross-file attribution policy draft,
+4. and a cleanup list for `11`.
+
+## Explicit Deferrals For Workshop 2
+
+- wording stability,
+- notes/help obligations,
+- warning policy,
+- and backend-originated diagnostic mapping.
+
+## Inputs
+
+- `docs/pbs/specs/11. Diagnostics Specification.md`
+- `docs/pbs/specs/13. Conformance Test Specification.md`
+- `docs/pbs/specs/14. Name Resolution and Module Linking Specification.md`
+- `docs/pbs/agendas/11. Diagnostics Agenda.md`
+- `docs/pbs/agendas/14.4. Name Resolution Workshop 4 - Linking Phase Boundary.md`
+

docs/pbs/agendas/11.2. Diagnostics Workshop 2 - Wording, Notes, and Help Surface.md

@@ -0,0 +1,113 @@
+# PBS Diagnostics Workshop 2
+
+Status: Active
+
+## Purpose
+
+Run the second focused discussion for `11. Diagnostics Specification.md` on the human-facing surface:
+
+- wording stability,
+- required versus optional notes,
+- help text,
+- and the boundary between normative content and tooling freedom.
+
+## Why This Slice Second
+
+This slice should follow Workshop 1 because wording cannot be scoped responsibly until the diagnostic identity and minimum attribution package are already settled.
+
+## Proposed Meeting Order
+
+1. Reconfirm the identity and attribution baseline from Workshop 1.
+2. Close which human-facing wording elements are normative.
+3. Close whether notes and help text are ever required.
+4. Close the illustrative versus normative example policy.
+5. Record warning and backend mapping topics for later workshops.
+
+## Decisions To Produce
+
+1. The normative boundary for human-facing wording.
+2. Whether notes are mandatory for any diagnostic classes.
+3. Whether help text is part of the v1 contract.
+4. Whether example wording in the spec is illustrative or binding.
+
+## Candidate Decisions
+
+### 1. Human Wording Is Illustrative Except For Distinguishing The Rejection Class
+
+Candidate direction:
+
+- wording does not need to be byte-for-byte stable across implementations,
+- but it must remain specific enough to distinguish the rejection class,
+- and it must not contradict the governing spec rule.
+
+Rationale:
+
+- This preserves tool freedom while keeping diagnostics usable.
+
+### 2. Notes Are Optional By Default
+
+Candidate direction:
+
+- notes are optional quality features in v1,
+- except where a later explicit rule may require related-location reporting for a narrow class.
+
+Rationale:
+
+- This keeps conformance small while leaving room for richer UX.
+
+Alternative to discuss:
+
+- require notes for multi-file conflicts because they are otherwise under-attributed.
+
+### 3. Help Text Is Outside Core Conformance
+
+Candidate direction:
+
+- help text, suggestions, and remediation hints are encouraged,
+- but not part of the normative minimum contract.
+
+Rationale:
+
+- This avoids binding the spec to one editorial style or educational approach.
+
+### 4. Spec Examples Are Illustrative Unless Marked Normative
+
+Candidate direction:
+
+- sample messages in `11` are examples only,
+- and the normative content lives in phase, attribution, and class requirements.
+
+Rationale:
+
+- This prevents examples from accidentally becoming the wording standard.
+
+## Questions To Resolve In The Room
+
+1. Should any diagnostic class require notes by default in v1?
+2. Is there any value in standardizing wording templates now?
+3. Should the spec reserve words like `error`, `note`, and `help` as output categories?
+4. Does conformance need to inspect wording classes at all?
+5. How much editorial freedom is acceptable before diagnostics stop feeling stable?
+
+## Expected Outputs
+
+This workshop should produce:
+
+1. a decision record for wording stability,
+2. a decision record for notes/help obligations,
+3. editing guidance for future `11` examples,
+4. and carry-forward items for conformance discussion in `13`.
+
+## Explicit Deferrals For Workshop 3
+
+- mandatory warnings,
+- cost visibility taxonomy,
+- and backend-originated failure mapping.
+
+## Inputs
+
+- `docs/pbs/specs/11. Diagnostics Specification.md`
+- `docs/pbs/specs/13. Conformance Test Specification.md`
+- `docs/pbs/agendas/11. Diagnostics Agenda.md`
+- `docs/pbs/agendas/11.1. Diagnostics Workshop 1 - Diagnostic Identity and Attribution.md`
+

docs/pbs/agendas/11.3. Diagnostics Workshop 3 - Cost Diagnostics and Warning Policy.md

@@ -0,0 +1,127 @@
+# PBS Diagnostics Workshop 3
+
+Status: Active
+
+## Purpose
+
+Run the third focused discussion for `11. Diagnostics Specification.md` on warnings and cost-facing diagnostics:
+
+- whether warnings are part of the normative contract,
+- which qualitative cost facts deserve mandatory surfacing,
+- and where diagnostics stops and profiling begins.
+
+## Why This Slice Third
+
+This slice should come after identity and wording because warning policy is only meaningful once the baseline diagnostic surface is already stable.
+
+It should also stay qualitative and avoid turning performance metrics into language law.
+
+## Proposed Meeting Order
+
+1. Reconfirm the cost facts already fixed by memory and lifetime rules.
+2. Decide whether warnings are in or out of conformance.
+3. Decide whether any qualitative cost diagnostics are mandatory.
+4. Decide the boundary between diagnostics, linting, and profiling.
+5. Record backend-mapping implications for Workshop 4.
+
+## Already-Settled Inputs To Reconfirm
+
+The meeting should explicitly reaffirm:
+
+- retention-bearing `bind` is a normatively relevant cost fact,
+- host-boundary crossings are normatively relevant cost facts,
+- copy-versus-alias behavior is normatively relevant qualitatively,
+- and exact byte counts or performance rankings are not normative.
+
+## Decisions To Produce
+
+1. Whether warnings are part of v1 conformance.
+2. Whether any qualitative cost diagnostics are mandatory.
+3. The line between core diagnostics and optional tooling enrichment.
+4. Whether cost diagnostics belong in `11` alone or also in `13`.
+
+## Candidate Decisions
+
+### 1. Warnings Are Outside Minimum Conformance In v1
+
+Candidate direction:
+
+- conforming tools may emit warnings,
+- but v1 does not require them for conformance.
+
+Rationale:
+
+- This keeps the baseline small.
+- It avoids forcing one style of beginner guidance too early.
+
+Alternative to discuss:
+
+- require a very small mandatory warning set for high-value cost facts.
+
+### 2. Cost Notes Are Encouraged But Optional
+
+Candidate direction:
+
+- tools may surface notes or warnings for:
+  retention-bearing `bind`,
+  host-boundary crossings,
+  and observable alias-versus-copy behavior.
+- none of these are mandatory in v1 conformance.
+
+Rationale:
+
+- This respects the normative cost model without overcommitting on tooling policy.
+
+### 3. Quantitative Performance Reporting Is Not Diagnostics Contract
+
+Candidate direction:
+
+- exact allocation counts,
+- exact byte counts,
+- and performance ranking remain outside the diagnostics spec.
+
+Rationale:
+
+- Those belong to profiling, not to language acceptance/rejection diagnostics.
+
+### 4. Linting Remains Implementation-Defined
+
+Candidate direction:
+
+- style hints, performance nudges, and educational suggestions remain implementation-defined unless later promoted deliberately.
+
+Rationale:
+
+- This prevents `11` from becoming a general lint catalog.
+
+## Questions To Resolve In The Room
+
+1. Is there any warning that is valuable enough to make mandatory in v1?
+2. Should cost diagnostics be notes only, warnings only, or fully tool-defined?
+3. Do host-boundary warnings belong to diagnostics, SDK guidance, or both?
+4. How should `13` treat optional warnings in conformance fixtures?
+5. Does excluding warnings from conformance undermine the beginner-facing goals of PBS?
+
+## Expected Outputs
+
+This workshop should produce:
+
+1. a decision record for warnings and conformance,
+2. a decision record for cost diagnostics boundaries,
+3. and follow-up notes for `13`.
+
+## Explicit Deferrals For Workshop 4
+
+- backend-originated error mapping,
+- source maps,
+- verifier/load-facing attribution,
+- and artifact-tool diagnostics.
+
+## Inputs
+
+- `docs/pbs/specs/10. Memory and Lifetime Specification.md`
+- `docs/pbs/specs/11. Diagnostics Specification.md`
+- `docs/pbs/specs/13. Conformance Test Specification.md`
+- `docs/pbs/agendas/11. Diagnostics Agenda.md`
+- `docs/pbs/agendas/11.1. Diagnostics Workshop 1 - Diagnostic Identity and Attribution.md`
+

docs/pbs/agendas/11.4. Diagnostics Workshop 4 - Backend-Originated Diagnostic Mapping.md

@@ -0,0 +1,125 @@
+# PBS Diagnostics Workshop 4
+
+Status: Active
+
+## Purpose
+
+Run the fourth focused discussion for `11. Diagnostics Specification.md` on backend-originated failures:
+
+- lowering failures,
+- verifier failures,
+- load-facing failures,
+- and how or whether they map back into the PBS-facing diagnostics contract.
+
+## Why This Slice Last
+
+This slice should come last because it depends on:
+
+- the phase vocabulary,
+- the attribution baseline,
+- and the lowering boundary being clearer.
+
+It should be the point where `11` explicitly interfaces with `12`, `15`, and `19`.
+
+## Proposed Meeting Order
+
+1. Reconfirm the frontend diagnostics baseline already closed.
+2. Sort backend-originated failure classes.
+3. Decide which backend failures remain PBS-facing diagnostics.
+4. Decide which failures belong only to artifact-facing tooling.
+5. Decide the minimum source-mapping obligations, if any.
+
+## Failure Classes To Sort
+
+- lowering rejection due to unsupported semantic state,
+- host-binding emission mismatch,
+- verifier rejection of malformed artifact invariants,
+- loader rejection directly attributable to malformed or unauthorized PBS-facing artifact usage,
+- and artifact-only corruption not attributable to valid PBS source.
+
+## Decisions To Produce
+
+1. The boundary between PBS-facing and artifact-facing diagnostics.
+2. The minimum source-mapping obligation for backend failures.
+3. Whether verifier/load failures participate in `11` directly.
+4. The input contract `13` may assert for these classes.
+
+## Candidate Decisions
+
+### 1. Only Source-Attributable Backend Failures Enter The PBS Diagnostics Contract
+
+Candidate direction:
+
+- if a backend failure is directly attributable to validly analyzed PBS source plus normative lowering rules, it remains part of the PBS-facing diagnostics contract,
+- otherwise it is artifact-tool or implementation failure surface.
+
+Rationale:
+
+- This keeps PBS diagnostics user-facing rather than compiler-internal.
+
+### 2. Verifier And Loader Failures Enter `11` Only When Userland Actionability Exists
+
+Candidate direction:
+
+- malformed or unauthorized host-facing artifact usage attributable to source remains in scope,
+- purely artifact-internal corruption or implementation bugs remain out of scope.
+
+Rationale:
+
+- This matches the current draft's narrow load-facing baseline.
+
+### 3. Source Mapping Is Useful But Minimal In v1
+
+Candidate direction:
+
+- v1 requires a source-facing location when the failure is source-attributable,
+- but does not yet require one standardized artifact offset map or source-map format.
+
+Rationale:
+
+- This keeps the contract implementable while leaving room for richer tooling later.
+
+### 4. Conformance Should Assert Only The Stable External Surface
+
+Candidate direction:
+
+- `13` may assert rejection phase, source attribution, and rejection class for backend-originated PBS diagnostics,
+- but not one exact verifier or loader message format.
+
+Rationale:
+
+- This keeps conformance aligned with the rest of `11`.
+
+## Questions To Resolve In The Room
+
+1. Which lowering failures are legitimate user-facing diagnostics versus compiler bugs?
+2. Do verifier failures need their own normative phase label, or map into linking/load-facing rejection?
+3. Is one source location enough for backend-originated failures?
+4. How much of artifact-facing tooling belongs in the PBS language contract at all?
+5. What exactly must `13` be able to test once `12` and `15` are closed?
+
+## Expected Outputs
+
+This workshop should produce:
+
+1. a decision record for backend diagnostics boundaries,
+2. a source-mapping obligations note,
+3. and explicit integration tasks for `11`, `12`, `13`, and `15`.
+
+## Explicit Deferrals
+
+- exact source-map file formats,
+- artifact UI presentation,
+- implementation bug reporting policy,
+- and internal compiler exception handling.
+
+## Inputs
+
+- `docs/pbs/specs/11. Diagnostics Specification.md`
+- `docs/pbs/specs/12. IR and Lowering Specification.md`
+- `docs/pbs/specs/15. Bytecode and PBX Mapping Specification.md`
+- `docs/pbs/specs/19. Verification and Safety Checks Specification.md`
+- `docs/pbs/agendas/11. Diagnostics Agenda.md`
+- `docs/pbs/agendas/11.1. Diagnostics Workshop 1 - Diagnostic Identity and Attribution.md`
+- `docs/pbs/agendas/11.3. Diagnostics Workshop 3 - Cost Diagnostics and Warning Policy.md`
+

docs/pbs/agendas/12. IR and Lowering Agenda.md

@@ -36,6 +36,57 @@ This agenda should keep the focus on semantic preservation and artifact obligati
 4. What is the minimal lowering model for builtin projections, builtin constants, and intrinsic member calls beyond what is already fixed?
 5. Which host-binding failures are lowering failures versus later verifier or loader failures?
 
+## Proposed Workshop Sequence
+
+### Workshop 1: Lowering Contract and IR Status
+
+Purpose:
+
+- decide whether PBS standardizes one canonical IR or only preserved obligations,
+- and close lowering preconditions after parsing, resolution, and type checking.
+
+Expected decisions:
+
+- canonical IR versus obligations-only model,
+- required bound-program inputs,
+- and minimal preserved semantic facts.
+
+### Workshop 2: Control Flow, Evaluation Order, and Propagation
+
+Purpose:
+
+- close the lowering model for expressions, branching, abrupt completion, `optional`, and `result`.
+
+Expected decisions:
+
+- explicit evaluation-order preservation,
+- lowered forms for `else`, `!`, and `handle`,
+- and trap versus propagation boundaries.
+
+### Workshop 3: Callables, Services, Contracts, and Callbacks
+
+Purpose:
+
+- close the lowering story for callable categories beyond ordinary top-level functions.
+
+Expected decisions:
+
+- callback formation model,
+- service and contract dispatch shape,
+- and runtime-artifact obligations for callable categories.
+
+### Workshop 4: Builtins, Host Bindings, and Artifact Invariants
+
+Purpose:
+
+- close builtin lowering, host-binding emission, and the invariants required before verifier and loader stages.
+
+Expected decisions:
+
+- builtin projection and intrinsic lowering obligations,
+- host-binding emission boundary versus PBX mapping,
+- and artifact invariants consumed by `15` and `19`.
+
 ## Expected Spec Material
 
 The resulting spec work should be able to add or close sections for:
@@ -70,4 +121,3 @@ The resulting spec work should be able to add or close sections for:
 - `docs/pbs/specs/14. Name Resolution and Module Linking Specification.md`
 - `docs/pbs/specs/15. Bytecode and PBX Mapping Specification.md`
 - `docs/pbs/specs/16. Runtime Execution and Initialization Specification.md`
-

docs/pbs/agendas/12.1. IR and Lowering Workshop 1 - Lowering Contract and IR Status.md

@@ -0,0 +1,118 @@
+# PBS IR and Lowering Workshop 1
+
+Status: Active
+
+## Purpose
+
+Run the first focused discussion for `12. IR and Lowering Specification.md` on the front door of lowering:
+
+- what the lowering contract consumes,
+- whether IR itself is normative,
+- and which semantic obligations must be preserved independent of IR shape.
+
+## Why This Slice First
+
+This slice should come first because every later lowering discussion depends on knowing:
+
+- what counts as a well-formed input to lowering,
+- and whether the spec standardizes one IR shape or only semantic preservation duties.
+
+## Proposed Meeting Order
+
+1. Reconfirm already-settled lowering inputs.
+2. Close the preconditions for lowering.
+3. Close the normative status of IR.
+4. Close the minimum preserved semantic obligations.
+5. Record construct-specific issues for later workshops.
+
+## Decisions To Produce
+
+1. The normative status of IR in PBS v1.
+2. The minimum required input state before lowering begins.
+3. The semantic facts that lowering must preserve regardless of IR architecture.
+4. The boundary between `12` and `15`.
+
+## Candidate Decisions
+
+### 1. Standardize Preserved Obligations, Not One Canonical In-Memory IR
+
+Candidate direction:
+
+- PBS v1 does not require one canonical compiler IR data model,
+- but it does require one stable set of preserved semantic obligations.
+
+Rationale:
+
+- This keeps the spec implementation-neutral while still preventing semantic drift.
+
+Alternative to discuss:
+
+- define one normative abstract IR grammar in the spec.
+
+### 2. Lowering Preconditions Require A Fully Bound Program
+
+Candidate direction:
+
+- parsing, name resolution, visibility/linking, and type checking must already be complete,
+- reserved builtin and host metadata must already be validated,
+- callable sets and canonical identities must already be resolved.
+
+Rationale:
+
+- Lowering should not invent unresolved semantic answers.
+
+### 3. Minimum Preserved Obligations Include Evaluation Order, Identity, and Host Boundary Facts
+
+Candidate direction:
+
+- lowering must preserve:
+  source-observable evaluation order,
+  abrupt-completion behavior,
+  value-identity and aliasing facts,
+  host-boundary crossings,
+  and trap-versus-propagation distinctions.
+
+Rationale:
+
+- These are the semantic anchors later workshops will rely on.
+
+### 4. `15` Owns Final Artifact Layout, `12` Owns The Contract Before It
+
+Candidate direction:
+
+- `12` defines the semantic and artifact-facing invariants a lowered program must satisfy,
+- `15` defines the final PBX and bytecode mapping details.
+
+Rationale:
+
+- This keeps the lowering spec from collapsing into artifact byte layout.
+
+## Questions To Resolve In The Room
+
+1. Is obligations-only precise enough, or does PBS need a normative abstract IR?
+2. Should canonical identity resolution be fully complete before lowering?
+3. Which semantic facts are mandatory to preserve explicitly rather than infer later?
+4. Does `12` need one explicit “bound program” model?
+5. How much artifact vocabulary can `12` use before it starts stealing `15`'s job?
+
+## Expected Outputs
+
+1. a decision record on IR status,
+2. a decision record on lowering preconditions,
+3. and a checklist of preserved semantic obligations for `12`.
+
+## Explicit Deferrals For Workshop 2
+
+- control-flow shapes,
+- propagation operators,
+- and callable-category-specific lowering.
+
+## Inputs
+
+- `docs/pbs/specs/9. Dynamic Semantics Specification.md`
+- `docs/pbs/specs/10. Memory and Lifetime Specification.md`
+- `docs/pbs/specs/12. IR and Lowering Specification.md`
+- `docs/pbs/specs/15. Bytecode and PBX Mapping Specification.md`
+- `docs/pbs/agendas/12. IR and Lowering Agenda.md`
+- `docs/pbs/agendas/14.4. Name Resolution Workshop 4 - Linking Phase Boundary.md`
+

docs/pbs/agendas/12.2. IR and Lowering Workshop 2 - Control Flow, Evaluation Order, and Propagation.md

@@ -0,0 +1,117 @@
+# PBS IR and Lowering Workshop 2
+
+Status: Active
+
+## Purpose
+
+Run the second focused discussion for `12. IR and Lowering Specification.md` on control flow and propagation:
+
+- evaluation order,
+- branching,
+- abrupt completion,
+- `optional`,
+- `result`,
+- `!`,
+- and `handle`.
+
+## Why This Slice Second
+
+This slice follows naturally from Workshop 1 because it applies the preserved-obligations model to the core execution constructs.
+
+## Proposed Meeting Order
+
+1. Reconfirm the preserved semantic obligations from Workshop 1.
+2. Close evaluation-order preservation in lowered form.
+3. Close the lowered model for branching and abrupt completion.
+4. Close the lowered model for `optional` and `result` propagation.
+5. Record callable and runtime-artifact issues for Workshop 3.
+
+## Decisions To Produce
+
+1. How evaluation order is preserved explicitly.
+2. How abrupt completion is represented in lowered control flow.
+3. The lowered shape of `optional else`, `expr!`, and `handle`.
+4. The boundary between propagation and trap in lowering.
+
+## Candidate Decisions
+
+### 1. Lowering Must Make Single Evaluation Explicit
+
+Candidate direction:
+
+- call target formation,
+- argument evaluation,
+- `if` conditions,
+- `switch` selectors,
+- `some(expr)` payload formation,
+- and `bind(context, fn_name)` capture
+must each lower to explicit once-only evaluation points.
+
+Rationale:
+
+- These are already language-observable guarantees.
+
+### 2. Branching Lowers To Explicit Control Transfers
+
+Candidate direction:
+
+- `if` and `switch` lower to explicit branch structure,
+- non-selected arms do not evaluate,
+- and tail-result formation is explicit rather than implicit.
+
+Rationale:
+
+- This keeps the dynamic-semantics contract visible through lowering.
+
+### 3. Propagation Uses Dedicated Lowered Paths
+
+Candidate direction:
+
+- `optional else` lowers to a presence test plus fallback path,
+- `expr!` lowers to success-path unpack plus immediate error propagation path,
+- `handle` lowers to explicit arm dispatch over the error case space.
+
+Rationale:
+
+- These constructs are semantically distinct enough that ordinary expression lowering should not blur them.
+
+### 4. Trap Is Not Rewritten Into Result Flow
+
+Candidate direction:
+
+- lowered trap paths remain fatal abort paths outside ordinary `result` propagation,
+- and `handle` never intercepts trap.
+
+Rationale:
+
+- This preserves the existing semantics cleanly.
+
+## Questions To Resolve In The Room
+
+1. Does `12` need dedicated abstract operations for propagation, or only obligations on the emitted control flow?
+2. How explicit must once-only evaluation be in the spec text?
+3. Does `switch` lowering need one canonical decision-tree shape?
+4. Is `handle` best specified as arm dispatch plus remap semantics, or as a more abstract effect-preservation rule?
+5. Which of these details belong to `12` versus `15`?
+
+## Expected Outputs
+
+1. a decision record for evaluation-order preservation,
+2. a decision record for propagation lowering,
+3. and control-flow section targets for `12`.
+
+## Explicit Deferrals For Workshop 3
+
+- services,
+- contracts,
+- callbacks,
+- and runtime dispatch artifacts.
+
+## Inputs
+
+- `docs/pbs/specs/9. Dynamic Semantics Specification.md`
+- `docs/pbs/specs/10. Memory and Lifetime Specification.md`
+- `docs/pbs/specs/12. IR and Lowering Specification.md`
+- `docs/pbs/agendas/12. IR and Lowering Agenda.md`
+- `docs/pbs/agendas/12.1. IR and Lowering Workshop 1 - Lowering Contract and IR Status.md`
+

docs/pbs/agendas/12.3. IR and Lowering Workshop 3 - Callables, Services, Contracts, and Callbacks.md

@@ -0,0 +1,111 @@
+# PBS IR and Lowering Workshop 3
+
+Status: Active
+
+## Purpose
+
+Run the third focused discussion for `12. IR and Lowering Specification.md` on callable categories beyond ordinary top-level functions:
+
+- callbacks,
+- services,
+- contracts,
+- methods,
+- and dispatch obligations.
+
+## Why This Slice Third
+
+This slice should come after control-flow lowering because it builds on the general execution model while introducing runtime-dispatch and identity-sensitive concerns.
+
+## Proposed Meeting Order
+
+1. Reconfirm callable categories and identity facts already fixed.
+2. Close callback formation and invocation lowering.
+3. Close service and method lowering.
+4. Close contract-view and dispatch lowering.
+5. Record builtin and host-binding specifics for Workshop 4.
+
+## Decisions To Produce
+
+1. The lowering story for callback formation and invocation.
+2. The lowering story for service singleton methods.
+3. The lowering story for contracts and dispatch.
+4. Which runtime-artifact facts must be explicit versus implementation-defined.
+
+## Candidate Decisions
+
+### 1. Callback Lowering Must Preserve Captured Identity And Retention
+
+Candidate direction:
+
+- callback values created by `bind` lower to a representation that preserves:
+  target callable identity,
+  captured context identity,
+  and retention-bearing lifetime facts.
+
+Rationale:
+
+- These are already required by memory and semantics specs.
+
+### 2. Service Lowering Preserves Singleton Identity
+
+Candidate direction:
+
+- service method calls lower through the module-owned singleton identity,
+- and lowering must not accidentally materialize new service instances.
+
+Rationale:
+
+- This is a language-observable property.
+
+### 3. Contract Lowering Must Preserve Selected Implementation Identity
+
+Candidate direction:
+
+- contract values lower as runtime-dispatchable views over an underlying owner plus implementation selection,
+- but `12` does not freeze one concrete table or object layout yet.
+
+Rationale:
+
+- This keeps the semantic contract clear while deferring layout choices.
+
+### 4. Receiver-Bearing Method Calls Need Explicit Lowered Receiver Handling
+
+Candidate direction:
+
+- struct, service, and contract method calls lower through an explicit receiver-bearing callable shape,
+- even if the backend later optimizes the representation.
+
+Rationale:
+
+- This keeps receiver identity and call semantics visible in the spec.
+
+## Questions To Resolve In The Room
+
+1. Does contract dispatch need a dedicated runtime artifact category in the spec?
+2. Does callback lowering need one explicit abstract representation?
+3. How much of method dispatch belongs in `12` versus runtime execution specs?
+4. Are service methods lowered like receiver calls or like specialized global calls?
+5. Which of these constructs need explicit artifact invariants before `15`?
+
+## Expected Outputs
+
+1. a decision record for callback lowering,
+2. a decision record for service and contract lowering,
+3. and callable-category section targets for `12`.
+
+## Explicit Deferrals For Workshop 4
+
+- builtin projection lowering,
+- builtin constants,
+- host-binding emission,
+- and verifier-facing artifact invariants.
+
+## Inputs
+
+- `docs/pbs/specs/4. Static Semantics Specification.md`
+- `docs/pbs/specs/9. Dynamic Semantics Specification.md`
+- `docs/pbs/specs/10. Memory and Lifetime Specification.md`
+- `docs/pbs/specs/12. IR and Lowering Specification.md`
+- `docs/pbs/agendas/12. IR and Lowering Agenda.md`
+- `docs/pbs/agendas/12.2. IR and Lowering Workshop 2 - Control Flow, Evaluation Order, and Propagation.md`
+

docs/pbs/agendas/12.4. IR and Lowering Workshop 4 - Builtins, Host Bindings, and Artifact Invariants.md

@@ -0,0 +1,111 @@
+# PBS IR and Lowering Workshop 4
+
+Status: Active
+
+## Purpose
+
+Run the fourth focused discussion for `12. IR and Lowering Specification.md` on the backend-facing edges:
+
+- builtin projections,
+- builtin constants,
+- intrinsic member calls,
+- host-binding emission,
+- and artifact invariants required before verifier or loader stages.
+
+## Why This Slice Last
+
+This slice should come last because it depends on the general lowering contract plus the special ownership rules around VM-owned versus host-backed behavior.
+
+## Proposed Meeting Order
+
+1. Reconfirm already-settled builtin and host-binding facts.
+2. Close lowering obligations for builtin projections and constants.
+3. Close lowering obligations for intrinsic member calls.
+4. Close host-binding emission obligations.
+5. Close pre-verifier and pre-loader artifact invariants.
+
+## Decisions To Produce
+
+1. Builtin lowering obligations beyond already-settled metadata consumption.
+2. Host-binding emission obligations before loader resolution.
+3. The artifact invariants required before verifier/loader stages.
+4. The exact boundary between `12`, `15`, and `19`.
+
+## Candidate Decisions
+
+### 1. Builtin Projections Stay VM-Owned Through Lowering
+
+Candidate direction:
+
+- builtin projection access lowers through VM-owned operations only,
+- and never through host-binding tables or host syscall paths.
+
+Rationale:
+
+- This is already settled; `12` needs only to make the preserved obligation explicit.
+
+### 2. Builtin Constants Lower Through Materialization, Not Constant Folding Semantics
+
+Candidate direction:
+
+- builtin constants lower through their VM-owned materialization path,
+- not through ordinary user-authored compile-time constant evaluation.
+
+Rationale:
+
+- This keeps builtin shells distinct from ordinary `declare const`.
+
+### 3. Host-Binding Emission Must Be Explicit Before `15`
+
+Candidate direction:
+
+- lowering must produce canonical host-binding entries,
+- deduplicate them by canonical identity,
+- and emit host-backed callsites in the pre-load form already fixed elsewhere.
+
+Rationale:
+
+- This is the bridge between bound source and artifact mapping.
+
+### 4. `12` Defines Artifact Invariants, `15` Defines Encoding
+
+Candidate direction:
+
+- `12` states what must be true of the emitted artifact boundary,
+- `15` states exactly how those facts appear in PBX and bytecode form,
+- `19` states what must be verified.
+
+Rationale:
+
+- This keeps the three backend-facing specs from overlapping.
+
+## Questions To Resolve In The Room
+
+1. Does `12` need any abstract instruction vocabulary for builtins and host calls?
+2. Which invariants belong to lowering rather than to verification?
+3. How much ordering and dedup detail should `12` restate versus reference from other specs?
+4. Should intrinsic lowering be specified as abstract op families or only semantic obligations?
+5. What exact artifact guarantees must `13` eventually assert?
+
+## Expected Outputs
+
+1. a decision record for builtin lowering obligations,
+2. a decision record for host-binding emission obligations,
+3. and an artifact-invariants checklist spanning `12`, `15`, and `19`.
+
+## Explicit Deferrals
+
+- exact bytecode instruction encodings,
+- exact PBX section layout,
+- and verifier algorithm details.
+
+## Inputs
+
+- `docs/pbs/specs/6.1. Intrinsics and Builtin Types Specification.md`
+- `docs/pbs/specs/6.2. Host ABI Binding and Loader Resolution Specification.md`
+- `docs/pbs/specs/12. IR and Lowering Specification.md`
+- `docs/pbs/specs/15. Bytecode and PBX Mapping Specification.md`
+- `docs/pbs/specs/19. Verification and Safety Checks Specification.md`
+- `docs/pbs/agendas/12. IR and Lowering Agenda.md`
+- `docs/pbs/agendas/12.3. IR and Lowering Workshop 3 - Callables, Services, Contracts, and Callbacks.md`
+

docs/pbs/agendas/13. Conformance Test Agenda.md

@@ -35,6 +35,58 @@ This agenda should keep conformance practical and layered so the project can evo
 4. What is the smallest reusable fixture set that still exercises host-backed and stdlib-backed surfaces honestly?
 5. How should compatibility expectations across language, stdlib, and cartridge domains be tested over time?
 
+## Proposed Workshop Sequence
+
+### Workshop 1: Conformance Claim Levels
+
+Purpose:
+
+- decide whether PBS has one conformance level or staged claims.
+
+Expected decisions:
+
+- claim taxonomy,
+- minimum requirements for each claim,
+- and naming constraints for partial implementations.
+
+### Workshop 2: Source-Level Oracle and Diagnostic Oracle
+
+Purpose:
+
+- close what source-level behavior must be asserted,
+- and decide how diagnostics enter conformance.
+
+Expected decisions:
+
+- positive versus negative suite boundaries,
+- diagnostic oracle granularity,
+- and minimum deterministic assertions.
+
+### Workshop 3: Artifact-Level Conformance and Fixtures
+
+Purpose:
+
+- decide when artifact-level tests become mandatory,
+- and close the fixture model for stdlib, registry, capability, and runtime scenarios.
+
+Expected decisions:
+
+- artifact-golden boundary,
+- fixture strategy,
+- and environment assumptions for host-backed tests.
+
+### Workshop 4: Regression and Compatibility Matrices
+
+Purpose:
+
+- decide how already-published behavior claims are preserved and tested over time.
+
+Expected decisions:
+
+- regression corpus policy,
+- compatibility-matrix expectations,
+- and alignment with `17`.
+
 ## Expected Spec Material
 
 The resulting spec work should be able to add or close sections for:
@@ -62,4 +114,3 @@ The resulting spec work should be able to add or close sections for:
 - `docs/pbs/specs/15. Bytecode and PBX Mapping Specification.md`
 - `docs/pbs/specs/17. Compatibility and Evolution Policy.md`
 - `docs/pbs/specs/19. Verification and Safety Checks Specification.md`
-

docs/pbs/agendas/13.1. Conformance Workshop 1 - Conformance Claim Levels.md

@@ -0,0 +1,98 @@
+# PBS Conformance Workshop 1
+
+Status: Active
+
+## Purpose
+
+Run the first focused discussion for `13. Conformance Test Specification.md` on conformance claims:
+
+- whether PBS has one conformance level or multiple claim tiers,
+- what each claim means,
+- and how partial implementations must describe themselves.
+
+## Why This Slice First
+
+This slice should come first because every later conformance workshop depends on knowing what kind of claim the tests are intended to validate.
+
+## Proposed Meeting Order
+
+1. Reconfirm the current source-level conformance baseline.
+2. Decide whether claim levels exist.
+3. Decide minimum requirements for each allowed claim.
+4. Decide naming restrictions for partial implementations.
+5. Record oracle and fixture consequences for later workshops.
+
+## Decisions To Produce
+
+1. One-level versus staged conformance model.
+2. Minimum obligations per conformance claim.
+3. Naming policy for partial implementations.
+4. The dependency from conformance claims into compatibility policy.
+
+## Candidate Decisions
+
+### 1. Allow Staged Claims
+
+Candidate direction:
+
+- permit staged claims such as:
+  frontend conformance,
+  source-runtime conformance,
+  and full toolchain conformance.
+
+Rationale:
+
+- This lets the project evolve honestly without pretending an unfinished backend is complete.
+
+Alternative to discuss:
+
+- keep only one conformance level to avoid user confusion.
+
+### 2. Each Claim Must Name What It Does Not Cover
+
+Candidate direction:
+
+- every partial claim must explicitly state excluded domains such as artifact emission, loader interaction, or verifier behavior.
+
+Rationale:
+
+- This prevents marketing-language ambiguity.
+
+### 3. Full PBS v1 Claim Requires The Whole Active Spec Set
+
+Candidate direction:
+
+- only the full claim may say “PBS v1 conforming” without qualifier,
+- staged claims must remain explicitly qualified.
+
+Rationale:
+
+- This protects the meaning of the top-level claim.
+
+## Questions To Resolve In The Room
+
+1. Are multiple conformance levels helpful or too confusing?
+2. What exact names should staged claims use?
+3. Can a parser-plus-binder implementation claim anything beyond “frontend”?
+4. Must runtime execution without artifact emission count as a distinct level?
+5. How does this interact with `17` compatibility labels?
+
+## Expected Outputs
+
+1. a decision record for claim levels,
+2. a claim taxonomy draft for `13`,
+3. and follow-up requirements for `17`.
+
+## Explicit Deferrals For Workshop 2
+
+- diagnostic oracle granularity,
+- source-level suite structure,
+- and artifact-level tests.
+
+## Inputs
+
+- `docs/pbs/specs/13. Conformance Test Specification.md`
+- `docs/pbs/specs/17. Compatibility and Evolution Policy.md`
+- `docs/pbs/agendas/13. Conformance Test Agenda.md`
+- `docs/pbs/agendas/17. Compatibility and Evolution Policy Agenda.md`
+

docs/pbs/agendas/13.2. Conformance Workshop 2 - Source-Level Oracle and Diagnostic Oracle.md

@@ -0,0 +1,96 @@
+# PBS Conformance Workshop 2
+
+Status: Active
+
+## Purpose
+
+Run the second focused discussion for `13. Conformance Test Specification.md` on the source-level oracle:
+
+- positive and negative suites,
+- runtime-oracle scope,
+- and how diagnostics participate in conformance.
+
+## Why This Slice Second
+
+This slice follows claim levels because it defines the actual assertions needed for the frontend and source-runtime portions of conformance.
+
+## Proposed Meeting Order
+
+1. Reconfirm the claim taxonomy from Workshop 1.
+2. Close the positive and negative source-level suite boundaries.
+3. Close the source-level runtime oracle.
+4. Close the diagnostic oracle granularity.
+5. Record artifact and fixture dependencies for Workshop 3.
+
+## Decisions To Produce
+
+1. The exact source-level oracle categories.
+2. The minimum diagnostic assertions conformance may check.
+3. The distinction between acceptance/rejection tests and runtime-oracle tests.
+4. The boundary between source-level conformance and artifact-level conformance.
+
+## Candidate Decisions
+
+### 1. Keep Source-Level Oracle As The Core Baseline
+
+Candidate direction:
+
+- conformance must at minimum assert parsing, rejection, binding, typing, dynamic semantics, and memory/identity behavior at source level.
+
+Rationale:
+
+- This matches the current maturity of the corpus.
+
+### 2. Diagnostic Oracle Checks Stable External Fields Only
+
+Candidate direction:
+
+- conformance may assert:
+  acceptance or rejection,
+  diagnostic phase,
+  source attribution,
+  and stable rejection class if adopted,
+- but not exact message wording.
+
+Rationale:
+
+- This aligns `13` to the likely direction of `11`.
+
+### 3. Runtime Oracle Remains Language-Observable
+
+Candidate direction:
+
+- conformance asserts only language-observable outcomes at this stage,
+- not implementation timing or internal GC behavior.
+
+Rationale:
+
+- This preserves portability across implementations.
+
+## Questions To Resolve In The Room
+
+1. Should diagnostic codes become part of the conformance oracle if `11` later adopts them?
+2. Must source-level runtime tests be required for every claim level or only some?
+3. How should trap behavior be asserted without over-specifying runtime internals?
+4. Which negative tests belong to parsing versus static semantics versus linking?
+5. How much source attribution detail is enough for conformance?
+
+## Expected Outputs
+
+1. a decision record for source-level oracle scope,
+2. a decision record for diagnostics in conformance,
+3. and suite-structure targets for `13`.
+
+## Explicit Deferrals For Workshop 3
+
+- artifact goldens,
+- stdlib and host fixtures,
+- and runtime-line environment modeling.
+
+## Inputs
+
+- `docs/pbs/specs/11. Diagnostics Specification.md`
+- `docs/pbs/specs/13. Conformance Test Specification.md`
+- `docs/pbs/agendas/11.1. Diagnostics Workshop 1 - Diagnostic Identity and Attribution.md`
+- `docs/pbs/agendas/13.1. Conformance Workshop 1 - Conformance Claim Levels.md`
+

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

@@ -0,0 +1,98 @@
+# 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`
+

docs/pbs/agendas/13.4. Conformance Workshop 4 - Regression and Compatibility Matrices.md

@@ -0,0 +1,100 @@
+# PBS Conformance Workshop 4
+
+Status: Active
+
+## Purpose
+
+Run the fourth focused discussion for `13. Conformance Test Specification.md` on long-lived behavior preservation:
+
+- regression corpus policy,
+- compatibility matrices,
+- and how published claims are tested over time.
+
+## Why This Slice Last
+
+This slice should come last because it depends on:
+
+- claim taxonomy,
+- source-level oracle,
+- artifact-level scope,
+- and compatibility policy direction.
+
+## Proposed Meeting Order
+
+1. Reconfirm the settled claim levels and oracle shapes.
+2. Decide what becomes part of the regression corpus.
+3. Decide how compatibility matrices are represented in tests.
+4. Decide how already-published behavior claims are preserved.
+5. Record final spec-integration tasks for `13` and `17`.
+
+## Decisions To Produce
+
+1. Regression corpus policy.
+2. Compatibility-matrix testing policy.
+3. The relationship between published claims and test obligations.
+4. How partial claims and full claims age over time.
+
+## Candidate Decisions
+
+### 1. Published Behavior Claims Must Enter A Regression Corpus
+
+Candidate direction:
+
+- once behavior is claimed as conforming or supported, it should become regression-protected in the corpus appropriate to that claim level.
+
+Rationale:
+
+- This turns compatibility promises into executable checks.
+
+### 2. Compatibility Matrices Should Be Testable, Not Only Documented
+
+Candidate direction:
+
+- the matrix across language line,
+  stdlib line,
+  runtime line,
+  and conformance claim
+must have test-backed meaning where support is promised.
+
+Rationale:
+
+- This prevents compatibility tables from becoming marketing-only artifacts.
+
+### 3. Retired Claims Must Be Explicitly Removed, Not Silently Forgotten
+
+Candidate direction:
+
+- when support is dropped, the corresponding claim and tests must be retired deliberately with migration or policy notes.
+
+Rationale:
+
+- This aligns conformance with compatibility governance.
+
+## Questions To Resolve In The Room
+
+1. What exactly enters the regression corpus: only bugs, or every published example and decision?
+2. How granular should compatibility matrices be?
+3. Can staged claims have separate regression corpora?
+4. How are unsupported combinations represented in tests?
+5. Which parts of this belong in `13` versus `17`?
+
+## Expected Outputs
+
+1. a decision record for regression policy,
+2. a decision record for compatibility-matrix testing,
+3. and a final alignment checklist between `13` and `17`.
+
+## Explicit Deferrals
+
+- release tooling implementation,
+- repository layout for the test corpus,
+- and changelog formatting.
+
+## Inputs
+
+- `docs/pbs/specs/13. Conformance Test Specification.md`
+- `docs/pbs/specs/17. Compatibility and Evolution Policy.md`
+- `docs/pbs/agendas/13.1. Conformance Workshop 1 - Conformance Claim Levels.md`
+- `docs/pbs/agendas/13.3. Conformance Workshop 3 - Artifact-Level Conformance and Fixtures.md`
+- `docs/pbs/agendas/17.3. Compatibility Workshop 3 - Compatibility Matrices and Published Claims.md`
+

docs/pbs/agendas/14. Name Resolution and Module Linking Agenda.md

@@ -34,6 +34,58 @@ Without this closure, parser and AST work can proceed only as exploratory implem
 4. When two imported modules make the same name visible, what is the exact ambiguity and rejection rule?
 5. Are reserved stdlib shells resolved as ordinary visible declarations with metadata, or do they have any special priority?
 
+## Proposed Workshop Sequence
+
+### Workshop 1: Scope, Lookup, and Imports
+
+Purpose:
+
+- close module scope construction,
+- close lookup order by namespace,
+- and close import alias and ambiguity rules.
+
+Reference:
+
+- `docs/pbs/agendas/14.1. Name Resolution Workshop 1 - Scope, Lookup, and Imports.md`
+
+### Workshop 2: Builtin Shells and Host Owners
+
+Purpose:
+
+- close how reserved stdlib shells enter resolution,
+- and close lookup and collision policy for builtin types, builtin constants, intrinsic members, and host owners.
+
+Expected decisions:
+
+- reserved-shell visibility model,
+- builtin and host-owner lookup interaction,
+- and canonical identity versus local aliasing boundaries.
+
+### Workshop 3: Callable Sets and Cross-Module Linking
+
+Purpose:
+
+- close overload-set formation across module boundaries,
+- and decide ambiguity and rejection rules for imported callable sets.
+
+Expected decisions:
+
+- callable-set merge rules,
+- barrel-matching consequences for imported overloads,
+- and cross-module ambiguity failures.
+
+### Workshop 4: Linking Phase Boundary
+
+Purpose:
+
+- decide which rules belong to static semantics versus a distinct linking phase.
+
+Expected decisions:
+
+- phase split or collapse,
+- rejection ownership by phase,
+- and inputs needed by `11`, `12`, and frontend conformance.
+
 ## Expected Spec Material
 
 The resulting spec work should be able to add or close sections for:
@@ -63,4 +115,3 @@ The resulting spec work should be able to add or close sections for:
 - `docs/pbs/specs/8. Stdlib Environment Packaging and Loading Specification.md`
 - `docs/pbs/specs/14. Name Resolution and Module Linking Specification.md`
 - `docs/pbs/specs/18. Standard Library Surface Specification.md`
-

docs/pbs/agendas/14.1. Name Resolution Workshop 1 - Scope, Lookup, and Imports.md

@@ -0,0 +1,184 @@
+# PBS Name Resolution Workshop 1
+
+Status: Active
+
+## Purpose
+
+Run the first focused discussion for `14. Name Resolution and Module Linking Specification.md` on the smallest set of decisions that unlocks normative frontend work:
+
+- scope construction,
+- namespace-specific lookup order,
+- import visibility,
+- and ambiguity rejection.
+
+## Why This Slice First
+
+This slice is the best first cut because it does not require full lowering closure, but it does unblock:
+
+- parser and binder architecture,
+- symbol-table modeling,
+- deterministic frontend diagnostics,
+- and the later discussion of overload visibility and reserved stdlib shells.
+
+It should intentionally avoid trying to close every linking edge case in one meeting.
+
+## Proposed Meeting Order
+
+1. Confirm already-settled inputs that are not up for debate.
+2. Close scope-construction rules inside one module.
+3. Close lookup order by namespace.
+4. Close import visibility and alias rules.
+5. Close ambiguity and duplicate rejection rules.
+6. Record deferred items for a second workshop.
+
+## Already-Settled Inputs To Reconfirm
+
+The meeting should start by explicitly reaffirming:
+
+- `mod.barrel` is the single source of module visibility.
+- Imports target modules, not files.
+- Only `pub` names are importable from another module.
+- PBS has distinct type, value, callable, and host-owner namespaces.
+- Builtin simple types `int`, `float`, `bool`, and `str` are always present in type position.
+- Reserved stdlib spaces resolve from the selected stdlib environment, not from ordinary dependencies.
+
+These points already come from existing specs and should not be reopened in this workshop.
+
+## Decisions To Produce
+
+1. Scope construction inside a module.
+2. Lookup order in value, type, callable, and host-owner position.
+3. Import alias behavior and collisions.
+4. Ambiguity rules when multiple imports expose the same visible name.
+5. The phase boundary between syntax, static semantics, and linking for these failures.
+
+## Candidate Decisions
+
+### 1. Scope Construction Inside One Module
+
+Candidate direction:
+
+- File-local top-level declarations are collected first from all `.pbs` files in the module.
+- `mod.barrel` is then applied as a visibility filter over the already-collected top-level declarations.
+- Top-level declaration availability inside the same module does not depend on source-file order.
+- Local block scopes nest normally over module scope.
+
+Rationale:
+
+- This matches the existing module model.
+- It prevents file-order-dependent lookup.
+- It keeps barrel as a visibility mechanism, not as the source of declaration existence.
+
+### 2. Lookup Order By Namespace
+
+Candidate direction:
+
+Value position:
+
+- nearest local bindings,
+- parameters,
+- visible `declare const`,
+- visible imported values,
+- service singleton values introduced by visible service declarations.
+
+Type position:
+
+- nearest type declarations visible in module scope,
+- visible imported type declarations,
+- builtin simple types.
+
+Callable position:
+
+- nearest callable declarations visible in module scope,
+- then visible imported callable declarations,
+- with overload sets formed after visibility filtering.
+
+Host-owner position:
+
+- visible host owners in module scope,
+- then visible imported host owners.
+
+Open point for discussion:
+
+- whether builtin simple types should be treated as implicit outermost scope or as a final fallback outside ordinary visible declarations.
+
+### 3. Import Alias Rules
+
+Candidate direction:
+
+- `import @project:mod;` imports the module itself as a module-qualified reference surface only if another spec later defines such a surface.
+- For current v1 name resolution, named imports are the only source of imported visible names.
+- `import { X } from ...;` introduces `X` in the matching namespace of the exported declaration.
+- `import { X as Y } from ...;` introduces only `Y` locally.
+- Alias spelling affects only the local visible name, never canonical builtin or host identity.
+
+Rationale:
+
+- Keeps current source behavior conservative.
+- Avoids inventing module-as-value semantics accidentally.
+- Matches the existing distinction between source-visible spelling and canonical metadata identity.
+
+### 4. Collision And Ambiguity Rules
+
+Candidate direction:
+
+- Two local declarations in the same namespace that produce the same non-overload identity are duplicates.
+- A local declaration and an imported declaration with the same visible name in the same namespace are a deterministic conflict unless one rule explicitly allows shadowing.
+- Two imported declarations with the same visible name in the same namespace are a deterministic ambiguity unless they are the same declaration reached through the same canonical module resolution.
+- Callable overload sets may merge only when their callable identities remain distinct after tuple-shape identity rules are applied.
+- Non-callable namespaces do not merge by name.
+
+Open point for discussion:
+
+- whether local declarations should fully shadow imports in value, type, callable, and host-owner namespaces, or whether PBS should reject such shadowing to keep lookup simpler for beginners.
+
+### 5. Diagnostic Phase Boundary
+
+Candidate direction:
+
+- malformed import syntax remains syntax-phase.
+- unresolved module path remains manifest/import-resolution phase.
+- import of non-exported symbol remains linking-phase or manifest/import-resolution-adjacent phase, but not syntax-phase.
+- duplicate local declarations remain static-semantics phase.
+- ambiguous visible names after import resolution remain linking-phase unless the project later collapses linking into static semantics explicitly.
+
+Rationale:
+
+- This preserves a clean split between parsing, declaration validity, and cross-module resolution.
+- It gives `11. Diagnostics Specification.md` a concrete input rather than forcing that spec to invent phases in isolation.
+
+## Questions To Resolve In The Room
+
+1. Do local top-level declarations shadow imported names, or is any such collision rejected?
+2. Are parameters and local `let` bindings one combined nearest-scope value layer, or should parameters be modeled separately for diagnostics only?
+3. Can imported overloads and local overloads merge into one callable set, or must that be rejected?
+4. Is `import @project:module;` currently just side-effect-free validation, or should it create any usable source-visible surface in v1?
+5. Do builtin simple types behave like reserved final fallback names or like ordinary always-visible type declarations?
+
+## Expected Outputs
+
+This workshop should produce:
+
+1. a decision record for scope and lookup order,
+2. a decision record for import alias and ambiguity policy,
+3. a concrete update plan for `14. Name Resolution and Module Linking Specification.md`,
+4. and a list of deferred issues for Workshop 2.
+
+## Explicit Deferrals For Workshop 2
+
+The following topics should be deferred unless they become unavoidable:
+
+- reserved stdlib shell priority versus ordinary imports,
+- member lookup on builtin receivers,
+- contract and method dispatch lookup details,
+- barrel matching of callable overload sets across module boundaries,
+- and whether linking is its own normative phase or is folded fully into static semantics.
+
+## Inputs
+
+- `docs/pbs/specs/3. Core Syntax Specification.md`
+- `docs/pbs/specs/4. Static Semantics Specification.md`
+- `docs/pbs/specs/5. Manifest, Stdlib, and SDK Resolution Specification.md`
+- `docs/pbs/specs/14. Name Resolution and Module Linking Specification.md`
+- `docs/pbs/specs/18. Standard Library Surface Specification.md`
+- `docs/pbs/agendas/14. Name Resolution and Module Linking Agenda.md`

docs/pbs/agendas/14.2. Name Resolution Workshop 2 - Builtin Shells and Host Owners.md

@@ -0,0 +1,159 @@
+# PBS Name Resolution Workshop 2
+
+Status: Active
+
+## Purpose
+
+Run the second focused discussion for `14. Name Resolution and Module Linking Specification.md` on reserved stdlib shells and host-owner resolution:
+
+- builtin type shells,
+- builtin constants,
+- intrinsic member surfaces,
+- and `declare host` owners imported from reserved stdlib modules.
+
+## Why This Slice Second
+
+This slice should come after Workshop 1 because it builds on already-closed rules for:
+
+- module scope construction,
+- ordinary import visibility,
+- aliasing,
+- and namespace-specific lookup order.
+
+It also prepares the ground for later lowering by making the resolution contract explicit without prematurely defining artifact shape.
+
+## Proposed Meeting Order
+
+1. Reconfirm already-settled ownership and stdlib-loading rules.
+2. Close the visibility model for builtin and host shells.
+3. Close lookup behavior for builtin types, builtin constants, and host owners.
+4. Close member resolution on builtin receivers.
+5. Close collision and ambiguity rules involving reserved shells.
+6. Record deferred callable-linking issues for Workshop 3.
+
+## Already-Settled Inputs To Reconfirm
+
+The meeting should explicitly reaffirm:
+
+- reserved stdlib project spaces include `@core:*` and `@sdk:*`,
+- reserved stdlib spaces resolve only from the selected stdlib environment,
+- source-visible builtin names resolve through imported builtin shell declarations,
+- builtin intrinsic members are not imported as free functions,
+- canonical builtin and host identities come from metadata rather than local alias spelling,
+- and host-owner namespace remains distinct from type, value, and callable namespaces.
+
+These are already fixed elsewhere and should not be reopened here.
+
+## Decisions To Produce
+
+1. Visibility rules for builtin shells and host owners imported from reserved stdlib modules.
+2. Lookup rules for builtin types, builtin constants, intrinsic members, and host owners.
+3. Collision and ambiguity rules when reserved shells overlap with ordinary user-visible declarations.
+4. Diagnostic ownership for reserved-shell resolution failures.
+5. Deferred boundary between source resolution and later lowering.
+
+## Candidate Decisions
+
+### 1. Reserved Shells Enter Resolution As Ordinary Visible Declarations
+
+Candidate direction:
+
+- Imported builtin type shells become visible in the type namespace like other imported type declarations.
+- Imported builtin constants become visible in the value namespace like other imported constants.
+- Imported host owners become visible in the host-owner namespace like other imported host declarations.
+- Reserved metadata changes canonical lowering identity, not the ordinary namespace they enter.
+
+Rationale:
+
+- This keeps the source model uniform.
+- It avoids a hidden parallel lookup system just for reserved stdlib surfaces.
+- It matches the current specs that describe shells as imported declarations with metadata.
+
+### 2. Builtin Simple Types Remain Separate From Imported Builtin Shells
+
+Candidate direction:
+
+- `int`, `float`, `bool`, and `str` remain always-available builtin simple types.
+- Imported builtin shells such as `Vec2` or `Color` are ordinary visible type declarations and do not share special priority with builtin simple types.
+- User-authored declarations still cannot reuse builtin simple type names.
+
+Rationale:
+
+- Separates the small predeclared core from stdlib-delivered builtin shells.
+- Prevents `@core:*` imports from acting like implicit language keywords.
+
+### 3. Intrinsic Members Resolve Through Receiver Type, Never Through Free Lookup
+
+Candidate direction:
+
+- Builtin intrinsic methods are resolved only during member lookup on a builtin-typed receiver.
+- They do not appear in top-level callable lookup.
+- They do not become visible through named import by method name.
+- Alias changes to the builtin type affect only source spelling of the owner type, not intrinsic canonical identity.
+
+Rationale:
+
+- This matches the existing builtin and intrinsics spec.
+- It prevents accidental confusion between member semantics and free functions.
+
+### 4. Collision Policy For Reserved Shells
+
+Candidate direction:
+
+- Namespace collisions are handled by the same visibility rules used for ordinary declarations.
+- A user-visible imported builtin type colliding with another visible type name is a deterministic conflict unless an already-closed shadowing rule says otherwise.
+- A host owner colliding with a type or value name is not a conflict by itself because host-owner namespace is distinct.
+- Duplicate canonical builtin identities in one resolved environment remain rejection cases even if local aliases differ.
+
+Open point for discussion:
+
+- whether conflicts involving reserved shells should be rejected more aggressively than ordinary import conflicts to preserve beginner clarity.
+
+### 5. Diagnostic Ownership
+
+Candidate direction:
+
+- failure to resolve the reserved module remains manifest/import-resolution phase,
+- import of a non-exported builtin or host shell remains linking or resolution-phase rejection,
+- member lookup failure on a builtin receiver remains static-semantics or linking-phase depending on the final phase model,
+- duplicate canonical builtin or host identities in one resolved environment remain deterministic compile-time rejection.
+
+Rationale:
+
+- This keeps module loading, visibility, and member resolution separate.
+- It gives `11` a concrete discussion input later.
+
+## Questions To Resolve In The Room
+
+1. Should reserved shells be completely ordinary imported declarations at source level, or do any of them need special lookup priority?
+2. Can an ordinary user declaration shadow an imported builtin shell, or should that always be rejected?
+3. Is member lookup on builtin receivers purely a type-driven operation after receiver typing, or does name resolution need a separate reserved-shell step?
+4. Should `@sdk:*` be allowed to expose builtin shells, or should builtin shells remain policy-preferred under `@core:*` only?
+5. Which failures around canonical builtin identity belong to resolution, static semantics, or environment validation?
+
+## Expected Outputs
+
+This workshop should produce:
+
+1. a decision record for reserved-shell visibility and lookup,
+2. a decision record for collision policy involving builtin and host shells,
+3. a concrete update plan for the reserved-shell sections of `14`,
+4. and a deferred list for cross-module callable-set discussion in Workshop 3.
+
+## Explicit Deferrals For Workshop 3
+
+The following topics should be deferred unless unavoidable:
+
+- imported callable-set merging across modules,
+- overload resolution across ordinary and reserved callable surfaces,
+- contract dispatch lookup,
+- and whether linking is fully distinct from static semantics.
+
+## Inputs
+
+- `docs/pbs/specs/5. Manifest, Stdlib, and SDK Resolution Specification.md`
+- `docs/pbs/specs/6.1. Intrinsics and Builtin Types Specification.md`
+- `docs/pbs/specs/14. Name Resolution and Module Linking Specification.md`
+- `docs/pbs/specs/18. Standard Library Surface Specification.md`
+- `docs/pbs/agendas/14. Name Resolution and Module Linking Agenda.md`
+- `docs/pbs/agendas/14.1. Name Resolution Workshop 1 - Scope, Lookup, and Imports.md`

docs/pbs/agendas/14.3. Name Resolution Workshop 3 - Callable Sets and Cross-Module Linking.md

@@ -0,0 +1,160 @@
+# PBS Name Resolution Workshop 3
+
+Status: Active
+
+## Purpose
+
+Run the third focused discussion for `14. Name Resolution and Module Linking Specification.md` on callable visibility and cross-module linking:
+
+- imported callable sets,
+- overload-set formation across module boundaries,
+- barrel matching consequences for imported overloads,
+- and deterministic ambiguity rejection.
+
+## Why This Slice Third
+
+This slice should come after Workshops 1 and 2 because it depends on already-closed rules for:
+
+- scope construction,
+- namespace-specific lookup order,
+- import aliasing,
+- reserved-shell visibility,
+- and ordinary collision handling.
+
+It is also the last major source-facing step before deciding whether linking is a separate normative phase.
+
+## Proposed Meeting Order
+
+1. Reconfirm callable identity and barrel visibility rules that are already fixed.
+2. Close how imported callable declarations become visible.
+3. Close overload-set formation across local and imported declarations.
+4. Close ambiguity and conflict rules for cross-module callable sets.
+5. Close barrel-matching consequences for imported overload visibility.
+6. Record phase-boundary questions for Workshop 4.
+
+## Already-Settled Inputs To Reconfirm
+
+The meeting should explicitly reaffirm:
+
+- callable identity ignores parameter labels and output labels,
+- overloaded functions differ by input/output tuple shape rather than parameter spelling,
+- only `pub` callable entries are importable from another module,
+- each exported overload must appear explicitly in `mod.barrel`,
+- and `mod.barrel` matches callables by callable identity rather than by label spelling alone.
+
+These points are already fixed and should not be reopened here.
+
+## Decisions To Produce
+
+1. Visibility rules for imported callable declarations and callable sets.
+2. Merge or no-merge policy between local and imported overloads.
+3. Ambiguity and rejection rules for callable sets visible from multiple modules.
+4. Barrel consequences for callable visibility across modules.
+5. Diagnostic ownership for callable-linking failures.
+
+## Candidate Decisions
+
+### 1. Imported Callables Enter Ordinary Callable Lookup
+
+Candidate direction:
+
+- `import { f } from @project:mod;` introduces the exported callable set named `f` into local callable lookup.
+- If the source module exports multiple overloads of `f`, the imported surface initially brings in that visible overload set, not only one declaration.
+- Alias spelling changes only the local visible callable name, not callable identity.
+
+Rationale:
+
+- This keeps imported callables aligned with existing callable namespace rules.
+- It avoids inventing per-overload import syntax before it is needed.
+
+### 2. Local And Imported Overloads Do Not Merge Implicitly
+
+Candidate direction:
+
+- A local callable set and an imported callable set with the same visible name do not silently merge.
+- Such a collision is a deterministic ambiguity unless both sets resolve to the same canonical underlying declarations.
+- Overload merging is allowed only within one declaration origin set already sanctioned by module visibility and barrel rules.
+
+Rationale:
+
+- Silent merging across modules makes beginner reasoning harder.
+- It also makes diagnostics and compatibility more fragile.
+- Rejecting cross-origin merges keeps overload sets traceable.
+
+Open point for discussion:
+
+- whether there is any narrow exception for identical re-exported declarations reached through more than one import path.
+
+### 3. Cross-Module Callable Ambiguity Is Rejected Before Overload Resolution
+
+Candidate direction:
+
+- If two different imported modules make the same callable name visible locally, and they do not denote the same canonical declarations, the program is rejected before ordinary overload resolution.
+- Overload resolution should not be used as a tie-breaker between different imported origin sets.
+- Callable ambiguity is resolved structurally by import visibility, not opportunistically by the later callsite.
+
+Rationale:
+
+- This keeps lookup deterministic and simple.
+- It avoids context-sensitive import ambiguity that changes across callsites.
+
+### 4. Barrel Visibility Defines The Imported Callable Set Boundary
+
+Candidate direction:
+
+- Only overloads exported through the source module's `mod.barrel` are part of the importable callable set.
+- Non-exported local overloads in the source module do not participate in imported callable visibility.
+- A named import of `f` from another module is therefore a request for that module's exported `f` set, filtered by barrel visibility.
+
+Rationale:
+
+- This makes cross-module callable linking a direct consequence of barrel policy rather than an extra ad hoc rule.
+
+### 5. Diagnostic Ownership
+
+Candidate direction:
+
+- duplicate callable declarations inside one module remain static-semantics rejection,
+- failure of a barrel callable entry to resolve inside its own module remains a module-linking or static-semantics-adjacent rejection depending on the final phase split,
+- cross-module callable-name ambiguity remains linking-phase rejection,
+- and overload-resolution failure at a callsite remains static semantics rather than module linking.
+
+Rationale:
+
+- This preserves a useful distinction between visible-set formation and callsite selection.
+
+## Questions To Resolve In The Room
+
+1. Should local and imported callable sets ever merge automatically under the same name?
+2. Should two imported callable sets with the same name be rejected immediately, or only when actually referenced?
+3. If the same declaration becomes reachable through two import paths, should that still be rejected or canonicalized as one visible origin?
+4. Is there any need for per-overload import control in v1, or is barrel-level export enough?
+5. Where exactly is the line between callable-set formation and ordinary overload resolution?
+
+## Expected Outputs
+
+This workshop should produce:
+
+1. a decision record for imported callable-set visibility,
+2. a decision record for callable ambiguity and merge policy,
+3. a concrete update plan for the callable-linking sections of `14`,
+4. and a narrow carry-forward list for phase-boundary cleanup in Workshop 4.
+
+## Explicit Deferrals For Workshop 4
+
+The following topics should be deferred unless unavoidable:
+
+- whether linking is a formally distinct phase or folded into static semantics,
+- diagnostic naming and code stability,
+- source-to-artifact mapping concerns,
+- and backend consequences of callable linking.
+
+## Inputs
+
+- `docs/pbs/specs/3. Core Syntax Specification.md`
+- `docs/pbs/specs/4. Static Semantics Specification.md`
+- `docs/pbs/specs/14. Name Resolution and Module Linking Specification.md`
+- `docs/pbs/agendas/14. Name Resolution and Module Linking Agenda.md`
+- `docs/pbs/agendas/14.1. Name Resolution Workshop 1 - Scope, Lookup, and Imports.md`
+- `docs/pbs/agendas/14.2. Name Resolution Workshop 2 - Builtin Shells and Host Owners.md`
+

docs/pbs/agendas/14.4. Name Resolution Workshop 4 - Linking Phase Boundary.md

@@ -0,0 +1,144 @@
+# PBS Name Resolution Workshop 4
+
+Status: Active
+
+## Purpose
+
+Run the fourth focused discussion for `14. Name Resolution and Module Linking Specification.md` on phase ownership:
+
+- what belongs to syntax,
+- what belongs to static semantics,
+- what belongs to module/linking,
+- and whether PBS keeps linking as a distinct normative phase at all.
+
+## Why This Slice Last
+
+This slice should come last because it is mostly a boundary-setting exercise over decisions already made in Workshops 1 through 3.
+
+Trying to close it earlier would force abstract phase arguments before the actual failure classes were concrete.
+
+## Proposed Meeting Order
+
+1. Reconfirm the concrete failure categories identified in earlier workshops.
+2. Group those failures by source-only, module-resolution, and cross-module visibility concerns.
+3. Decide whether PBS names linking as a distinct normative phase.
+4. Decide how this boundary feeds diagnostics, conformance, and frontend implementation claims.
+5. Record any residual editorial cleanup for the spec integration pass.
+
+## Failure Classes To Sort
+
+This workshop should explicitly sort at least the following classes:
+
+- malformed import syntax,
+- unresolved module path,
+- import of non-exported symbol,
+- duplicate local declarations,
+- ambiguous imported names,
+- callable-set ambiguity across modules,
+- builtin-receiver member lookup failure,
+- duplicate canonical builtin or host identities in one resolved environment,
+- and barrel entries that fail to resolve against module declarations.
+
+## Decisions To Produce
+
+1. Whether linking is a distinct normative phase in PBS v1.
+2. Ownership of the major failure classes already identified.
+3. The minimum phase vocabulary needed by diagnostics and conformance.
+4. The frontend implementation consequences of the chosen phase model.
+
+## Candidate Decisions
+
+### 1. Keep Linking As A Distinct Normative Phase
+
+Candidate direction:
+
+- syntax owns grammar and token-shape failures,
+- static semantics owns declaration validity, typing, and callsite selection,
+- linking owns cross-file and cross-module visible-set formation and barrel/import matching.
+
+Rationale:
+
+- This gives a clean home to failures that are neither purely syntactic nor ordinary local typing.
+- It matches the practical compiler architecture implied by module loading and barrel visibility.
+- It gives `11` and `13` a usable phase vocabulary.
+
+Alternative to discuss:
+
+- collapse linking into static semantics and treat "linking" only as an implementation detail.
+
+### 2. Module-Visibility And Import Failures Belong To Linking
+
+Candidate direction:
+
+- unresolved exported-name lookup after the target module is loaded belongs to linking,
+- ambiguous imported visible names belong to linking,
+- callable-set ambiguity across modules belongs to linking,
+- and unresolved barrel entries belong to linking or module-linking rather than to syntax.
+
+Rationale:
+
+- These failures arise from assembling visible declarations across files or modules, not from parsing isolated declarations.
+
+### 3. Callsite Selection Remains Static Semantics
+
+Candidate direction:
+
+- once visible callable sets are formed, overload resolution at a callsite remains static semantics,
+- member lookup driven by the known receiver type also remains static semantics unless it fails earlier due to unresolved imported shell visibility.
+
+Rationale:
+
+- This keeps typing and callable selection together.
+- It prevents linking from becoming a catch-all bucket for any failure that mentions imports.
+
+### 4. Diagnostics And Conformance Need Only A Small Stable Vocabulary
+
+Candidate direction:
+
+- the minimum normative phase vocabulary is:
+  syntax,
+  static semantics,
+  manifest/import resolution,
+  linking,
+  and host-binding/capability admission.
+- tools may subdivide internally, but they should map back to that stable external vocabulary.
+
+Rationale:
+
+- This is enough for source-facing determinism without overfitting to one compiler pipeline.
+
+## Questions To Resolve In The Room
+
+1. Is there real value in naming linking as its own normative phase, or does that add conceptual weight without enough payoff?
+2. Should unresolved barrel entries be considered module-internal static invalidity or linking invalidity?
+3. Should builtin-receiver member lookup failure always stay in static semantics once receiver type is known?
+4. Do diagnostics and conformance need the word `linking`, or only a broader `resolution` bucket?
+5. Does the chosen phase model help or hinder future lowering and verifier specs?
+
+## Expected Outputs
+
+This workshop should produce:
+
+1. a decision record for the PBS phase model around name resolution and linking,
+2. a sorted matrix of failure classes by phase,
+3. a concrete update plan for `14`,
+4. and explicit follow-ups for `11` and `13`.
+
+## Explicit Deferrals
+
+The following topics should be deferred unless unavoidable:
+
+- detailed diagnostic code design,
+- artifact-level failure surfacing,
+- verifier and loader phase internals,
+- and optimizer or backend pipeline naming.
+
+## Inputs
+
+- `docs/pbs/specs/11. Diagnostics Specification.md`
+- `docs/pbs/specs/13. Conformance Test Specification.md`
+- `docs/pbs/specs/14. Name Resolution and Module Linking Specification.md`
+- `docs/pbs/agendas/14. Name Resolution and Module Linking Agenda.md`
+- `docs/pbs/agendas/14.1. Name Resolution Workshop 1 - Scope, Lookup, and Imports.md`
+- `docs/pbs/agendas/14.2. Name Resolution Workshop 2 - Builtin Shells and Host Owners.md`
+- `docs/pbs/agendas/14.3. Name Resolution Workshop 3 - Callable Sets and Cross-Module Linking.md`

docs/pbs/agendas/17. Compatibility and Evolution Policy Agenda.md

@@ -34,6 +34,56 @@ This agenda should produce a policy that is strict enough to protect users and t
 4. Which incompatible changes require migration tooling rather than only release notes?
 5. How are compatibility claims constrained by conformance level and runtime line?
 
+## Proposed Workshop Sequence
+
+### Workshop 1: Compatibility Domains and Promise Levels
+
+Purpose:
+
+- define the domains PBS makes compatibility promises about,
+- and decide the strength of each promise.
+
+Expected decisions:
+
+- source, stdlib, cartridge, artifact, and runtime domain boundaries,
+- and behavioral versus binary compatibility split.
+
+### Workshop 2: Deprecation, Removal, and Migration Duties
+
+Purpose:
+
+- close the lifecycle policy for changes that affect published users.
+
+Expected decisions:
+
+- deprecation windows,
+- removal preconditions,
+- and migration tooling versus documentation-only obligations.
+
+### Workshop 3: Compatibility Matrices and Published Claims
+
+Purpose:
+
+- decide how compatibility claims are expressed across language line, stdlib line, runtime line, and conformance level.
+
+Expected decisions:
+
+- matrix shape,
+- supported-line expectations,
+- and alignment with `13`.
+
+### Workshop 4: Artifact and PBX Compatibility Policy
+
+Purpose:
+
+- decide whether artifact compatibility has an independent policy track from source compatibility.
+
+Expected decisions:
+
+- PBX compatibility promise,
+- runtime-loading compatibility boundaries,
+- and obligations when the artifact line changes.
+
 ## Expected Spec Material
 
 The resulting spec work should be able to add or close sections for:

docs/pbs/agendas/17.1. Compatibility Workshop 1 - Compatibility Domains and Promise Levels.md

@@ -0,0 +1,98 @@
+# PBS Compatibility Workshop 1
+
+Status: Active
+
+## Purpose
+
+Run the first focused discussion for `17. Compatibility and Evolution Policy.md` on the top-level policy model:
+
+- which compatibility domains PBS recognizes,
+- and what strength of promise applies to each.
+
+## Why This Slice First
+
+This slice should come first because every deprecation, migration, and matrix policy depends on a clean definition of domains and promise levels.
+
+## Proposed Meeting Order
+
+1. Reconfirm already-settled governance and versioning inputs.
+2. Close the compatibility domains.
+3. Close the promise level for each domain.
+4. Close behavioral versus binary compatibility terminology.
+5. Record migration and matrix issues for later workshops.
+
+## Decisions To Produce
+
+1. The compatibility domains PBS speaks about normatively.
+2. The promise level for each domain.
+3. The behavioral versus binary compatibility split.
+4. The relationship between claim level and compatibility promise.
+
+## Candidate Decisions
+
+### 1. Recognize Separate Domains
+
+Candidate direction:
+
+- PBS should distinguish at least:
+  source compatibility,
+  stdlib compatibility,
+  cartridge/runtime compatibility,
+  artifact compatibility,
+  and conformance-claim compatibility.
+
+Rationale:
+
+- Different breakages affect different users and toolchains.
+
+### 2. Promise Strength Differs By Domain
+
+Candidate direction:
+
+- source and published-cartridge behavior get the strongest promise,
+- stdlib and artifact domains may have tighter line-based conditions,
+- partial conformance claims get narrower promises than full ones.
+
+Rationale:
+
+- This avoids one vague compatibility slogan that means too many things.
+
+### 3. Separate Behavioral From Binary Compatibility
+
+Candidate direction:
+
+- source-level and runtime-observable behavior compatibility is not the same as artifact binary compatibility,
+- and the policy should state both explicitly.
+
+Rationale:
+
+- This prevents PBX policy from silently driving all evolution policy.
+
+## Questions To Resolve In The Room
+
+1. What are the minimum compatibility domains that PBS must name explicitly?
+2. Which domains deserve the strongest guarantees?
+3. Is cartridge compatibility mainly behavioral, binary, or both?
+4. How does staged conformance affect compatibility promises?
+5. Does stdlib compatibility belong as its own domain or inside source compatibility?
+
+## Expected Outputs
+
+1. a decision record for compatibility domains,
+2. a promise-level matrix draft,
+3. and terminology targets for `17`.
+
+## Explicit Deferrals For Workshop 2
+
+- deprecation windows,
+- migration-tooling duties,
+- and artifact-line change policy.
+
+## Inputs
+
+- `docs/pbs/specs/2. Governance and Versioning.md`
+- `docs/pbs/specs/13. Conformance Test Specification.md`
+- `docs/pbs/specs/17. Compatibility and Evolution Policy.md`
+- `docs/pbs/agendas/13.1. Conformance Workshop 1 - Conformance Claim Levels.md`
+- `docs/pbs/agendas/17. Compatibility and Evolution Policy Agenda.md`
+

docs/pbs/agendas/17.2. Compatibility Workshop 2 - Deprecation, Removal, and Migration Duties.md

@@ -0,0 +1,94 @@
+# PBS Compatibility Workshop 2
+
+Status: Active
+
+## Purpose
+
+Run the second focused discussion for `17. Compatibility and Evolution Policy.md` on lifecycle discipline:
+
+- deprecation,
+- removal,
+- migration duties,
+- and when tooling is mandatory versus documentation-only guidance.
+
+## Why This Slice Second
+
+This slice follows domain definition because the right deprecation and migration policy depends on what kind of surface is changing.
+
+## Proposed Meeting Order
+
+1. Reconfirm the compatibility domains and promise strengths from Workshop 1.
+2. Close deprecation requirements by domain.
+3. Close removal preconditions.
+4. Close migration-tooling versus documentation obligations.
+5. Record matrix consequences for Workshop 3.
+
+## Decisions To Produce
+
+1. Deprecation windows by domain.
+2. Removal preconditions by domain.
+3. Migration-tooling obligations.
+4. The policy for changes that are incompatible but still deliberate.
+
+## Candidate Decisions
+
+### 1. Deprecation Must Precede Removal For User-Facing Stable Surfaces
+
+Candidate direction:
+
+- source and stdlib user-facing surfaces require explicit deprecation before removal,
+- unless the change is confined to a new major line.
+
+Rationale:
+
+- This matches additive-first evolution goals.
+
+### 2. Migration Tooling Is Required Only For High-Frequency Or High-Impact Breaks
+
+Candidate direction:
+
+- some incompatible changes require tooling,
+- others may be served by precise migration notes,
+- and the policy should name the factors that trigger tooling duty.
+
+Rationale:
+
+- This is more realistic than requiring tools for every break.
+
+### 3. Removal Must Be Paired With An Announced Support Boundary
+
+Candidate direction:
+
+- removal is allowed only with a clearly documented support boundary and migration path or explanation.
+
+Rationale:
+
+- This makes policy operational rather than rhetorical.
+
+## Questions To Resolve In The Room
+
+1. Which domains require deprecation before removal?
+2. What triggers mandatory migration tooling?
+3. Can artifact-line changes skip deprecation if they stay behind a new major line?
+4. How should deprecated stdlib APIs be tested in conformance while still supported?
+5. When is documentation-only migration guidance enough?
+
+## Expected Outputs
+
+1. a decision record for deprecation policy,
+2. a decision record for migration duties,
+3. and lifecycle section targets for `17`.
+
+## Explicit Deferrals For Workshop 3
+
+- compatibility matrices,
+- published-claim aging,
+- and artifact compatibility line policy.
+
+## Inputs
+
+- `docs/pbs/specs/2. Governance and Versioning.md`
+- `docs/pbs/specs/13. Conformance Test Specification.md`
+- `docs/pbs/specs/17. Compatibility and Evolution Policy.md`
+- `docs/pbs/agendas/17.1. Compatibility Workshop 1 - Compatibility Domains and Promise Levels.md`
+

docs/pbs/agendas/17.3. Compatibility Workshop 3 - Compatibility Matrices and Published Claims.md

@@ -0,0 +1,97 @@
+# PBS Compatibility Workshop 3
+
+Status: Active
+
+## Purpose
+
+Run the third focused discussion for `17. Compatibility and Evolution Policy.md` on support claims over time:
+
+- compatibility matrices,
+- supported combinations,
+- published claims,
+- and how those claims age or retire.
+
+## Why This Slice Third
+
+This slice follows domain and lifecycle policy because matrix policy is where those choices become operational.
+
+## Proposed Meeting Order
+
+1. Reconfirm domain and lifecycle decisions from Workshops 1 and 2.
+2. Close the shape of the compatibility matrix.
+3. Close what counts as a published support claim.
+4. Close how claims retire or narrow over time.
+5. Record artifact-specific leftovers for Workshop 4.
+
+## Decisions To Produce
+
+1. The compatibility-matrix dimensions PBS must publish.
+2. The policy for published support claims.
+3. The relationship between claims, conformance, and regression.
+4. The retirement policy for supported combinations.
+
+## Candidate Decisions
+
+### 1. Publish A Matrix Across The Major Compatibility Domains
+
+Candidate direction:
+
+- the matrix should cover at least:
+  language line,
+  stdlib line,
+  runtime line,
+  and conformance claim level.
+
+Rationale:
+
+- These are the main axes users will rely on.
+
+### 2. Published Claims Must Be Backed By Conformance Or Regression Evidence
+
+Candidate direction:
+
+- support claims are not just prose;
+- they must correspond to maintained test evidence where support is promised.
+
+Rationale:
+
+- This aligns policy with `13`.
+
+### 3. Unsupported Combinations Must Be Explicit
+
+Candidate direction:
+
+- the matrix must allow explicit “unsupported” states rather than implying silence equals support.
+
+Rationale:
+
+- This reduces accidental ambiguity.
+
+## Questions To Resolve In The Room
+
+1. What exact axes belong in the official matrix?
+2. Must every supported combination have conformance evidence?
+3. How should experimental or provisional combinations be labeled?
+4. When support is dropped, how is that reflected in the matrix and docs?
+5. Which parts of this are policy versus test-harness detail?
+
+## Expected Outputs
+
+1. a decision record for the compatibility-matrix model,
+2. a published-claims policy note,
+3. and alignment tasks for `13`.
+
+## Explicit Deferrals For Workshop 4
+
+- PBX compatibility,
+- binary-loading policy,
+- and artifact-line changes.
+
+## Inputs
+
+- `docs/pbs/specs/13. Conformance Test Specification.md`
+- `docs/pbs/specs/17. Compatibility and Evolution Policy.md`
+- `docs/pbs/agendas/13.4. Conformance Workshop 4 - Regression and Compatibility Matrices.md`
+- `docs/pbs/agendas/17.1. Compatibility Workshop 1 - Compatibility Domains and Promise Levels.md`
+- `docs/pbs/agendas/17.2. Compatibility Workshop 2 - Deprecation, Removal, and Migration Duties.md`
+

docs/pbs/agendas/17.4. Compatibility Workshop 4 - Artifact and PBX Compatibility Policy.md

@@ -0,0 +1,93 @@
+# PBS Compatibility Workshop 4
+
+Status: Active
+
+## Purpose
+
+Run the fourth focused discussion for `17. Compatibility and Evolution Policy.md` on artifact compatibility:
+
+- PBX compatibility,
+- runtime-loading compatibility,
+- and how artifact-line changes are versioned and promised.
+
+## Why This Slice Last
+
+This slice should come last because artifact policy is the most backend-dependent and should be informed by the broader domain and matrix decisions first.
+
+## Proposed Meeting Order
+
+1. Reconfirm the source, stdlib, cartridge, and matrix policy already chosen.
+2. Decide whether artifact compatibility is an independent policy track.
+3. Decide PBX and runtime-loading promise boundaries.
+4. Decide how artifact-line changes are versioned and communicated.
+5. Record final integration tasks for `17`, `15`, and `19`.
+
+## Decisions To Produce
+
+1. Whether artifact compatibility is independent from source compatibility.
+2. The promise boundary for PBX and loader compatibility.
+3. The versioning and communication policy for artifact-line changes.
+4. The relationship between artifact policy and published cartridge support.
+
+## Candidate Decisions
+
+### 1. Artifact Compatibility Is A Distinct Policy Track
+
+Candidate direction:
+
+- PBX and emitted-artifact compatibility should be named explicitly rather than assumed from source compatibility.
+
+Rationale:
+
+- Binary and loader compatibility carry different risks and evolution constraints.
+
+### 2. Runtime Loading Promise Must Be Stated By Supported Line
+
+Candidate direction:
+
+- artifact compatibility should be expressed against explicit runtime and artifact lines,
+- not as a timeless blanket guarantee.
+
+Rationale:
+
+- This keeps the promise honest and testable.
+
+### 3. Artifact-Line Breaks Require Explicit Version Signaling
+
+Candidate direction:
+
+- incompatible artifact changes require an explicit line or major-boundary signal,
+- plus migration or tooling guidance when older published cartridges are affected.
+
+Rationale:
+
+- This aligns artifact evolution with the broader compatibility policy.
+
+## Questions To Resolve In The Room
+
+1. How strong should PBX compatibility promises be?
+2. Are published cartridges protected mainly by source compatibility or by explicit artifact-line support?
+3. What counts as an artifact compatibility break?
+4. Must artifact-line changes always align with major language-version changes?
+5. How should loader support boundaries be documented and tested?
+
+## Expected Outputs
+
+1. a decision record for artifact compatibility policy,
+2. a PBX/runtime promise note,
+3. and final section targets for `17`.
+
+## Explicit Deferrals
+
+- exact PBX layout details,
+- exact loader algorithms,
+- and binary test harness implementation.
+
+## Inputs
+
+- `docs/pbs/specs/6.2. Host ABI Binding and Loader Resolution 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/specs/19. Verification and Safety Checks Specification.md`
+- `docs/pbs/agendas/17.3. Compatibility Workshop 3 - Compatibility Matrices and Published Claims.md`