# Packer Decisions

This directory contains packer decision records.

Retained packer decision records:

- [`Concurrency, Observability, and Studio Adapter Boundary Decision.md`](./Concurrency,%20Observability,%20and%20Studio%20Adapter%20Boundary%20Decision.md)
- [`Filesystem-First Operational Runtime and Reconcile Boundary Decision.md`](./Filesystem-First%20Operational%20Runtime%20and%20Reconcile%20Boundary%20Decision.md)

The first packer decision wave was already consolidated into:

- normative specifications under [`../specs/`](../specs/)
- didactic material under [`../learn/`](../learn/)

## Purpose

A decision record is the bridge between packer discussion and packer execution.

Use this directory to capture:

- what was decided,
- why that direction was chosen,
- which constraints now apply,
- what remains intentionally undecided,
- which specs, plans, tests, or implementations must be updated.

A decision should be stable enough that a spec or implementation worker can act on it without reconstructing the original debate.

## Expected Format

A packer decision should usually include:

1. Title
2. Status
3. Date or Cycle
4. Context
5. Decision
6. Invariants and Constraints
7. Explicit Non-Decisions
8. Propagation Targets
9. Validation Notes or Examples

## Writing Rules

- State the adopted decision early and clearly.
- Write in stable language, not in exploratory tone.
- Capture architectural constraints explicitly.
- Record what is still not decided so later work does not guess.
- Point to the exact packer specs, PRs, or code areas that need propagation.

## Implementation Rule

If implementation work reveals a missing decision, do not infer it.
Return the issue to agenda or decision review.