feedback_lp_t_file_substrate_audit_pre_dispatch

Before dispatching any Wave (or any execution session that consumes spike T-files via an LP), the coordinator MUST scan the LP for T-file citations and verify against the actual T-files. T-file claims drift between authoring and dispatch — the executing session is right to follow the T-file (empirical source) when the LP miscites, but catching the miscitation pre-dispatch saves dispatch friction and preserves the LP as a reliable substrate.

Why: Wave B execution session caught a substrate-correcting finding (record §3.6, locked 2026-05-26): Wave B LP v1.4 §1 step 1’s N1 fork DEFAULT cited “SDK-as-host” for U2 @inherit/* package hosting. The U2 T-file §7 actually recommends code-inherit-standard. The LP miscitation would have produced a worse-architected solution (SDK as host couples one consumer to package-host status; harder to detach later). Executing session followed the T-file correctly — but this is exactly the verify-before-author discipline (global CLAUDE.md §13.6) the coordinator session should apply BEFORE dispatch, not the executing session AFTER.

How to apply:

1. For each LP that’s queued for dispatch (Wave C v1.7, Wave D v1.6 at time of locking), grep for T-file citations:

   grep -nE "T-spike-[a-z0-9-]+|T[0-9]+[^_-]|suite-[0-9] [SU][0-9]+" <wave-X-execution-launch-prompt.md>

2. For each citation, read the cited T-file’s relevant section (usually §“hosting decision” / §7 / §“recommendation” / §“VALIDATED” depending on T-file’s structure).
3. Compare LP claim against T-file content:
   • Hosting recommendations: which repo?
   • LoC reduction claims: aggressive parameterisation figure (T-file claim) vs conservative pure-config figure (likely actual)?
   • Vendor/library names: does LP name vendor X but T-file evaluated vendor Y?
   • Version pins: does LP cite version N but T-file validated against N-1?
4. If any miscitation found: either (a) fix the LP pre-dispatch (treating it as a P-round revision), OR (b) capture the correction in the executing session’s launch-prompt body as a “substrate-correcting note” so the executing session is aware before running.
5. Default: pre-dispatch fix is better than executing-session-correction (catches drift earlier; preserves LP as load-bearing substrate).

When this rule applies:

• Pre-Wave-C dispatch (this coordinator session)
• Pre-Wave-D dispatch
• Any future wave / phase execution that consumes spike T-files via an LP
• Generalises beyond waves: any execution session reading a substrate doc that cites external research artefacts (T-files, indexed/ library books, suite findings docs)

Sister rules / related disciplines:

• verifying-before-author skill (global CLAUDE.md §13.6) — the 6-method toolkit for verifying claims before embedding in substrate
• feedback-research-artefact-forward-traceability — phase_q_relevance: + structured companion_files: so the LP knows what T-files it cites
• project-wave-b-closed-2026-05-26 §3.6 — the empirical case that triggered this lock
• feedback-actively-use-t-files-in-scorecard-authoring — companion rule for scorecard authors (don’t substitute prior-knowledge alternatives for T-file-cited ones)

Anti-pattern this rule prevents: dispatching a wave whose LP cites T-file X recommending Y, where T-file X actually recommends Z. Executing session either (a) follows the wrong LP and produces worse architecture, or (b) catches the drift mid-execution and HALTs, costing time. Both outcomes worse than a pre-dispatch grep + verify pass (~5 min for typical wave LP).