David F GliddenandClaude Opus 4.8
3f9a89b00c
Basic Memory v0.21.6 first sync over the live memory dir (steward-authorized live-dir trial, Option A 2026-06-06): adds permalink: to frontmatter, refolds long YAML description lines, strips final newlines. Bodies untouched — verified via full diff classification. From this commit forward, any diff in claude/memory shows only what Basic Memory or the session writes. Trial design: MemPalace untouched as incumbent; git status check on this dir at every wrap; end-of-day evaluation (recall quality, sync robustness, rebuild-from-files, malformed-file behavior). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
3.4 KiB
name, description, type, originSessionId, permalink
| name | description | type | originSessionId | permalink |
|---|---|---|---|---|
| Drift pattern — had-the-warning-in-context-and-still-launched-the-thing-it-warned-against | When MEMORY.md contains a specific safety warning about an action and I take the action anyway. Steward caught it 2026-05-13 before harm landed. Pattern recurs because warnings get read at index level and not actively applied to the next decision. | feedback | a5411fd1-4a96-43e7-aa1a-1a50d8951a8f | claude-memory/feedback-warning-in-context-still-launched |
Rule: When MEMORY.md or a recent memory file flags a specific safety constraint, that constraint must be actively checked against the next action that could trip it. Reading the warning at session-start is not the same as applying it.
Why: On 2026-05-13 the steward caught me launching a Python probe against the mempalace MCP handlers while the chamber-library mine was still running. MEMORY.md's 2026-05-11 entry explicitly flagged that PR #442's branch lacks the concurrent-writer lock fix #1162, and the literal Q I had left for next-Claude was "Will PR #442's branch — lacking 3.3.5's concurrent-writer lock fix — hold up on a 700k-drawer mine without HNSW corruption mid-run?" That warning was in my context the whole session. The probe was killed in time, no harm landed — but only because the steward intervened.
The 2026-05-03 broken-mine session is the empirical case for what concurrent-write contention does to a PR #442 palace: 933,576 drawers stored, search returning instant "Error finding id," three days of CPU lost.
How to apply:
- Before any action that touches a live system (database query, MCP call, mine-adjacent operation), explicitly ask: is there a memory entry warning against this in the current state?
- Treat the open question (the literal Q for next-Claude in the previous wrap) as an active constraint, not a curiosity. If the Q is "will X corrupt under Y," then doing X during Y requires explicit authorization.
- Reading-the-warning-at-wake-up is necessary but not sufficient. The application moment is the moment of action, not the moment of reading.
- When a probe or test feels obviously safe ("just a read"), check the lock model. PR #442 branch lacks the per-collection lock that 3.3.5 adds; concurrent reads can still trip HNSW segment loads that fail catastrophically.
Wake-up procedure is a known trigger. Recurred 2026-05-14: launched mempalace_status + _diary_read + _kg_query as part of the /wake-up MemPalace-query step despite MEMORY.md's explicit note that the mine was active and hooks were DISABLED for safety. The wake-up skill instructs MemPalace querying as procedure; the active mine is an exception that overrides the procedure. The /wake-up MemPalace step is conditional on the substrate being available — when it isn't, skip the MemPalace block and note the skip in the briefing. Do not call mempalace tools during an active mine, even read-only ones, until the steward confirms the mine has completed and hooks have been restored.
Related drift patterns:
- Cosine-as-only-tool when the toolset is multi-modal (same session, separate shape — using
searchwhile CLAUDE.md explicitly says use the full toolset of search/kg_query/find_tunnels/traverse/diary_read) - Structural-counter-as-health-signal (2026-05-05, parent shape — letting an indirect signal stand in for direct verification)
- Stale-memory-not-actively-applied (2026-05-09, recurring shape — memory present but inert during decision)