Wave D LP v1.8 audit findings (queued for v1.9 surgical fix)
Context
Coordinator ran /review-plan on Wave D LP v1.8 in parallel while Wave C.1 executing session worked on Del 1 description backfill. Read-only verification against actual filesystem state via verify-before-author 6-method toolkit. Findings catalogued here for application as v1.8 → v1.9 AFTER Wave C.1 closes (avoid docs-strategy push contention).
HIGH findings (substrate drift that would mislead executing session)
WD-RP-H1: 601-doc corpus claim is STALE → actual is 609 specs
- v1.8 description: “actual 601-doc corpus” + “~601 docs per smoke-test ST-1 baseline”
- v1.8 §1 step 2 + §2 + §5 forks all cite “601-doc”
- Empirical:
find ~/testatetech/docs-strategy/docs/superpowers/specs/ -type f -name '*.md' | wc -l= 609 - Drift: +8 specs since v1.8 freeze (likely from Wave C session record + Phase-1.5+ master plan + Wave C.1 LP cascade)
- Fix: replace “601” → dispatch-time count (run
find ... | wc -lin §0a verification block); OR pin to “609 at v1.9 authoring + tolerance ±10 at dispatch”
WD-RP-H2: master plan companion pin v1.12 STALE → should be v1.14
- v1.8
companion_files.master_plan.version_pinned:"v1.12" - Current master plan: v1.14 (Wave C closure + Phase-1.5+ Wave E expansion at f25d337)
- Drift: 2 versions
WD-RP-H3: Wave C LP companion pin v1.8 STALE → should be v1.9
- v1.8
companion_files.wave_c_launch_prompt.version_pinned:"v1.8" - Current Wave C LP: v1.9 (per #198 R8 cleanup at d6f165b)
- Drift: 1 version
WD-RP-H4: pin-drift Python script LoC ~1014 STALE → should be 1098
- v1.8 description: “replaces 1,014 LoC of TT-custom Python”
- v1.8 §3 step 1-6 + companion_files.pin_drift_target: “~1014 LoC at S3 spike time”
- Empirical:
wc -l ~/testatetech/docs-strategy/scripts/check-frontmatter-pins.py= 1098 - Drift: +84 LoC since v1.8 freeze
- Fix: re-anchor as snapshot “1014 LoC at S3 spike time (2026-05-25); 1098 LoC at v1.9 author time” OR update to current
WD-RP-H5: §4 step 6 “Wave A.1 CI changelog regen suppression” RESOLVED by Wave C.1 — stale reference
- v1.8 §4 step 6: “Notify on potentially-graduating Wave-E items (annotation-linter OPA, arch-state RDF, mcp_agent_mail, Wave A.1 CI changelog regen suppression)”
- BUT: Wave C.1 Del 3 (now Linear-aligned audit migration) is RESOLVING this. Pilot LIVE at
0c6e066; cascade in flight via executing session. - Post-Wave-C.1, “CI changelog regen suppression” no longer Phase-1.5+ Wave-E queue — it’s DONE (resolved via different mechanism than originally framed).
- Fix: remove “Wave A.1 CI changelog regen suppression” from §4 step 6 Wave-E list; add note “Wave A.1 catch-up resolved via Wave C.1 Linear-aligned audit migration (NOT via actor-guard pattern as originally framed)“
WD-RP-H6: CF Pages provisioned BUT v1.8 instructs executing session to do CF dashboard work
- v1.8 §1 step 4 instructs:
“In Cloudflare dashboard: connect to
testatetech/docs-strategyGitHub repo. Build command… Output directory… CNAME setup (Rich picks subdomain)” - BUT: CF Pages project
tt-inherit-docsALREADY PROVISIONED atb876b622-e401-49aa-be99-06deaad4af80(per CF prep session 2026-05-26; memoryproject_cloudflare_pages_tt_inherit_docs_2026_05_26.md) - Executing session would either redo work OR get confused
- Fix: replace §1 step 4 with “CF Pages project pre-provisioned at
tt-inherit-docs.pages.dev(project IDb876b622-e401-49aa-be99-06deaad4af80). Executing session: pushmkdocs.yml+ verify build fires via GitHub→CF integration; NO CF dashboard work needed (Rich-side parallel work completed 2026-05-26).”
WD-RP-H7: frontmatter v1.5 references → should be v1.6 (post-M5+S2-lock) OR v1.7 (post-Wave-C.1)
- v1.8 description: “Wave C frontmatter v1.5 RECOMMENDED” (description field + companion_files role)
- v1.8 §1 step 1+2+3 + §3 Rego + §5 fork row: “Wave C’s frontmatter v1.5”
- Current state: frontmatter v1.6 LIVE (M5+S2 lock at 4d91f58; 3-tier MADR-5 status vocab + 3.7 forward-traceability)
- Post-Wave-C.1: will be v1.7 (linear_project_id field added per Del 3 companion update)
- Fix: bump v1.5 → v1.6 throughout for body claims; note “v1.7 post-Wave-C.1 close adds OPTIONAL linear_project_id field”
MED findings
WD-RP-M1: Wave C “RECOMMENDED to close first” language is now stale
- v1.8 §0 ceremony + companion_files.wave_c_launch_prompt.role: “Wave C frontmatter v1.5 RECOMMENDED to close first”
- Wave C IS CLOSED (commit 3494467 2026-05-26T07:55 BST); Wave C.1 is IN-FLIGHT addressing deferrals
- Fix: reframe as “Wave C CLOSED at 3494467 (Wave C.1 in-flight addressing deferrals; expected close before Wave D dispatch)“
WD-RP-M2: Path E audit chain-of-pins claim needs verification
- v1.8 §4 close-out step 2 + companion_files.path_e_audit: “Wave B already bumped v1.4 → v1.5 at 5c5372b 2026-05-26; Wave C will bump v1.5 → v1.6 at its close”
- VERIFY: did Wave C close actually bump Path E audit v1.5 → v1.6? Or was that deferred to Wave C.1?
- Fix: empirical verification + correct the chain at v1.9 author time
WD-RP-M3: T1 extrapolation math — 601 → 609 affects the 64s prediction
- v1.8 §1 step 3 + §2: “mkdocs build should complete <30s on ~601 docs IF T1’s linear extrapolation holds (T1 caveat 1 flagged potential 64s at ~230-doc extrapolation; actual corpus is now ~2.6× larger)”
- With 609 not 601: 1.39s × (609/5) ≈ 169s (or ~2.8 min) at linear extrapolation
- Wave D §5 forks already cover “>90s investigate” — but the “32-90s VALIDATED-WITH-NOTE” range may need rethinking at 609-scale
- Fix: update math in §1 step 3 + §2 to reflect 609-doc reality; consider tightening §5 fork thresholds
WD-RP-M4: §3 OPA pin-drift migration LoC at multiple §s
- Same root as WD-RP-H4 but appears at: description + §3 step 6 + companion_files.pin_drift_target
- v1.7 WD-03 fix softened the migration LoC claim (“structural-validation half migrated to ~50-128 LoC Rego; drift-detection half ~890 LoC retained”) but kept the 1014 baseline
- Fix: re-anchor entire §3 baseline to current 1098 LoC OR clearly snapshot to “1014 at S3 spike 2026-05-25”
LOW findings
WD-RP-L1: §10 dispatch reference uses “version: 1.7+” semantic
- v1.8 §8 dispatch: “Verify status: approved + version: 1.7+”
- v1.8 satisfies this (1.8 > 1.7) but cleaner would be “1.8+” or “1.9+” at v1.9
- Fix: bump to “1.9+” at v1.9 author time
WD-RP-L2: §0 ceremony heartbeat format unspecified
- v1.8 §0 ceremony has no explicit heartbeat format (unlike Wave C.1 v1.5’s
[N/6]) - Wave D has 2 mandatory + 1 optional deliverables →
[N/3]format - Fix: add explicit “Heartbeat every 15 min:
Wave D [N/3] — <deliverable status>” line in §0
WD-RP-L3: Linear-aligned audit memory not referenced
- Post-Wave-C.1, the Linear-aligned audit architecture is canonical. Wave D mkdocs site will be the Tier-3 public-facing surface that exposes wave-records.
- v1.8 §0 substrate read list could optionally reference
feedback_linear_aligned_audit_architecture_2026_05_26.mdas upstream context - Fix: optional addition to §0 substrate-read list at v1.9
WD-RP-L4: Wave D vs Wave C.1 Del 3 clarification
- Wave D §3 (OPA pin-drift migration) and Wave C.1 Del 3 (Linear-aligned audit migration) are DIFFERENT migrations
- v1.8 doesn’t explicitly distinguish — could confuse future readers
- Fix: §3 disambiguation note: “this Del 3 (OPA pin-drift) is ORTHOGONAL to Wave C.1 Del 3 (Linear-aligned audit migration for CHANGELOG.md) — different tools, different problems”
Gaps (new substrate to fold in)
WD-RP-G1: New substrate landed since v1.8 freeze
To fold into v1.9 companion_files or §0 substrate-read:
- CF Pages project at
tt-inherit-docs.pages.dev(memory:project_cloudflare_pages_tt_inherit_docs_2026_05_26.md) - Linear-aligned audit architecture (memory:
feedback_linear_aligned_audit_architecture_2026_05_26.md) - Wave C.1 LP at v1.5 (will be closed when Wave D dispatches; treat as PRECURSOR companion)
- Wave C.1 Del 3 pilot at
code-inherit-standard 0c6e066(substrate-correcting finding worth citing) - Wave C.1 execution record (will exist post-Wave-C.1 close; expected ~5-10 honesty caveats per Wave C.1 LP §6)
WD-RP-G2: mkdocs site discoverability for wave-records
Wave D mkdocs site at tt-inherit-docs.pages.dev will surface wave-records (Wave A/B/C/C.1 + future). This is the Tier-3 public-facing surface per Linear-aligned audit architecture. Worth noting as a quality criterion in §1 done criterion: “wave-execution-records discoverable via mkdocs nav under their docs/superpowers/specs/ path”.
WD-RP-G3: §3 OPA pin-drift migration scope clarification post-Wave-C.1
Post-Wave-C.1 Del 3, two changelog-related migrations are conceptually distinct:
- Wave C.1 Del 3 (DONE post-Wave-C.1-close): freeze CHANGELOG.md + delete workflow + Linear-aligned audit tier
- Wave D §3 (OPTIONAL): OPA pin-drift hook migration (different Python script; different validation purpose)
v1.9 should explicitly disambiguate at §3 opening to prevent reader confusion.
Application plan (post-Wave-C.1-close)
After Wave C.1 closes:
- Coordinator runs final docs-strategy pull to ensure clean state
- Apply Wave D LP v1.8 → v1.9 with these findings (5+2 HIGH + 4 MED + 4 LOW + 3 gaps = 17 surgical edits)
- Pre-commit hooks expected to reformat (prettier) — re-stage + re-commit per established pattern
- Push + verify
- Update §10 dispatch reference to “version: 1.9+”
- Then ready to dispatch Wave D execution session
Estimated v1.9 authoring time: ~30-45 min coordinator work.
References
- Wave D LP v1.8:
docs-strategy/docs/superpowers/specs/2026-05-25-wave-d-execution-launch-prompt.md - Master plan v1.14:
docs-strategy/docs/superpowers/specs/2026-05-25-waves-a-d-master-plan.md - Wave C LP v1.9:
docs-strategy/docs/superpowers/specs/2026-05-25-wave-c-execution-launch-prompt.md - frontmatter-conventions.md v1.6:
docs-strategy/frontmatter-conventions.md - Wave C.1 LP v1.5:
docs-strategy/docs/superpowers/specs/2026-05-26-wave-c-1-execution-launch-prompt.md - T1 mkdocs T-file:
~/off-github/library/projects/inherit/T-spike-t1-mkdocs-material-2026-05-25.md - pin-drift script:
docs-strategy/scripts/check-frontmatter-pins.py(1098 LoC) - CF Pages memory:
~/.claude/projects/-home-richardd-testatetech/memory/project_cloudflare_pages_tt_inherit_docs_2026_05_26.md - Linear-aligned audit memory:
~/.claude/projects/-home-richardd-testatetech/memory/feedback_linear_aligned_audit_architecture_2026_05_26.md