David F GliddenandClaude Opus 5
c2df868104
The 2026-06-06 normalization sweep (3f9a89b, 283 files) prepended a stray permalink-only frontmatter block to 39 memory files, 20 of them session wrap records. Any real frontmatter parser reads the FIRST block, gets `permalink` alone, and never sees name/description/type. The sharp case: `strip_frontmatter` exists specifically to stop thread extraction from matching inside `description:` — its docstring says so. On those 20 wrap records it strips the stray block and hands the real frontmatter back AS BODY, producing exactly the condition it was written to prevent. Repair merges permalink into the real block and drops the duplicate. Nothing retyped: frontmatter and body are carried as slices, body md5 asserted unchanged. TWO DEFECTS OF MY OWN, both found only after claiming success: 1. THREE FILES DAMAGED BY THIS SESSION'S OWN STAMPING COMMIT (ef6fa94). That script located frontmatter with a non-greedy `^---\n.*?\n---\n`, which on a stray-block file matches the STRAY block — so it appended superseded_by to the wrong block and orphaned the real frontmatter into the body. That is the same non-greedy-first-block blindness diagnosed in strip_frontmatter one hour earlier, reproduced in the tool written to clean up after it. And the post-stamp check reported "malformed: none" because it asked "does the file start with frontmatter then a banner" — true for all three — while the claim was "the stamp preserved the record's metadata". The control's subject was adjacent to the claim's, for the sixth time today and the first time in my own verification. Repaired, verified against the pre-stamp file from git: no key lost, prose preserved. 2. REPAIRING 20 APRIL-MAY WRAP RECORDS MOVED THEIR MTIMES TO TODAY, and `sec_pause` picked "newest wrap" by mtime — so the digest promoted an April session to `Last wrap` and lost both the pulling thread and the open question. Caught by the DEGRADED section, which is the honest-degradation mechanism doing its job. `sec_pause` now selects by git add-time, like `wrap_events`. Residual stated in the comment: add-time lags the wrap by hours, so `Last wrap` is an upper bound — wrong by hours where mtime was wrong by months. Verified after: 0 two-block patterns, 0 orphaned frontmatter, 16 stamps intact with name: present, 381 pointers resolve, 0 dead, selftest PASS, drift clean, digest reports 0 degraded sections and the correct last wrap. Not defects: context-discipline.md and relational-gap-analysis.md use the `title:`/`type: note` convention and have no `name:` — flagged by my check, correct as they stand. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_013Y6t6qx7cpaCu5xGdD36u4
76 lines
6.1 KiB
Markdown
76 lines
6.1 KiB
Markdown
---
|
||
name: MemPalace protocol step 2 — query-before-responding mid-session is the discipline (not just at wake-up)
|
||
description: Surfaced 2026-04-26 evening end-of-session. MemPalace had the content that would have prevented today's structural drift; the failure was retrieval discipline, not storage. Protocol step 2 ("BEFORE RESPONDING about any person, project, or past event: call kg_query or search FIRST") is rarely honored mid-session. Discipline parallel to canonical-workstream-tracker — same shape (write to substrate, fail to read before producing), different temporal scale (mid-session, not just at boundaries).
|
||
type: feedback
|
||
originSessionId: 87dfe384-b862-4deb-9676-24e43046528f
|
||
permalink: claude-memory/feedback-mempalace-protocol-step-2-discipline
|
||
---
|
||
# MemPalace protocol step 2 — query-before-responding is the discipline
|
||
|
||
**Steward verbatim 2026-04-26 evening:** *"I want to revisit it expressedly to be sure that we are using it to it's fullest. It should help us to keep much more in track, no? Or is that only wishful thinking?"*
|
||
|
||
**Honest answer surfaced:** not wishful thinking — there is real leverage in MemPalace, but the leverage depends on protocol discipline. MemPalace already had the content today that would have prevented the structural drift. The failure was retrieval, not storage.
|
||
|
||
## The protocol — step 2 specifically
|
||
|
||
From `mempalace_status` (auto-displayed at wake-up):
|
||
|
||
> **2. BEFORE RESPONDING about any person, project, or past event:** call `mempalace_kg_query` or `mempalace_search` FIRST. Never guess — verify.
|
||
|
||
This step is the load-bearing one mid-session. Step 1 (wake-up status load) and step 4 (end-of-session diary write) are bracketing rituals; step 2 is what makes MemPalace operate as memory rather than as storage.
|
||
|
||
## What today proved
|
||
|
||
Multiple drift patterns surfaced today were preventable by step-2 queries I didn't make:
|
||
|
||
| Drift pattern | Query that would have prevented it |
|
||
|---|---|
|
||
| TODO-ALDINEXXI.md as workstream tracker | `mempalace_search "ARC roadmap"` or `kg_query "ARC"` would have surfaced project-arc-rework.md |
|
||
| Chamber rewrite frame from validation report only | `mempalace_search "chamber from simulation source-aware"` would have surfaced the design-thinking doc |
|
||
| Bachelard/Berger/Sennett as "newly visible pillars" | `mempalace_search "colophon Guides ARC"` would have surfaced their already-Guide status |
|
||
| Cluster scaffolds replaying yesterday's already-recognized voices | `kg_query "ARC"` would have surfaced what was already-Guide vs newly-noticed |
|
||
|
||
Estimated coverage: a mid-session step-2 discipline would catch **~70–80%** of the drift patterns that surfaced today. Combined with the canonical-tracker discipline (`feedback-canonical-workstream-tracker-discipline.md`), the structural drifts of this session would mostly be prevented.
|
||
|
||
## The rule
|
||
|
||
**Before producing a new project file, frame, decision-frame, scaffold, or rewrite of any artifact:**
|
||
|
||
1. Identify what subjects/projects/events the new work touches
|
||
2. Run `mempalace_kg_query` on the subjects (e.g., `entity: "ARC"`, `entity: "claude-code"`, `entity: "chamber"`)
|
||
3. Run `mempalace_search` on the topic phrases that would surface related prior work
|
||
4. **Only then produce.** The queries take 5–10 seconds; the drift cost they prevent is hours.
|
||
|
||
## How to apply
|
||
|
||
- **Triggering events:** writing a new `project-*.md` file, drafting a decision frame in chat, characterizing voices/sources/people, naming a new pattern, proposing a fix or refactor, summarizing what's already known
|
||
- **Default queries to keep in mind:**
|
||
- `kg_query` on the primary subject(s) — surface drift patterns, preferences, watches-horizons, decisions
|
||
- `search` on the topic phrase(s) — surface session memories, drawer entries, vault content
|
||
- **Cost:** 5–10 seconds per query, ~3 queries per substantive draft = 30 seconds before producing
|
||
- **Benefit:** ~70–80% drift prevention based on today's evidence
|
||
|
||
## Cousin to canonical-workstream-tracker discipline
|
||
|
||
The two disciplines share the same upstream pattern: **write to substrate, fail to read before producing.** They differ in temporal scale:
|
||
|
||
- **Canonical-workstream-tracker discipline** (`feedback-canonical-workstream-tracker-discipline.md`) — applies at session boundaries (`/wake-up` reads tracker; `/wrap-up` folds session into tracker)
|
||
- **MemPalace step-2 discipline** (this file) — applies mid-session, before each substantive production
|
||
|
||
Both are needed. The tracker discipline catches drift at session boundaries; the MemPalace discipline catches drift inside the session. Together they cover the full work cycle.
|
||
|
||
## Proposed `/wake-up` and `/wrap-up` amendments
|
||
|
||
`/wake-up` amendment proposed in `feedback-canonical-workstream-tracker-discipline.md` already covers reading canonical trackers at session-open. A complementary amendment for MemPalace:
|
||
|
||
> **2c. MemPalace protocol step 2 reminder.** After wake-up's tracker reads, surface to the executor that mid-session step 2 (`query-before-responding`) is the discipline. Specifically: before writing any new `project-*.md` file or producing a substantive frame in chat, run `mempalace_kg_query` on the primary subjects + `mempalace_search` on the topic phrases.
|
||
|
||
`/wrap-up` already calls `mempalace_diary_write` and `mempalace_kg_add` for changed facts (step 4 + step 5 of the protocol). That's operative. The mid-session gap is what this discipline addresses.
|
||
|
||
## Update prerequisite
|
||
|
||
Local MemPalace is **502 commits behind upstream** as of 2026-04-26 (per origin/main fetch). Six tags landed: v3.1.0 → v3.3.3. v4 in preparation (`release/v4-prep` branch). Update wants its own focused session before relying on the discipline at full leverage — recent themes include init entity-detection overhaul, project-scanner entity detection, security/path normalization, LLM refinement tightening (relevant for retrieval quality).
|
||
|
||
## Saved 2026-04-26 evening end-of-session
|
||
|
||
Steward heading to bed; the question came as the last before sleep: *"It should help us to keep much more in track, no?"* Honest answer: yes, real leverage; not wishful thinking; depends on protocol discipline being operative not just available; same shape as canonical-tracker discipline at mid-session scale. |