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