Lock-cascade discipline — 5 mandatory artefacts per Q-lock
Rule: every Q-lock decision (refined-prompt-era ζ.2 audit Qs Q-NNN under v3.0+) MUST author all 5 mandatory artefacts in checklist order BEFORE committing.
Why: between Q-027 and Q-031 (2026-05-17 → 2026-05-18), 5 consecutive net-new locks landed via arch-state lastmod prose + spike-reference + memory only — WITHOUT formal cascade-Q files at answered-questions/Q-NNN-zeta-<topic>-locked.md. This silent-drift fragmented the forensic audit trail (no single locus for full scorecard + 8 options + persona pass + sub_clarifications), broke cross-Q citation (citations like “per Q-031 P-10 (b)-fold” had no anchor file), and failed the acquirer-DD readability test (DD reviewers couldn’t assemble decision context from 3-4 fragmented files). Rich-directive 2026-05-18T10:00 BST: “ensure that this does not happen again.”
How to apply: at lock-cascade time, author the 5 mandatory artefacts in this exact order:
| # | Artefact | Path | Notes |
|---|---|---|---|
| 1 | Cascade-Q file (FIRST) | docs/superpowers/specs/2026-04-29-multi-phase-audit/answered-questions/Q-NNN-zeta-<topic>-locked.md | Full forensic record. ~800-1500L for net-new Qs; ~150-250L STUB permitted ONLY for super-amendments where prior cascade-Q file already captured full decision context (e.g., Q-025.1 light cycle re-validate over Q-025). |
| 2 | Arch-state amendment | docs/superpowers/specs/inherit-v2-architecture-state.md | Bump version: (minor for single lock, major for wave close); extend lastmod: scalar with em-dash prose. Cumulative — never replace prior prose. |
| 3 | Memory file | ~/.claude/projects/-home-richardd-testatetech/memory/project_zeta_q<NNN>_locked_<slug>_<date>.md | Compressed ~150L summary. Working-memory substrate; NOT a replacement for cascade-Q file. |
| 4 | Active-work-log entry | project_active_work.md | One-line append per closed Q-lock. |
| 5 | MEMORY.md index entry | MEMORY.md (top) | Rich single-line index pointer with Wsum + margin + key facts matching the Q-031/Q-030/Q-029 cadence. |
4-layer enforcement mechanism (codified 2026-05-18):
- PROMPT-level:
refined-end-of-turn-directive.mdv3.16 §1 step 1 enumerates the 5 artefacts as MUST-checklist + adds pre-flight boundary-test. - TOOLING-level:
~/testatetech/docs-strategy/scripts/check-lock-cascade-completeness.py(pre-commit hook) refuses any commit that bumps arch-stateversion:WITHOUT a pairedanswered-questions/Q-NNN-*-locked.mdin the same commit. The strongest layer — mechanically unbypassable except via--no-verify(which must be justified in commit body). - MEMORY-level (this file): auto-loads in TT-scoped sessions; read-time enforcement.
- META-Q audit-trail:
meta-questions/MQ-006-cascade-q-file-discipline-locked.mdrecords the decision + drift incident + enforcement layers.
Retrospective remediation (2026-05-18): Q-027..Q-031 received lightweight STUB cascade-Q files (~150-250L each) restoring ls answered-questions/ discoverability for every locked Q. Q-032 onwards — full cascade-Q files (~800-1500L). MQ-006 records the rationale.
Anti-patterns to refuse:
- “I’ll just update arch-state lastmod prose + memory + spike-reference” — drift signal. STOP and author the cascade-Q file FIRST.
- “The cascade-Q file would duplicate the memory” — false. Cascade-Q file is the DURABLE FORENSIC RECORD; memory is the WORKING-MEMORY COMPRESSION. They serve different consumers (acquirer-DD vs ongoing-session-Claude).
- “Skipping cascade-Q is faster” — true (~30-45 min faster per Q), but the Year-2 cost of re-deriving 5+ locks worth of decision context dwarfs the cadence saving. Acquirer-DD scenario is load-bearing.
- “Super-amendments don’t need cascade-Q files” — partially true (light-cycle re-validates may use stub format), but the parent lock STILL needs a cascade-Q file. Cluster super-amendments like Q-026.2 / Q-027.2 still need either a fresh file or an extension to the parent file.
Boundary test (apply before staging arch-state):
git status | grep -E "answered-questions/Q-\d+.*-locked\.md"If output is empty AND arch-state.md is modified, STOP. The pre-commit hook will refuse the commit anyway; better to catch at staging time.
See also:
[[refined_prompt_v3_16_lock_cascade_discipline]]— v3.16 directive (this discipline’s prompt-level layer)[[mq_006_cascade_q_file_discipline_locked]]— meta-Q decision record[[project_zeta_q031_locked_delta_eta_star_grant_of_representation_mvp_2026_05_18]]— example Q-031 drift incident (no cascade-Q file authored at lock time; stub authored retrospectively 2026-05-18)[[feedback_architecture_state_file_discipline]]— sister discipline (arch-state always-current); this discipline ensures arch-state bumps are PROPERLY ANCHORED to a Q-NNN file[[feedback_research_artefact_forward_traceability]]— sister discipline (forward-traceability frontmatter); cascade-Q file is the forward-traceability anchor for the lock decision itself