1.8 KiB
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/ and propagated into ../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:
- Briefing
- Target
- Method
- Acceptance Criteria
- Tests or Validation
Recommended additional sections:
- Motivation
- Scope
- Non-Goals
- Affected Documents
- 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.