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

---
name: session-2026-06-02-afternoon-evening-plane-so-coordination-layer-stood-up-mempalace-recurring-drop-root-cause-found-fixed-1495-cold-start-warmup
description: 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
metadata:
  node_type: memory
  type: project
  originSessionId: 4121cd33-7223-4181-8719-ca764ba5890a
permalink: 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.