dotfiles/claude/memory/session-ledger-2026-05-04.md

---
name: Session Ledger 2026-05-04
description: Practice-of-return ledger maintained by /symmetria — returns, open horizons,
  recalibrations, authorization moves, sub-agent dialogues, bypasses.
type: feedback
originSessionId: 45a40b1e-09cd-42bb-a41a-7298f78a8cf0
permalink: claude-memory/session-ledger-2026-05-04
---

# Session Ledger — 2026-05-04

## Returns

- 17:5x — Steward asked "could we have done something wrong [during the update]?" Answered honestly: yes, plausibly. The 2026-04-29 update was 3.0.0→3.3.3 + chromadb 0.6.3→1.5.8 (major-version jump on chromadb). MemPalace ships a `migrate` subcommand specifically for ChromaDB version upgrades. Need to verify whether migrate was run before the bge-m3 mine wrote 933k drawers on top of the upgraded backend. Not deflecting into action without checking this first.

## Open horizons

- Diagnose Python/Chroma crash: was `mempalace migrate` run on 2026-04-29? If not, that may be the root cause of the segfault, the search "Error finding id" yesterday, and the MCP crashes today.
- Decision pending: `mempalace migrate` (if applicable) → then `mempalace repair` (rebuild vector index from stored data) → vs. revert to `palace.pre-bge-m3-2026-04-30` as fallback.
- Spec §XII.d revision (paragraph-with-sidenote font-style) — small mechanical follow-up; deferred while mempalace is the active thread.

## Confidence to recalibrate

- "Mempalace just needs `repair`" — too quick. The crash inside Chroma's Rust bindings on `count()` is more fundamental than an index issue. Migration may be the upstream condition.

## Authorization moves

- 17:5x — Plan: backup + migrate `palace.pre-bge-m3-2026-04-30/` first; restore baseline before tackling broken big palace. **Steward authorized.**
- 18:0x — Surprise from dry-run: pre-bge-m3 palace already readable by chromadb 1.5.8; 131,418 drawers; no migration needed. Revises diagnosis: the chromadb upgrade alone didn't break things — something specific to the bge-m3 mine wrote unreadable data into the big palace.
- 18:0x — Plan: swap palaces (rename current `palace/` → `palace.bge-m3-broken-2026-05-04/`, rename `palace.pre-bge-m3-2026-04-30/` → `palace/`). **Steward authorized "if we have a backup in place." Backup confirmed at `palace.pre-bge-m3-2026-04-30.backup-2026-05-04/`. Executed.**
- 18:1x — After swap: status works (131,418 drawers); search fails on dimension mismatch (collection 384d, embedding 1024d) — bge-m3 patch in `chroma.py` is forcing global 1024d. Diagnosed live, not as a surprise.
- 18:1x — Path A authorized: revert chroma.py patch to restore mxbai/384d globally. Patch saved at `~/_Dev/mempalace/.local-data/bge-m3-patch-2026-04-30.diff` for future per-collection refactor. **Executed.**
- 18:1x — Steward set durable rule for library re-mining: incremental, prioritized by criticality, "I'm not losing days to this again." Saved as `project-mempalace-library-incremental-remine-strategy.md`.

- 18:3x — Diagnosed live: HNSW segment writer error under 3.3.4 (different from yesterday's "Error finding id"). Steward's instinct: "are we really on the latest build?" — caught me about to propose a complex multi-hour recovery before checking upstream. **Saved hours.** Drift pattern returned: *almost-deferred-to-complex-recovery-without-checking-upstream-first.*
- 19:0x — Confirmed: 3.3.4 (released 2026-04-30, day after steward's pull) ships fixes for our exact symptoms (#1191 HNSW bloat, #1135 max-seq-id, #1287 divergence floor, #1262/#1289 SIGSEGV). 4 days on broken software unknowingly. **Steward authorized full upgrade.**
- 19:1x — Migrate dry-run on broken palace under 3.3.4 confirmed extraction path works. But honest correction surfaced: migrate extracts text only, NOT embeddings. The "save 3 days" framing partially wrong — re-embed always required.
- 19:3x — Path A (upstream default mxbai 384d, no patch) authorized after steward weighed quality vs risk. BM25 carries multilingual verbatim recall for chamber-library use case; PR #442 still has merge conflicts and isn't merged. Reverted bge-m3 patch.
- 19:4x — Steward asked about update completeness — caught the upgrade gap pattern. Surfaced PR #442/#912/#1261 as the architecturally correct path (configurable embedding model) — **OPEN with merge conflicts**, not in 3.3.4. Wait-for-upstream rather than continue patching.
- 20:0x — Roadmap audit: v3.3.5 (May 8, four days out) is a storage-stability sprint with 52 open issues, including #1266 ("HNSW pickle corruption after long-running mine: repair/migrate cannot recover") — **OUR SCENARIO VERBATIM**. If #1266 ships in 3.3.5, chamber-library bge-m3 recovery may preserve embeddings.
- 20:3x — **Strategic pivot authorized:** mine ARC superpower slate now (typography, style, philosophy, Loeb canon — all already converted). Park chamber-library 933k for v3.3.5. Incremental, validated, no multi-day passes. Steward: *"I'm not losing days to this again."*
- 21:0x — Library walk surfaced gap: rhetorical canon. Loeb DSL (533 MB, 537 vols) on Desktop has it ALL (Aristotle Rhetoric+Poetics, Cicero De Oratore+Orator+Brutus, Quintilian, Longinus, Demosthenes, Plato Phaedrus+Gorgias). Steward: *"Everything Loeb in the chamber library came from this file."* Confirmed — 89 files already extracted June 2025. Just needs DSL markup strip.
- 21:2x — Steward triage of "superpower mine" Desktop folder: 10 PDFs matching exactly the load-bearing gaps (Hochuli, Müller-Brockmann, Smeijers, Morison, Rutter, Alexander Timeless+Oregon, Bachelard Fire+Air+Reverie). **They had triaged this independently.** Pleasing convergence.
- 22:0x — Better-tools authorized: install Marker (ML-based PDF→md), uninstall ocrmypdf+unpaper. Marker test kicked off (slow first-run model download, still going at session end).
- 22:1x — Restored Stop hook to settings.json; updated wake-up skill (full toolset + upgrade check section); steward applied CLAUDE.md mempalace primacy section.
- 22:3x — Loeb markup strip ran cleanly: 88 files, 280 MB output. Phase_1 files reduced 13-29% (Aristotle 27 MB → 17.7 MB).
- 23:0x — Wrote 470-line L1 lessons doc at `lessons-from-mempalace-upgrade-2026-05-04.md`. Twelve durable patterns: health-vs-function, storage-vs-recall, silent-format-corruption, recovery-paths-must-precede-failures, upgrade hygiene, verbatim primacy, dimension pinning, protocol-as-discipline, hooks for continuity, concurrent-writer discipline.
- 23:0x — Cleaned 4 Ollama models (cm-david:v2 + 3 cm-keystone-ranking variants), 16.6 GB freed. gemma4:e4b held pending steward triage.
- 23:0x — Kicked off unsupervised ARC chamber mine (PID 10737). 6 sequential targets into wing chamber_library.
- 23:0x — Steward sleep plan; manual mempalace_diary_write completed before sleep (Stop hook won't fire this session, fires next).

## Sub-agent dialogues

## Bypasses

## Drift patterns to save (kg_add at wrap)

1. **almost-deferred-to-complex-recovery-without-checking-upstream-first** — was about to propose a multi-step recovery for HNSW corruption before checking if upstream had shipped a fix. Steward asked "are we really on the latest build?" → 3.3.4 had been released the day after the previous pull, with fixes for our exact symptoms. Saved hours of unnecessary work. This is a sibling/cousin of the existing **blame-the-exotic-before-checking-the-boring** pattern (April 28 ledger) — different domain, same shape: when symptoms match common patterns, check the boring/upstream/standard before designing exotic recovery.

2. **structural-counter-as-health-signal-without-functional-validation** — trusted mempalace_status's "933,576 drawers" as a health signal until forced to recognize that drawer count is structural, not functional. Search was completely broken. The migrate dry-run named it directly: "Palace is NOT readable by chromadb 1.5.8." Storage exists; storage isn't memory. This is the contamination problem at infrastructure level — the system reports "ready" via its own counters that don't reflect what users experience. New pattern; sibling of (but distinct from) defended-the-spec-against-the-eye.