feedback_architecture_state_file_discipline

Rule

After every Phase-5 tension-lock (parent and each sub-decision), update docs/superpowers/specs/inherit-v2-architecture-state.md:

• Bump lastmod (ISO 8601 with minute precision)
• Bump version (minor for single lock, major for wave-close)
• Append a row to changelog with scorecard reference + amendment numbers
• Update the relevant section(s): modules / primitives / Shape X / amendment-registry / open-tensions / Phase-1.5 cell-count
• Commit: docs: architecture-state v{X.Y} — {tension-id} {lock-summary}

Before producing any strategic output that references v2 module names, primitive counts, amendment numbers, Shape X angles, or Seq G1 positions — read the state file first. Do not produce the output from working-memory of what was decided.

Why

Prior incident (2026-04-24, within this session): Produced a strategic “what should we do to make v2 + InheritKit as good as possible?” message that listed 7 modules with “Catalogue” as the 6th — silently missing both:

1. T-005 F sub-decision 1 (Commerce rename, 94.0%) — locked same session
2. Q3 B (8th Transfer module added at pos 3, 92.0%) — locked same session

The information was fully in the repo (scorecards + adjudication-log + memories), but when producing strategic output I answered from context-memory rather than cross-checking the lock artefacts. By the 10th hour of the session the context held decision narratives while precise names and positions drifted.

Rich’s response: “I am nervous that you are forgetting things like our decision to rename Catalogue to Commerce, and that we added Transfer. What is the best way to ensure these decisions are not lost?”

Root cause: No single canonical live-state document existed. Scorecards are per-decision; adjudication-log is prose-history; memories are per-topic; MEMORY.md is one-line index. None of them answer the question “what IS the current 8-module list right now?” in one place.

Fix: One state file + one discipline. The file exists as inherit-v2-architecture-state.md with extensive frontmatter documenting its own read_before / update_trigger / update_procedure. The discipline is this memory + the docs-strategy CLAUDE.md pointer (auto-loads every session). Together they survive context compaction AND fresh-session resumption.

How to apply

When locking a tension/sub-decision:

1. Commit the scorecard (per feedback_always_save_scorecards)
2. Append to adjudication-log with amendment numbers
3. Update inherit-v2-architecture-state.md — this is the step that closes the loop
4. Bump the registry version in the state file frontmatter if an amendment was added
5. If the lock cascades to other docs (brand-architecture.md §modules, partner-model §Shape B, etc.), either fix those now or flag them for a later cascade-sweep

When answering a strategic question about v2:

1. Read inherit-v2-architecture-state.md first (even if you remember the answer)
2. Cross-check module names, amendment numbers, primitive counts against the file
3. Then produce the output
4. If the file is stale (lastmod looks old + recent scorecards suggest a lock happened), flag it to Rich rather than producing from memory

Red flag: if about to produce strategic output and you notice you’re relying on “I remember we decided…” rather than “the state file says…” — STOP. Read the file.

Compounding with other disciplines

• feedback_always_save_scorecards: scorecards are the audit trail; state-file is the current state. Both persist. Scorecards without state-file = drift. State-file without scorecards = unauditable.
• feedback_always_display_full_scorecard: display in chat for Rich; persist in scorecard file; update state-file. Three surfaces, each serving a different purpose.
• feedback_scorecards_one_at_a_time_optimal_sequence: each sub-decision lock updates the state-file. Parent + sub-decisions = multiple state-file updates per tension.
• feedback_automatic_deep_dive_when_options_feel_imperfect: when a deep-dive produces a new Option (e.g., G6-7 B’), the state-file captures the locked option after the scorecard closes — not the pre-dive options.

Cascade-update targets (when state-file changes affect other docs)

After updating state-file, consider whether these need cascade-updates:

• brand-architecture.md §modules (single-line module-list references)
• docs/superpowers/specs/2026-04-22-inherit-v2-architecture-proposal.md v1.12 §7-module list (becomes 8-module)
• docs/superpowers/specs/2026-04-19-inherit-v2-roadmap.md v1.5 (if timeline or module-count-dependent)
• docs/superpowers/specs/2026-04-20-inherit-v2-critique-ready-spec.md v1.0 (mega-spec with 250 claims)
• partner-model v2.5 §Shape B (Commerce-scope references)
• feedback_v2_asset_catalogue_scope memory (canonical-primitive-count evolution)
• project_shape_x_full_lock_2026_04_23 memory (8-angle lock record — needs module-count update to 8)
• Active work log Seq G1 section (if still carries pre-Q3B 7-module ordering)

These do not all need to be updated synchronously; but flag them as known-stale if the state-file has diverged.