# 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`