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 -l in §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-strategy GitHub repo. Build command… Output directory… CNAME setup (Rich picks subdomain)”

  • BUT: CF Pages project tt-inherit-docs ALREADY PROVISIONED at b876b622-e401-49aa-be99-06deaad4af80 (per CF prep session 2026-05-26; memory project_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 ID b876b622-e401-49aa-be99-06deaad4af80). Executing session: push mkdocs.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

  • 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.md as 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:

  1. Coordinator runs final docs-strategy pull to ensure clean state
  2. Apply Wave D LP v1.8 → v1.9 with these findings (5+2 HIGH + 4 MED + 4 LOW + 3 gaps = 17 surgical edits)
  3. Pre-commit hooks expected to reformat (prettier) — re-stage + re-commit per established pattern
  4. Push + verify
  5. Update §10 dispatch reference to “version: 1.9+”
  6. 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