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

name, description, type, originSessionId, permalink

name	description	type	originSessionId	permalink
Session Ledger 2026-05-04	Practice-of-return ledger maintained by /symmetria — returns, open horizons, recalibrations, authorization moves, sub-agent dialogues, bypasses.	feedback	45a40b1e-09cd-42bb-a41a-7298f78a8cf0	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.