Master plan §16 Wave LP authoring contract LOCKED 2026-05-26
Rule
Every Wave launch-prompt (Wave A through future Waves N) MUST reference the Waves A-D master plan in 4 places per master plan §16:
| # | Element | Where in LP | Forcing function |
|---|---|---|---|
| 1 | companion_files.master_plan block with pin_kind: floor + version_pinned | LP frontmatter | Pin-drift hook flags stale floor-pins (semantic floor-satisfaction tolerates v1.X+) |
| 2 | Master plan as FIRST entry in §0 substrate-read list with ★ bold markers + “REQUIRED FIRST READ” | LP §0 ceremony | Visual force-attention prevents skipping during ceremony |
| 3 | Master plan in §7/§10 References row with current version pin | LP §7 References | Cross-reference for future readers (Steven Day-1; future-Claude post-compaction) |
| 4 | NEW step in §4 close-out: “Master plan update (REQUIRED per §16 contract)” with v1.X → v1.X+1 IN-FLIGHT bump in same atomic commit as execution record | LP §4 close-out | Atomicity ensures master plan never drifts behind wave closures by ≥1 commit |
Why: Rich-directive 2026-05-26T~11:55 BST after empirically observing “the master plan is sometimes being forgotten.” Over the Wave A → B → C → C.1 arc the master plan accumulated multi-wave stale lag (Wave C.1 closure data missing for ~24h until v1.16; Model C era absorbed only when v1.16 caught up). Wave LPs had inconsistent master-plan references — sometimes mid-position in §0 substrate-read, sometimes only via companion_files, sometimes not at all in §4 close-out. §16 makes the coupling explicit and contractual.
How to apply: when authoring any new wave LP (Wave A through future Waves N), run the §16.3 compliance audit bash one-liners before commit:
LP=docs/superpowers/specs/2026-MM-DD-wave-X-execution-launch-prompt.md
echo "Check 1 (companion_files block):"
grep -A 5 '^ master_plan:' "$LP" | head -6 || echo "FAIL: no master_plan companion_files block"
echo "Check 2 (§0 substrate-read FIRST + bold markers):"
grep -B 1 -A 1 'Waves A-D master plan' "$LP" | grep -E 'Read substrate|★' || echo "FAIL: master plan not bolded/starred in §0"
echo "Check 3 (§7/§10 References):"
grep -E '^- (\*\*)?(Waves A-D )?[Mm]aster plan' "$LP" || echo "FAIL: no References entry"
echo "Check 4 (§4 close-out master-plan-update step):"
grep -A 1 'Master plan update' "$LP" || echo "FAIL: no §4 close-out master-plan-update step"If any check fails, the LP needs a v1.X → v1.X+1 surgical update before dispatch.
Empirical validation (first day)
§16 was authored 2026-05-26T12:00 BST as part of master plan v1.16. The §16.3 compliance audit was immediately run on the v1.16 sister-update Wave D LP v2.0.2 (the LP that introduced §16-compliance). Result: §16.3 found 4 stale v1.15 master plan references in v2.0.2’s live-body (description + purpose + companion_files.master_plan.version_pinned + §7 References row). Floor-pin semantics had silently tolerated them (v1.16 ≥ v1.15 satisfies a v1.15 floor). The 4 refs were bumped v1.15 → v1.16 as Wave D LP v2.0.3 at commit 2069810.
This is exactly the dogfood pattern the discipline is designed to catch. The policy caught its own first-day violation; semantic floor-pin satisfaction ≠ explicit currency.
The 3 drift modes §16 prevents
- Master plan pin lag — companion_files version_pinned becomes stale (Wave D LP v1.8 pinned master plan v1.12 when actual was v1.15); reader can’t tell which wave’s substrate is canonical
- Master plan content lag — wave closure data lands in execution-record but not in master plan (Wave C.1 closure landed in execution-record v1.0 but master plan §4.5 + §8 table didn’t get the row until v1.16); cross-wave audit is incomplete
- Substrate-read forgetfulness — executing session reads LP but doesn’t pull up the master plan, missing cross-wave context (prior wave caveats + velocity calibration + dependency graph + Phase-1.5+ scope boundary)
§16 closes all 3 via the same forcing function: master plan is FIRST in §0, REQUIRED in §4 close-out, contractually-referenced everywhere else.
Compliance status (as of 2026-05-26T12:10 BST)
| Wave LP | §16-compliant? | Reason |
|---|---|---|
| Wave A LP v1.0 | N/A frozen | F-15 historical artefact; no retroactive compliance required |
| Wave B LP v1.4 | N/A frozen | F-15 historical artefact |
| Wave C LP v1.9 | N/A frozen | F-15 historical artefact |
| Wave C.1 LP v1.5 | N/A frozen | F-15 historical artefact |
| Wave D LP v2.0.3 | ✅ COMPLIANT | First §16-compliant LP at commit 2069810 |
| Future wave LPs (E/F/G/H/I) | TBD | Author per §16 contract from outset |
Forward-compliance applies to all new wave LPs from 2026-05-26T~12:00 BST forward. Closed waves are frozen-by-design.
Cross-references
- Master plan §16:
docs/superpowers/specs/2026-05-25-waves-a-d-master-plan.mdv1.16+ (commitda9755b) - Wave D LP v2.0.3 (first compliant):
docs/superpowers/specs/2026-05-25-wave-d-execution-launch-prompt.mdv2.0.3 (commit2069810) - /review-plan output that surfaced the need: this session 2026-05-26T~11:55 BST
- Companion forcing-function in frontmatter-conventions: TBD (Phase-1.5+ candidate — add a global section about cross-doc reference contracts)
Related memories
- project-wave-d-lp-v2-0-model-c-restructure-2026-05-26 — Wave D LP arc up to v2.0.3
- feedback-research-artefact-forward-traceability — sibling discipline (forward-traceability is the WHY; §16 is the HOW for master-plan-↔-LP specifically)
- feedback-lp-t-file-substrate-audit-pre-dispatch — pre-dispatch substrate audit pattern (§16.3 audit is the master-plan analogue)
- feedback-conftest-rego-dogfood-self-validation-pattern — schema-validates-its-own-author paradigm; §16.3 caught its own first violation in same family