Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
4.1 KiB
name, description, metadata
| name | description | metadata | ||||||
|---|---|---|---|---|---|---|---|---|
| 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. |
|
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)
- Backup the palace first —
~/.mempalace/palace-memory(and the typography palace if touched): same-disk copy, verify count. No backup → no upgrade. - Upgrade the installed tool to 3.4.0 (installed via pipx/uv — check
which mempalacefor the carrier; currently 3.3.6). - 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). - Re-test wing-scoped search (
mempalace_searchwithwing:) — expect graceful fallback now, notError finding id. Either way keep the unscoped+post-filter workaround until #1665's root cause closes. - Smoke the session protocol:
mempalace_status, onekg_query, onediary_read, CLIwake-up --wing claude-sessions(ordering check per step 3). - 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 runrepair(#1589, still booby-trapped). - 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:
- 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. - 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. - 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).