Files
dotfiles/claude/memory/project-mempalace-upgrade-3-4-0-plan.md
T
David F GliddenandClaude Opus 5 ef6fa94dcd [FIX] Stamp 16 superseded trackers; harvest the rule one of them carried
The record is updated where information ARRIVES and never where a reader LOOKS.
Three instances found the same day, each with the correct information already
written down elsewhere:

  REVIEWED-81 (AUTHORIZED 07-28)      -> PENDING-81 still reads open
  the ARC open-work register, which   -> those 6 trackers still read live
    says in its own description that
    it supersedes them, with a
    per-file verified verdict
  register entry A2: "the content     -> register entry B3, one page below:
    half (B3) is now unblocked +         "[OPEN - gated on A2]"
    started" (06-17)

The third is the sharpest: both halves sit in the SAME document, so no tooling
gap explains it. ~/CLAUDE.md already rules this under Memory Discipline
("mark the superseded record as superseded"); the rule is being applied to facts
and not to trackers, PENDING items or register entries, which are also facts
about state.

Executed under steward authorization, arrears only:
- 16 trackers stamped `superseded_by:` + `superseded_on:` AND a visible in-body
  banner. The banner is the point — metadata alone repeats the defect, since the
  finding is about what a reader sees. 9 obsoleted by the 2026-07-07 MemPalace
  wind-down; 7 already carrying the register's own verified `DONE-retire`.
- B3's label corrected, with the two-month error left visible rather than
  silently amended.
- Nothing moved, renamed or deleted: 381 pointers resolve, 0 dead, 0 mis-authored.

HARVESTED BEFORE STAMPING, and this is why the harvest came first:
`project-mempalace-library-incremental-remine-strategy` carried a steward-verbatim
rule that is instrument-independent — never run a single multi-day index; order by
criticality; gate each tranche on READBACK, not on write-success (933,576 drawers
once stored successfully and could not be read back at all). It lived only inside
a MemPalace tracker, so retiring the instrument would have retired the rule with
it. ~/CLAUDE.md names that exact hazard: "state the obligation first and the
instrument second, or the next retired tool takes a rule down with it." Now
`feedback-bulk-indexing-runs-incrementally-with-readback.md`, and it applies to
studium-engine corpus work.

Held back deliberately: 2 correctly-parked files with named dependencies, 2 named
nowhere (returned to the steward), and 39 trackers unread — recorded as a gap,
not as a finding.

Measurement note: every earlier estimate of tracker staleness was wrong, because
both mtime and git-last-commit were reset across 283 files by the 2026-06-06
normalization sweep. The honest figure excludes it: median 90 days.

Filed as PENDING-142 ADDENDUM 2 per steward direction (fold, do not file anew).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_013Y6t6qx7cpaCu5xGdD36u4
2026-08-17 15:23:26 +02:00

4.4 KiB
Raw Blame History

name, description, metadata, superseded_by, superseded_on
name description metadata superseded_by superseded_on
project-mempalace-upgrade-3-4-0-plan Scheduled MemPalace 3.3.6 → 3.4.0 upgrade — approach ratified 2026-06-07, execute a few days later once past the heavy ARC work. Backup first; migrate-wings and repair explicitly excluded.
node_type type originSessionId
memory project 5a8200e7-d734-4dc1-b69e-93d77076cab2
project-mempalace-winddown.md 2026-08-17

SUPERSEDED 2026-08-17. A scheduled 3.3.6 → 3.4.0 upgrade of an instrument retired before the slot came.

Current record: project-mempalace-winddown.md. Kept for detail and provenance — do not read the status below as live.

MemPalace upgrade 3.3.6 → 3.4.0 — scheduled plan (ratified 2026-06-07)

Steward directive: execute "in a few days once we've gotten past the heavy work" (the ARC SCSS day 2026-06-08 + whatever follows). Never change the memory substrate the night before — or morning of — a big work day.

Why upgrade: 3.4.0 (92 commits, on PyPI) ships a filtered-search fallback (#1245)

  • MCP stale-index retry (#1635) — converts our most-hit failure (#1665 wing-filter Error finding id) from hard error to graceful degradation — plus diary_write/hook repairs (#1693, #1700: content alias, −32602 diagnostic) that touch the exact machinery our Stop/PreCompact hooks fire.

Why caution: our two filed issues remain OPEN — #1665's root cause (HNSW drifts from sqlite after bulk delete) is unfixed, and #1589 (repair rebuilds an index chromadb SIGSEGVs on) is untouched. Palliatives, not cures. Full read: CM-AI docs/thinking/David/l1-reliability/substrate-failure-lessons-2026-06-07.md §10.

The sequence (one sitting, ~30 min)

  1. Backup the palace first — ~/.mempalace/palace-memory (and the typography palace if touched): same-disk copy, verify count. No backup → no upgrade.
  2. Upgrade the installed tool to 3.4.0 (installed via pipx/uv — check which mempalace for the carrier; currently 3.3.6).
  3. Re-apply / verify the local recency-ordering fix in layers.py — the wake-up CLI's handoffs ordering depends on it; if the upgrade clobbers it, the thread-lineage glance reads oldest-first (wake §2.b.0.5 documents the symptom).
  4. Re-test wing-scoped search (mempalace_search with wing:) — expect graceful fallback now, not Error finding id. Either way keep the unscoped+post-filter workaround until #1665's root cause closes.
  5. Smoke the session protocol: mempalace_status, one kg_query, one diary_read, CLI wake-up --wing claude-sessions (ordering check per step 3).
  6. Do NOT run migrate-wings (wing-name normalization — interesting for our odd wing names but a 61k-drawer migration wants its own considered session, after a verified backup and a read of the migration guide). Do NOT run repair (#1589, still booby-trapped).
  7. Note the outcome in the day's ledger + this file; if the wing filter now degrades gracefully, update feedback-mempalace-wing-filter-broken.

Same slot — our own memory system's maintenance (added 2026-06-07 night)

Three bounded improvements to the files-authoritative layer, ratified in principle, to execute in this same post-heavy-work sitting:

  1. MEMORY.md archive pass — the index is over capacity (531 lines / 267 KB; the harness loads it PARTIALLY every session with a warning). Our own silent-truncation exposure: move Archived-section entries older than ~2 weeks into MEMORY-archive-2026.md (linked from the index), keep the index to current threads + standing preferences. Top-of-file loads first, so the fresh entries are safe meanwhile.
  2. Wake canary (skill-harvest proposal, steward to authorize) — apply lesson 7 to ourselves: a cheap wake/wrap probe — every [[link]] and index pointer in MEMORY.md resolves to a file; flag dead pointers and (optionally) load-bearing orphans. One script, runs in seconds, catches our index drifting from our store.
  3. Palace backup as standing practice — not just before the upgrade: a periodic same-disk copy of ~/.mempalace/palace-memory (launchd or wrap-step), because "restore is the only test of backup" and the palace currently has none.

Standing posture regardless of version: witness, not notary — per the 2026-06-07 CLAUDE.md amendment (conflicts = verification triggers). MemPalace remains the unaffiliated stopgap; BMF is the destined replacement (mempalace-is-unaffiliated-stopgap).