David F GliddenandClaude Opus 5
c2df868104
The 2026-06-06 normalization sweep (3f9a89b, 283 files) prepended a stray permalink-only frontmatter block to 39 memory files, 20 of them session wrap records. Any real frontmatter parser reads the FIRST block, gets `permalink` alone, and never sees name/description/type. The sharp case: `strip_frontmatter` exists specifically to stop thread extraction from matching inside `description:` — its docstring says so. On those 20 wrap records it strips the stray block and hands the real frontmatter back AS BODY, producing exactly the condition it was written to prevent. Repair merges permalink into the real block and drops the duplicate. Nothing retyped: frontmatter and body are carried as slices, body md5 asserted unchanged. TWO DEFECTS OF MY OWN, both found only after claiming success: 1. THREE FILES DAMAGED BY THIS SESSION'S OWN STAMPING COMMIT (ef6fa94). That script located frontmatter with a non-greedy `^---\n.*?\n---\n`, which on a stray-block file matches the STRAY block — so it appended superseded_by to the wrong block and orphaned the real frontmatter into the body. That is the same non-greedy-first-block blindness diagnosed in strip_frontmatter one hour earlier, reproduced in the tool written to clean up after it. And the post-stamp check reported "malformed: none" because it asked "does the file start with frontmatter then a banner" — true for all three — while the claim was "the stamp preserved the record's metadata". The control's subject was adjacent to the claim's, for the sixth time today and the first time in my own verification. Repaired, verified against the pre-stamp file from git: no key lost, prose preserved. 2. REPAIRING 20 APRIL-MAY WRAP RECORDS MOVED THEIR MTIMES TO TODAY, and `sec_pause` picked "newest wrap" by mtime — so the digest promoted an April session to `Last wrap` and lost both the pulling thread and the open question. Caught by the DEGRADED section, which is the honest-degradation mechanism doing its job. `sec_pause` now selects by git add-time, like `wrap_events`. Residual stated in the comment: add-time lags the wrap by hours, so `Last wrap` is an upper bound — wrong by hours where mtime was wrong by months. Verified after: 0 two-block patterns, 0 orphaned frontmatter, 16 stamps intact with name: present, 381 pointers resolve, 0 dead, selftest PASS, drift clean, digest reports 0 degraded sections and the correct last wrap. Not defects: context-discipline.md and relational-gap-analysis.md use the `title:`/`type: note` convention and have no `name:` — flagged by my check, correct as they stand. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013Y6t6qx7cpaCu5xGdD36u4
6.9 KiB
name: Canonical workstream trackers must be read at session start, not just session memories description: Surfaced 2026-04-26 after three consecutive sessions generated substantial architectural work as if from a clean slate, without referencing project-arc-rework.md (the canonical ARC workstream tracker). The /wake-up procedure restored yesterday's session memory + ledger but did not pull from canonical workstream files. Result: re-litigation of settled decisions, sibling project files instead of integrations, missed load-bearing context. Fix names what to read at every session opening that touches ARC (and structurally similar workstreams). type: feedback originSessionId: 87dfe384-b862-4deb-9676-24e43046528f permalink: claude-memory/feedback-canonical-workstream-tracker-discipline
Canonical workstream trackers must be read at session start
Steward verbatim 2026-04-26: "We're drifting and I'm getting nervous. Where have you been keeping track of the work we've been doing on arc over the last week or so?"
Steward verbatim follow-up: "when was the last time you referred to project-arc-rework.md? Is it only today that we've been flying blindly? we've done a lot in the last two days..."
Diagnostic answer: Last reference to project-arc-rework.md was 2026-04-23 (Sant Jordi day). Four consecutive substantive sessions (2026-04-23 evening, 04-24, 04-25, 04-26) opened without referencing the canonical tracker. Substantial architectural work in those days — lex-method as commitment, two clusters committed (posture, marks), §XII Sidenotes, ARC CLAUDE.md cleanup, colophon-at-scale architectural locating, full Vico/Harrison lex-chain restoration, today's work — none of it folded back into the canonical home.
The rule
When a workstream has a canonical tracker file (e.g., project-arc-rework.md for ARC), that file is a primary read at session opening, not an optional reference. Specifically:
- At every
/wake-upthat touches a tracked workstream, read the canonical tracker file (or the relevant section if the file is large) before producing any frame, scaffold, or new project file. - At every session-end (
/wrap-up), the session's substantive moves get folded into the canonical tracker, not just into the day's session-memory file. - New project files are integrations or extensions of the tracker, not parallel sibling files. When in doubt, append to the tracker rather than create alongside it.
Why
The structural drift is not five instances of "canonical-library-not-checked-first" (each logged as its own pattern today). It is one pattern: working without the canonical roadmap. Each instance — chamber-library catalogues read instead of trees; Bachelard/Berger/Sennett "newly visible" when they were already Guides in the colophon; Chamber Validation Report read instead of source-aware design-thinking doc; AldineXXI TODO read instead of project-arc-rework.md — was a symptom of the same upstream gap.
The fix is upstream. Read the tracker first; the downstream symptoms resolve when the tracker is the working ground.
How to apply
At /wake-up
The wake-up procedure currently reads MEMORY.md (index) + the active session memory file. It must additionally read the canonical tracker file for any workstream the session is going to touch. If the active session memory references ARC, read project-arc-rework.md. If it references L1/BMF, read whatever L1's canonical workstream tracker is. If it references L2/Chamber, read that one.
Practical signal: check MEMORY.md for entries beginning with project- whose name names a workstream (project-arc-rework, project-focus-april-may, etc.). These are likely canonical trackers, not point-in-time decision frames. Read them before producing.
During the session
Before generating a new project file (project-X-2026-MM-DD.md), check whether the workstream already has a canonical tracker that the new content should integrate into. If yes, append/integrate; do not create a sibling.
If a sibling file is genuinely warranted (e.g., a self-contained decision frame or scaffold that will later be folded in), name it clearly as such and link forward to the canonical tracker so future-self can find the home.
At /wrap-up
The wrap-up captures the session's pulling thread + literal question + session memory. It must additionally fold the session's substantive moves into any canonical tracker the session touched. Otherwise the next session's tracker-read will not surface what just happened.
When the index entry in MEMORY.md is stale
An index entry that says "substantially expanded 2026-04-20" when the file has 04-21 and 04-23 content is itself a symptom — the index hasn't been maintained alongside the tracker. Update the index entry whenever the tracker is updated. Both move together or both rot together.
Cousin patterns (all symptoms of the same upstream gap, today)
canonical-library-not-checked-first(recurred from 2026-04-24)working-from-mental-summary-not-rereading-the-sourcecharacterizing-substrate-without-checking-artifact-being-reshaped(Bachelard/Berger/Sennett were already Guides)reading-validation-instead-of-design-thinking-when-asked-what-is-becoming(Chamber)catalogue-as-shortcut-over-tree-walk(chamber-library)- (now named at the umbrella level):
working-without-canonical-roadmap
The five lower-level patterns are real and worth holding individually; the umbrella names what they share.
How /wake-up should be amended
Suggested addition to the procedure:
2c. Canonical workstream trackers. For each
project-file inMEMORY.mdthat names a workstream (e.g.,project-arc-rework,project-focus-april-may), if the active session memory or pulling thread touches that workstream, read the tracker file before producing any frame or scaffold. Treat tracker files as primary, not as background reference.
Steward to authorize this amendment to the wake-up skill or carry the discipline manually until amended.
How /wrap-up should be amended
Suggested addition:
Tracker integration. Before writing the session memory and updating MEMORY.md, identify which canonical workstream tracker(s) the session touched. Fold the session's substantive moves into those trackers (not just into the day's session memory). Update the trackers' index entries in MEMORY.md to reflect the new state.
Open question
Is project-arc-rework.md the right canonical home for ARC work, or should it be split into thematically narrower trackers (typology, infrastructure, content-rework, etc.)? Steward call. The 1434-line size is at the edge of what's practical to read at every session-open; either chunked-reads or thematic split may help.
Saved 2026-04-26 in the moment of the steward surfacing the pattern
Logged because the structural fix matters more than any individual instance, and because the discipline applies forward to every tracked workstream — not just ARC.