# PBS Frontend IR and Lowering Workshop 2

Status: Active

## Purpose

Run the second focused discussion for `13. Lowering IRBackend Specification.md` on frontend-lowering obligations for:

- expression evaluation order,
- branching behavior,
- and propagation-related constructs at frontend IR boundary.

## Why This Slice Second

After Workshop 1 closes contract/preconditions, this workshop closes construct-level obligations that must be testable in frontend scope.

## Proposed Meeting Order

1. Reconfirm preserved obligations from Workshop 1.
2. Close once-only evaluation obligations in frontend IR terms.
3. Close branch and abrupt-completion representation obligations.
4. Close propagation construct obligations (`optional`, `result`, `!`, `handle`) at frontend boundary.
5. Record callable-category leftovers for Workshop 3.

## Decisions To Produce

1. Which evaluation-order guarantees must remain explicit in frontend IR obligations.
2. Which branch/abrupt-completion facts are mandatory in v1 frontend lowering.
3. Which propagation constructs are in-scope versus deterministic rejection in v1 slice.
4. Which diagnostics are required when unsupported propagation constructs are used.

## Candidate Decisions

### 1. Frontend Lowering Must Preserve Once-Only Evaluation Facts

Candidate direction:

- source-observable single-evaluation points are preserved as explicit lowering obligations,
- independent of one exact IR node taxonomy.

### 2. Branching Obligations Are Normative At Frontend Boundary

Candidate direction:

- selected/non-selected branch semantics remain explicit in frontend lowering contract,
- with no implicit permissive fallbacks.

### 3. Propagation Constructs Have Explicit V1 Status

Candidate direction:

- each construct is marked `supported in v1 frontend lowering` or `deterministic reject`,
- and this status is mirrored in Gate U fixtures.

### 4. Diagnostics Identity Must Be Stable For Unsupported Forms

Candidate direction:

- unsupported forms emit stable code/severity/primary attribution,
- so regression tests can lock behavior.

## Questions To Resolve In The Room

1. Which propagation constructs are fully represented now versus deferred?
2. What minimum frontend IR evidence is enough to prove evaluation-order obligations?
3. Which failures should be classified as parse/static errors versus lowering errors?
4. Which fixture shapes are mandatory for Gate U here?

## Expected Outputs

1. a decision note on expression/control-flow lowering obligations,
2. a decision note on propagation status map (support/reject),
3. and fixture targets for frontend conformance tests.

## Explicit Deferrals For Workshop 3

- callable-category representation details,
- and service/contract/callback-specific obligations.

## Inputs

- `docs/pbs/specs/9. Dynamic Semantics Specification.md`
- `docs/pbs/specs/12. Diagnostics Specification.md`
- `docs/pbs/specs/13. Lowering IRBackend Specification.md`
- `docs/general/specs/13. Conformance Test Specification.md`
- `docs/pbs/agendas/13.1. IR and Lowering Workshop 1 - Lowering Contract and IR Status.md`