dotfiles/claude/memory/session-2026-06-02-plane-setup-mempalace-coldstart-fix.md

name, description, metadata, permalink

name	description	metadata	permalink
session-2026-06-02-afternoon-evening-plane-so-coordination-layer-stood-up-mempalace-recurring-drop-root-cause-found-fixed-1495-cold-start-warmup	CapableMind housekeeping pivot. Built the Plane↔GH effort-tracking bridge (BMF project, 5 thin tasks, GH-mirrored labels) and diagnosed+fixed the weeks-old MemPalace silent-drop (upstream	node_type type originSessionId memory project 4121cd33-7223-4181-8719-ca764ba5890a	claude-memory/session-2026-06-02-plane-setup-mempalace-coldstart-fix

Session 2026-06-02 (afternoon/evening) — Plane setup + MemPalace cold-start fix

Re-wake same day (~3h after the ARC craft-morning wrap). Steward pivoted: "CapableMind housekeeping." Two arcs, both shipped to completion; one needs activation+verification next session.

Past — what we did

Arc 1 — Plane.so coordination layer (Seb's request: make the 6-hour gap a boon, not a bottleneck)

• Added the official Plane MCP server — claude mcp add --transport http --scope user plane https://mcp.plane.so/http/mcp. OAuth, user-scoped, no secret stored. (Reserved Seb's PAT for future automation — OAuth is cleaner for interactive use; Plane's own recommendation.) Connected after steward did /mcp browser auth + a Claude Code restart (mid-session MCP adds need a relaunch to appear).
• Coordination model (Seb's, the load-bearing distinction): GH issues = canonical/technical; Plane task = thin effort overlay — [BM #N] title tag, ONE effort/coordination line (no technical detail), GH issue attached as link, priority+labels mirror GH. Coupled-but-separated → no parallel-source-of-truth drift (honours CLAUDE.md "one canonical source per concern"). This dissolved my whole "canonical-role" question.
• Home project = BMF (Better Memories Framework, for betterMemories_app issues). BBF = BetterBridge is a different beast — an agent control-plane/observability product (Shopify embedded app), downstream of L1 (consumes BMF health/recall); spec docs/specs/bbf/core/betterbridge-spec.md. I misread BBF as the coordination board; steward corrected → I read the repo to ground it.
• Cleared the 7 Plane demo tutorial cards (kept BMF project — it's our home; MCP exposes no archive-project tool). Seeded 5 thin tasks grow-as-we-go: #165 (urgent, bug+priority:critical), #167 (high, bug+priority:high), #170 (tracking), #168 (documentation), #171 (bug+tracking). Each: effort-line + GH link + mirrored priority/labels.
• Created 5 Plane labels mirroring GH colours (bug #d73a4a, documentation #0075ca, priority:critical #b60205, priority:high #d93f0b, tracking #ededed).
• Recorded Plane as NOW-CENTRAL to the steward↔Seb workflow: reference-plane-coordination-workflow.md + MEMORY.md Standing-preferences pointer.
• Steward decisions: effort-description shape + assignees → "wait and see a few days, revisit." Labels → mirror GH. Grow-as-we-go (not full 35-issue backfill).
• Tool gotcha caught: create_work_item silently ignores description_stripped — needs description_html. Fixed via update; verified persisted.

Arc 2 — MemPalace recurring silent-drop: ROOT CAUSE FOUND + FIXED (was "root cause unknown" for weeks)

• Steward's hypothesis (re-enable the every-15 auto-write to keep MCP from going idle) disproven both ways: (a) auto-write was never actually disabled — ~/.mempalace/config.json has no hooks key → defaults auto_save=true, and the hook log shows it firing today; (b) it's a separate process (mempalace mine &) that never touches the MCP server's idle timer — can't keep the connection warm.
• Real cause = upstream MemPalace/mempalace #1495: first chromadb-write after a fresh mempalace-mcp boot must cold-load the embedder (5–30s); that exceeds Claude Code's MCP client timeout → -32000 desync, stderr uncaptured → no trace (why the logs end clean with no death). diary_write AT WRAP is the classic first-write — exactly the steward's "red MCP error before I invoked wrap-up." Restart just re-arms the trap → recurs.
• Fix cf96e68 (merged #1530) is already in the steward's tree (branch local/bge-m3-on-3.3.6, 0 behind origin/main) but opt-in.
• Steward flagged the non-standard engine (bge-m3 pinned on MPS, not the standard CoreML/ONNX #1495 describes). VERIFIED the warmup is embedder-agnostic: _maybe_eager_warmup_embedder() (mcp_server.py:2656, called from main() L2845) fires a throwaway probe through the configured EF → embedding.py:259-279 wires bge-m3 → SentenceTransformerEmbeddingFunction(device="mps"). So warmup WILL load bge-m3/MPS at boot. bge-m3 already cached (~/.cache/huggingface/hub/models--BAAI--bge-m3) → no 2.2GB download.
• Note: the bge-m3/MPS dispatch is a LOCAL patch (embedding.py:22-23) re-applied after each upstream merge — fragile; re-apply + re-confirm warmup on any future mempalace update.
• FIX APPLIED in ~/.claude/settings.json env: MEMPALACE_EAGER_WARMUP=1 + MEMPALACE_LOG_FILE=/Users/davidglidden/.mempalace/mcp.log (capture future traces) + MEMPALACE_MCP_IDLE_HOURS=0 (idle-exit insurance). Requires Claude Code restart to activate (env applies at MCP subprocess launch). Startup will be a few seconds slower (bge-m3→MPS load moved to boot — the point). Dropped #2 (raise MCP timeout) — warmup makes it moot.
• Defense-in-depth (steward-authorized): patched /wrap-up SKILL.md §4.0 — liveness-ping MemPalace (lightweight hook_settings, NOT slow status) before the diary write; if down, surface loudly and let the file/ledger deposit carry the wrap. A drop can never silently eat a wrap again. (Provenance note added per skill convention.)

Present — mood / returns

• Steward corrected me twice, both caught real errors before I over-committed: (1) BBF≠coordination board (I'd assumed from name+timing) → read the repo; (2) "our embedding engine is not the standard" → I'd been about to present the #1495 fix as clean without checking it warms bge-m3/MPS. Both are the verify-before-assert / render-and-LOOK through-line that recurs across recent sessions. Good catches, gracefully taken.
• Time-discipline held: steward flagged "we've lost more than a week already — don't lose a lot of time on this." I bounded the MemPalace diagnosis, and the upstream-issue check (#4) turned out to BE the win (#1495 named our exact bug). Lean beat thorough here because the answer was already written down upstream.
• render-and-LOOK wins: caught the description_stripped silent-drop by reading the returned objects; verified the warmup call-site + EF wiring + model cache rather than asserting.

Future

• Pulling thread: the MemPalace cold-start fix is applied but UNVERIFIED. It only activates on a Claude Code restart, and the proof is a clean next-session wrap with no -32000. Until then it's a hypothesis with strong evidence, not a confirmed fix.
• Actionable resumption point (as of wrap — re-judge against what changed): ~/.claude/settings.json env is set; restart pending. First move next session: at wake, check ~/.mempalace/mcp.log exists + shows the warmup probe at boot, and that mempalace_status/first diary_write is fast (warm). If yes → fix confirmed, close the recurring item. If it still drops → the warmup didn't take for bge-m3/MPS; escalate (move the env onto the mempalace MCP server's own env in ~/.claude.json, and/or confirm the probe actually exercises the configured EF on this branch).
• Open horizons (ranked):
  • Load-bearing: verify the MemPalace fix (above).
  • Live, low-effort: maintain the Plane board as we work (update task state as issues move — the relay). Steward revisits effort-description shape + assignees in a few days.
  • Housekeeping remainder surfaced at wake, NOT done this session: 8 untracked CapableMind-AI files (deferred review since 2026-05-18); PENDING.md at 768 lines (archive CLOSED OP-/S-/CD- items); BMF runtime parked pending Seb's N6; L1 tracker current-state stale (2026-05-28); Seb gate-question (did his D1–D10 move the four Hindsight findings) — checkable now that he's back-ish.
  • Parked: L2 (through end of May — now past; not re-opened this session).

Pause statement

I'm about to be away from this. The MemPalace fix is applied but won't have been exercised until the restart + a real next-session MemPalace write. I want to find, on return, either confirmation it held (mcp.log shows warmup, no drop) or a clean signal it didn't (so we escalate the env placement) — not a silent re-arming of the same trap.

Decisions deferred (and why)

• #2 (raise MCP tool timeout): dropped, not deferred — warmup amortizes the cold-load to startup, so the timeout never trips; raising it would treat a symptom the root fix removes.
• Effort-description shape + Plane assignees: steward chose "wait and see a few days" — don't tune the thin-task format or assign tasks until the board's been lived with.
• The rest of the housekeeping list (untracked files, PENDING bloat, BMF restart, L1 tracker refresh, Seb gate-question): not touched — Plane + MemPalace consumed the session; they remain open for the next housekeeping pass.
• Did NOT restart Claude Code mid-wrap to activate the fix — chose to wrap first so the deposit is safe, then the steward restarts.

Literal question for next-Claude

After the restart: did the warmup actually prevent the cold-start drop — does ~/.mempalace/mcp.log show the warmup probe at boot, and did the first diary_write/search succeed without -32000? If it still drops, the env didn't reach the bge-m3/MPS path and we escalate.