52 lines
1.4 KiB
Markdown
52 lines
1.4 KiB
Markdown
# Packer Decisions
|
|
|
|
This directory contains packer decision records.
|
|
|
|
There are currently no retained packer decision records.
|
|
|
|
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.
|