Launch-prompt scope-framing at rule-statement granularity

Rule: when authoring a launch-prompt for a downstream session that will edit a procedural-prompt-layer artefact (~/.claude/CLAUDE.md, refined-end-of-turn-directive.md, CASCADE-Q-TEMPLATE.md, patterns/README.md, BUILD-ORDER.md, or similar), the launch-prompt’s §0 Decision Matrix MUST include a sub-section that enumerates verbatim the specific rule statements being promoted — not just a reference to the source paper section or scope-framing phrases like “promote toolkit” or “codify methods”. This grants Rich-approval at the rule-statement layer, not just the batch-commission layer.

Why: BATCH ρ on Wednesday 20 May 2026 (commit 6f9197a / arch-state A-226) promoted the verify-before-author toolkit from 2026-05-19-verify-before-author-precedent-paper.md v1.1 §10.4 ADOPTION-RECOMMENDED status to ~/.claude/CLAUDE.md §13.6. The launch-prompt I authored framed scope as “Codifies 5+1 verify-before-author methods … as MANDATORY for all TT-scoped sessions” + “operational toolkit”. Rich approved BATCH ρ via “I want to do 1, 3, 4” pick from my recommendation set. The executing session then pulled paper v1.1 §10.4 content verbatim, which included a procedural MUST sentence: “Every load-bearing substrate claim about an external authoritative source MUST cite the verification chain inline. A claim without a runnable verification command is not load-bearing — mark it (candidate; verify before use) per §13.5 rule 3.” That MUST sentence is operationally stronger than “promote toolkit” implied — it’s a procedural-MUST-gate, not just an operational-reference-toolkit. Rich was not separately asked to approve the specific rule statement. The transitive-approval-chain (Rich approved batch → batch authored prompt → prompt referenced paper section → paper section contained MUST sentence) had a granularity-gap. Rich caught it later in the same session via Rich-recall (“we discussed adding a rule that insisted that all facts must be verified online. however, i do not believe we agreed for that to be implemented”) and triggered partial-reversion arch-state A-228 / ledger task-115 / commit bd595dd removing the MUST sentence while retaining the methods toolkit + anti-patterns as descriptive reference.

How to apply: when authoring a launch-prompt that names a procedural-prompt-layer artefact in companion_files.<key>.path with role: PRIMARY TARGET (or similar “WRITE” intent), the launch-prompt’s §0 Decision Matrix MUST contain a dedicated fork — typically #N Rule statements being promoted — that quotes verbatim each load-bearing rule statement to be added or modified. Format:

| N | **Rule statements being promoted** | Enumerated below (Rich-approval REQUIRED at rule-statement granularity before BATCH commission): followed by a numbered list of verbatim rule statements, each tagged (MUST / SHOULD / MAY / descriptive-reference) so the procedural-strength is explicit. If the source paper has a single proposed rule, quote it once. If multiple, list all. DO NOT collapse to “extract from paper §X.Y” — that re-opens the granularity-gap.

This applies regardless of the source paper’s ADOPTION-RECOMMENDED status. A paper recommending a procedural MUST does not equal Rich-approving a procedural MUST. The launch-prompt is the explicit-approval gate; if the rule isn’t in the launch-prompt at rule-statement granularity, the executing session has implicit licence to weaken or strengthen the rule as it pulls source content, and Rich’s batch-commission pick doesn’t constitute granular approval.

Trigger boundary-test: before sending a launch-prompt that touches a procedural-prompt-layer artefact — re-read your own §0 Decision Matrix. If you cannot point to a section that quotes verbatim the rule statements being promoted, the launch-prompt is not ready. Add the section + re-confirm with Rich at rule-statement granularity OR scope-narrow the batch to “operational reference only, no procedural-MUST framing”.

Procedural-prompt-layer artefact inventory (current as of 2026-05-20; verify before authoring):

  • ~/.claude/CLAUDE.md (global)
  • ~/testatetech/CLAUDE.md (parent workspace)
  • ~/testatetech/docs-strategy/CLAUDE.md (project)
  • docs-strategy/.../refined-end-of-turn-directive.md (cascade-Q authoring prompt)
  • docs-strategy/.../CASCADE-Q-TEMPLATE.md (cascade-Q file template)
  • docs-strategy/.../patterns/README.md (pattern doc index — gates discoverability flow)
  • docs-strategy/.../BUILD-ORDER.md (Q-lock NEXT-UP signal)
  • docs-strategy/.../inherit-v2-architecture-state.md (§15 amendment registry — semantic content, not procedural; lower-risk but still load-bearing)
  • per-repo CLAUDE.md files (in-scope: code-inherit-v2 + code-inheritkit + code-ias + code-inheritv2-www + code-inheritv2-test-suite)

Late-binding form: Rich-recall is the late-binding form of this discipline — even post-commit, the principle can catch transitive-approval gaps and trigger partial-reversion (BATCH ρ A-226 → A-228 partial-reversion precedent commit bd595dd). But late-binding costs are real: arch-state amendments + ledger entries + partial-reversion forensic narrative. Catching at launch-prompt-authoring time is cheaper than catching at Rich-recall time.

Companion: feedback_research_artefact_forward_traceability (sibling write-time discipline — research artefacts must declare downstream consumers); feedback_post_commit_body_content_verification (sibling verify-time discipline — post-commit grep-verify catches frontmatter-only landings); feedback_claude_does_research_inline_at_q_lock_time (sibling Q-lock-time discipline — fetch inline rather than spawn Paul-bound task); arch-state §15 A-228 row (the partial-reversion precedent); commit bd595dd (the partial-reversion commit).