69 lines
1.8 KiB
Markdown
69 lines
1.8 KiB
Markdown
# Packer Pull Requests
|
|
|
|
This directory contains self-contained packer change proposals for review.
|
|
|
|
Current retained set:
|
|
|
|
- none
|
|
|
|
The previous execution wave has already been consolidated into [`../learn/`](../learn/) and propagated into [`../specs/`](../specs/).
|
|
|
|
## Purpose
|
|
|
|
A pull request document packages a packer change as an executable plan before final integration.
|
|
|
|
Use this directory when a change:
|
|
|
|
- touches multiple documents or code paths,
|
|
- changes packer architecture or semantics,
|
|
- needs explicit acceptance criteria,
|
|
- affects diagnostics, build outputs, registry rules, or shipper boundaries,
|
|
- should be reviewed before editing the final normative corpus or implementation.
|
|
|
|
## Required Properties
|
|
|
|
Every pull request document must be self-contained.
|
|
|
|
A reviewer should be able to understand:
|
|
|
|
- the problem,
|
|
- the target state,
|
|
- the execution method,
|
|
- the acceptance bar,
|
|
- and the validation surface.
|
|
|
|
## Required Sections
|
|
|
|
Each packer pull request should include, at minimum:
|
|
|
|
1. Briefing
|
|
2. Target
|
|
3. Method
|
|
4. Acceptance Criteria
|
|
5. Tests or Validation
|
|
|
|
Recommended additional sections:
|
|
|
|
6. Motivation
|
|
7. Scope
|
|
8. Non-Goals
|
|
9. Affected Documents
|
|
10. Open Questions
|
|
|
|
## Writing Rules
|
|
|
|
- Keep the proposal self-contained and reviewable.
|
|
- Separate architectural reasoning from implementation detail.
|
|
- Make packer outputs and contracts explicit.
|
|
- Do not smuggle unresolved product or architecture choices into implementation steps.
|
|
- If a required decision is missing, stop and raise it instead of guessing.
|
|
|
|
## Review Rule
|
|
|
|
A pull request may plan code and spec consequences, but it must not replace a missing decision record.
|
|
|
|
## Production Sequence
|
|
|
|
When a new execution wave starts, add only the PRs that still represent pending work.
|
|
Do not repopulate this directory with already-absorbed historical implementation slices.
|