Rule: T-file authoring is incomplete until its logging-contract is closed. Both happen within the SAME Claude session — no “I’ll close the cross-links later” pattern. If a session can’t close the logging contract before ending (time pressure / context limit / etc.), it MUST mark this explicitly in the T-file’s frontmatter discipline_compliance: field as a known-gap so the next session picks it up.

Closure components (per plan §0 logging contract; updated 2026-05-02 with S1+S2+S2.5 evidence):

  1. T-file at ~/off-github/library/projects/inherit/T-spike-{slug}-{date}.md per §1.1 frontmatter contract
  2. arch-state §11 (or equivalent evidence index) row LANDED with full evidence + Changelog row + lastmod bump
  3. Q-* file §10 (or equivalent cascade-question section) row LANDED + CHANGELOG entry + lastmod bump
  4. MEMORY.md +1 index entry pointing at new memory file
  5. New memory file project_<slug>_<date>.md (type:project) with substantive findings + cross-references
  6. active-work-log entry updated to current-state reflecting spike closure
  7. (If applicable) plan §1.X briefing for downstream spikes — when the spike outcome has actionable implications for S{N+1}+ dispatchers

All 7 components close in the SAME session as T-file authoring (item 1).

Why: S1 outcome 2026-05-02:

  • T-file authored 2026-05-02T07:01 BST (one minute after plan v1.0 committed; substantive 23KB content with 21-jurisdiction depth-4.6 finding)
  • Logging-contract steps 2-7 NEVER closed in that session — session ended without arch-state cite / Q-* cross-link / memory file / active-work-log update
  • S1’s substantive evidence sat orphaned for 4.5 hours
  • Closure happened ONLY because Rich asked 2026-05-02T11:30 BST: “S1 ran earlier — I wonder if the results were not saved?”
  • If Rich hadn’t surfaced this, S1 evidence might have stayed orphaned indefinitely — Phase E Task 13 lock-decision wouldn’t have seen it; S2-S10 dispatchers wouldn’t have used the SEED-handle table; richard-tasks for partner-firm REVIEW would have stayed unsurfaced

S2 and S2.5 demonstrated correct-pattern:

  • S2: T-file authored 2026-05-02T10:58 BST; logging-contract closed 2026-05-02T11:08 BST (10 min lag — within session)
  • S2.5: T-file authored 2026-05-02T12:25 BST; logging-contract closed 2026-05-02T12:30 BST (5 min lag — within session)

How to apply:

  1. In subagent prompts for spike dispatch: explicitly require closure-within-session as a hard discipline. Per the S3 prompt 2026-05-02 BST: “CLOSE THE LOGGING CONTRACT WITHIN SAME SESSION (per S2 + S2.5 pattern): After Step 8 T-file authoring, also do [arch-state cite + Q- cross-link + memory file + MEMORY.md entry]. S1 anti-pattern (4.5-hour lag between T-file authoring and logging-contract closure) was caught at S2 + fully avoided at S2.5. Continue the discipline.”*

  2. In refined-prompt directive: add as a top-level discipline (v3.6 candidate). Refined-prompt v3.5 step 6e covers spike-outcome capture but doesn’t insist on temporal coupling. v3.6 should add: “If you author a T-file in a session, you MUST close the logging contract (arch-state cite + Q- cross-link + memory file + active-work-log update) before ending the session. T-file authoring without same-session closure leaves substantive evidence orphaned.”*

  3. In plan §0 logging contract: re-number to require steps 2-7 happen “within same session as T-file authoring (item 1)”. Avoid the failure mode of treating §0 steps as a separate Phase E task (which is what S1 essentially did — Phase E Task 12 was to be the cross-link-cascade catch-up, but Rich-discipline is stronger if cascading happens per-spike rather than batched).

  4. For sessions that genuinely can’t close in-session (rare; usually time pressure or context-window limit): mark T-file frontmatter discipline_compliance: with LOGGING-CONTRACT-DEFERRED-TO-NEXT-SESSION and add a top-line entry in active-work-log: **[LOGGING-CONTRACT-PENDING]** for T-spike-{slug}-{date} — close in next session. Otherwise this evidence is orphaned. This makes the gap loud rather than silent.

  5. For new sessions that find a logging-contract-pending entry: prioritise closing it BEFORE starting any new spike work. Discipline-debt accumulates fast; closing within a few hours is a working compromise; closing within days is unacceptable.

Boundary tests (when this rule fires STRONGLY):

  • ✓ Any spike-Q (S1-S10 in current ε.ι derisking suite; same pattern for future spike suites)
  • ✓ Any architectural amendment (A-N row authoring) that has cross-link implications for arch-state + Q-* + memory
  • ✓ Any decision-quality artefact (scorecard / WR-file / audit-record) that should propagate to load-bearing locations

Boundary tests (when this rule does NOT apply):

  • ✓ Throwaway exploratory work (a cat /tmp/explore.py doesn’t need logging-contract closure — but writing a T-file does)
  • ✓ Scratch notes that won’t influence load-bearing decisions

Codification trigger: S1 anti-pattern 2026-05-02 — T-file authored at 07:01 BST but logging-contract steps NEVER closed at the time. Detected at 11:30 BST when Rich asked “S1 ran earlier — I wonder if the results were not saved?”. Closing-cascade then took ~15 min (which would have been ~5 min if done immediately at T-file authoring). S2 + S2.5 both followed correct-pattern after this lesson; rule fully validated.

Related memories:

  • project_zeta_q3_eps_iota_S1_2026_05_02.md — the anti-pattern instance (T-file 07:01; closure 11:45)
  • project_zeta_q3_eps_iota_S2_2026_05_02.md — first correct-pattern demonstration (T-file 10:58; closure 11:08)
  • project_zeta_q3_eps_iota_S2_5_owlready2_rescue_2026_05_02.md — second correct-pattern demonstration (T-file ~12:25; closure ~12:30)
  • feedback_architecture_state_file_discipline.md — the broader “update arch-state after every tension-lock” discipline this rule extends

Forward integration:

  • Refined-prompt v3.6 candidate: add as a top-level methodology rule (Step 11 or extension to existing Step 9)
  • Plan §0 logging contract: re-number “within same session as T-file authoring (item 1)”
  • T-file frontmatter contract §1.1: add logging_contract_closure_timestamp: field for forensic audit