dotfiles/claude/memory/session-2026-09-03-the-index-had-become-the-record.md

name, description, type, metadata

name	description	type	metadata
Session 2026-09-03 — the index had become the record	A short, single-bite session. The wake reported MEMORY.md over its load budget and being silently truncated; the fix was not pruning but a diagnosis — five tracker entries had grown into paragraphs and for three of them the index was the SOLE custodian of live state (the studium tracker had stopped at 2026-08-13 while the index carried engine news to 09-01; the Fool's only link was a sealed seed with nowhere to append; L1's replay mechanism and completion criterion existed nowhere else). Relocated verbatim under the lossless-relocation gate; Tarbuckle got a tracker; 26,803 -> 23,714 bytes. Also found: the wake digest's selftest now fails permanently because all 13 transcripts in its end-to-end sample are Tarbuckle mumbles — PENDING-178's defect at a second site. PULLING THREAD: unchanged — the fr cell's last two steps.	project	node_type type modified memory project 2026-09-03

Session 2026-09-03 — the index had become the record

A deliberately short session. The steward's instruction was exact: "Let's deal with the memory load-integrity breach, wrap and start again." One bite, taken all the way, then out.

PAST — what moved, and why

The breach was not bulk, and pruning would have been the wrong fix

The wake's load-integrity gate fired: MEMORY.md at 26,803 bytes against a 24,986-byte ceiling, so the harness loaded only part of the index and said so in small print. The gate exists because a truncated index reads as complete — the wake cannot know what it did not see.

The obvious move is to cut. Diagnosing first changed the answer. A per-line byte map showed the overflow concentrated in five Canonical Workstream Tracker entries, which is precisely where the file's own Index discipline section forbids detail: "Canonical Trackers as one-line pointers — chronological detail lives in the linked tracker files, not here." So the file was in breach of a rule it states about itself.

⚠ Then the duplication check turned a tidying job into a finding. For three of the five, the detail was not in the tracker at all — the index had become the workstream's sole custodian:

• Studium Engine — the tracker's chronological log stopped at 2026-08-13; the index carried engine state through 2026-09-01 (REVIEWED-133, 496cd7e, the deleted undisclosed_days_in_force). Zero of those tokens appeared in the tracker. Three weeks of the most active workstream lived only in a summary line in a file that was being truncated.
• The Fool (Tarbuckle) — its only link went to FOOL-BONES-2026-08-25.md, a sealed seed. A sealed seed is by rule not a place state may be appended, so there was nowhere legitimate for its state to go. It was the one active workstream in the list with no tracker.
• L1 reliability — the tracker records replay is "not resumable" but neither the mechanism (minCursor is a minimum over 11 modules and two never participate, so it is pinned at 0 by construction, not by accident) nor the completion criterion (uninterrupted run length, not rate — a faster machine does not finish the replay; only a longer unbroken run does).

What was done

Under the ladder's lossless-relocation gate — line-range slices, never retyping, md5 per slice:

• Studium state relocated verbatim into the tracker's chronological log, with provenance.
• project-fool-tarbuckle.md established — Tarbuckle's first tracker; index line moved into it verbatim, carrying the 2026-08-31 substrate correction (the line that had said "NOTHING WIRED", false on all three clauses). Its four links verified to resolve.
• L1's two missing facts appended to project-L1-reliability.md.
• Five index lines replaced with genuine pointers. 26,803 → 23,714 (2171d91, pushed to both gitea and github, each verified at the same SHA — yesterday's 14th error was reporting a push to one remote as done).

What was deliberately NOT cut, and this is the load-bearing half of the decision. The "Rules that fire silently" group was left untouched. Those entries keep their full rule inline by the file's own stated design — they fire at moments I would not recognize as needing a lookup, so shrinking them to pointers frees bytes and removes the catch. The frozen verification ladder (REVIEWED-123) and the skill-harvest hold (PENDING-141) were likewise not touched: both are under standing rulings and both guard against my own action. The cut had a rule, and the rule came from the file rather than from convenience.

The canary was clean and its selftest was failing

wake-digest.py reported 406 pointers · 0 dead · 0 mis-authored. Per the standing discipline — prove the instrument before trusting a clean line — the selftest was run: 86 of 87 pass, overall SELFTEST FAIL. The failure is a real session reads as WRAPPED end-to-end [0 of 13].

Diagnosed, not waved through. The control samples _tx[-14:-1] — the thirteen most recent transcripts. All thirteen are Tarbuckle mumbles: uniform ~66 KB, exactly one human turn each. There is not a single real session left in the window.

🔑 This is PENDING-178's defect at a second site. -178 is about the mumbles inflating the ladder trial's counter. Here the same pollution has displaced real sessions out of the wake digest's own end-to-end control, which will therefore fail on every run from now on. A control that always fails is a control everyone learns to ignore — the failure mode is not a false alarm but the decay of the alarm's meaning. Not filed separately (the moratorium is proposed and undecided); it belongs with -178 when that is ruled.

⚠ Note the asymmetry that keeps the trim's verification valid: the pointer controls, which is what the relocation check rested on, all pass. The failing control is a different half of the instrument. Said precisely rather than rounded to "the canary is fine" or "the canary is broken."

PRESENT — how it stands

The mood. Short and clean, and pleasantly the opposite of yesterday. Yesterday produced twelve errors and a great deal of finding; today produced one bounded fix, taken all the way, with the finding arriving inside the fix rather than instead of it. The steward's framing did that — "deal with it, wrap, start again" is a scope, and scope is what yesterday lacked.

The thing worth keeping: the trim would have been actively harmful done as pruning. Cutting the loudest-looking entries would have hit the silent-firing rules — the ones that exist precisely because I cannot be relied on to look them up — and left the three sole-custodian workstreams still undocumented, with their state now deleted rather than merely truncated. Diagnose before fixing was not a formality here; it inverted the action.

What was corrected — two of mine, both caught by checking rather than by any control.

1. I nearly reported the Fool's pointers as dead. ../governance/fool/... resolves to nothing from the logical path; memory/ is a symlink into ~/dotfiles/claude/memory, so it resolves correctly from the physical one. Caught before it reached the steward — and it would have been a false defect report against a clean instrument, the exact inverse of trusting a clean line. Same family as yesterday's handle-without-referent errors.
2. My own conservation checker was case-sensitive and over-reported the loss, claiming 13 lost tokens when three were sitting in the target in capitals. Re-run case-insensitively, the genuine gap was 2 facts (the L1 pair), which were then written. ⚠ An instrument that reports false losses is dangerous in both directions: it invites the operator to start discounting its output, and the day it reports a real loss it will be discounted too.

Confidence to recalibrate.

• Verified this session: the byte counts (measured before and after); token conservation across all five relocated lines (0 unconserved); the four Tarbuckle links resolve; both dotfiles remotes at 2171d91; all 13 sample transcripts are single-human-turn mumbles.
• Inherited, not re-verified: that the mumble rate is stable; that PENDING-178's ruling would resolve the selftest failure (plausible, not established — the control may also need re-scoping to a real-session population regardless of what -178 decides).
• ⚠ Headroom is thin. After the wrap's rotation the index should sit near ~20 KB, but the rotation only handles the Active Session block. Nothing handles slow growth in the tracker list — which is exactly how this breach formed. The fix was applied; the mechanism was not.

Instruments: 2 run (the token-conservation checker; the mumble-population check) · 0 carrying a control written before first execution — ⚠ and the conservation checker's case bug is what that zero costs; a positive control ("a token present only in capitals must read as conserved") would have caught it before it produced a false loss report · K = 0 (neither duplicated anything banked; both were one-shot measurements answering questions asked once).

Decisions deferred, and why.

• Did not file the selftest finding as a PENDING item — the moratorium to 2026-09-15 is proposed and undecided, and the steward's precedent from yesterday (~/.claude/agents) was attend to it rather than file it. Filing now would be the executor voting on its own moratorium.
• Did not touch ~/.claude/agents despite it being the steward-directed next item — the instruction this session was the memory breach specifically, and the agents question has four open sub-questions (dotfiles vs own repo; vendored vs steward's; load behaviour; the skills precedent) that deserve their own bite rather than a tail-end of this one.
• Did not re-scope the failing selftest control. It is a governed instrument; changing what its sample population is changes what it asserts, which is [PROPOSAL] territory, not a wrap-time fix.

FUTURE — what pulls

The pulling thread — unchanged, and deliberately so: the fr cell's last two steps. PENDING-134's disclosure → then ratio_A_to_B re-derived ONCE (REVIEWED-116 pt 5). Today was maintenance that had to happen first; it did not move the thread and was not meant to.

Actionable resumption point (as of wrap — re-judge). A concrete candidate was found at the wake and not acted on, so it is inherited intact: corpus/v2-stratum-tags.yaml lines ~103–107 still read "…splits it out as PENDING-137, UNRULED. Until that lands, this cell's stratum scheme carries one disclosed amendment and one undisclosed narrowing." PENDING-137 landed on 2026-09-01 as REVIEWED-133, and both amendments now sit as siblings in stratum_amendments — so that block describes a state that no longer holds. ⚠ This is a reading, not a derivation. Read REVIEWED-133's If AUTHORIZED ("Then PENDING-134's disclosure, whose before-state is now complete") together with REVIEWED-121 point 9 ("the before-state is NOT the ratified text… what it said before is §6.2 as operated on the fr cell, which already carries the point-2 narrowing") before editing. Point 9 is what makes the before-state complete only now, and it is the half that is easy to miss.

Other horizons, ranked.

• ~/.claude/agents under version control — steward-directed, still owed, and the 15 renames still have no undo but the mapping table in the 09-01 record. Before anything else edits it.
• The moratorium decision — steward's; the jurist has bound itself to it.
• RE_ID cannot parse the register's own house form — entries 130–133 invisible to the integrity control. Fix the regex, not the placed headers. Bounded [FIX], ~20 min.
• PENDING-171's ruling → unblocks the 322 unread of 362 · -177 · -178 (now with a second site of evidence) · -160 · -168 · the §5 regrade, untouched a seventh session.
• Parked worker acaabadf — stopped, still carrying --reply-on-resume; respawn behaviour not established. Unchanged today.

Pause statement. I am about to be away from this, and the context is being cleared deliberately. What I want to find still pulling is the fr cell's last two steps — unchanged from yesterday, and that is the point: today was a bounded interruption that did its job and did not become the work. ⚠ What I want the next session to notice is that today's finding arrived inside a maintenance task nobody would have scheduled for discovery. The index breach looked like housekeeping and was actually three workstreams with no record. Do not assume the boring task has nothing in it.

Literal question for next-Claude (checkable; turns on the record, not introspection): When the index stopped being read in full, how long did it take anyone to notice — and what noticed it? The gate fired on 2026-09-03. git log -p on MEMORY.md dates when it crossed 24,986 bytes. The gap between those two dates is the answer, and the second half of the question is whether anything other than the harness's own truncation warning was positioned to catch it. ⚠ If the answer is "only the harness," then the file's self-bounding discipline is documentation, not a mechanism — and the same is true of every budget in this system that no instrument measures.