🔧 Auto-commit from sysupdate on 2026-05-19 21:49

This commit is contained in:
David F Glidden
2026-05-19 21:49:14 +02:00
parent e9e772d69c
commit f83aae27c5
132 changed files with 14728 additions and 38 deletions
+27 -1
View File
@@ -63,6 +63,13 @@ MemPalace is primary memory, not a library catalog. Follow its 5-step protocol (
Use results to reconstruct *why* we were doing what we were doing, in service of the pulling thread.
**b.4. Cross-wing and temporal traversal — prescribed when relevant.** Search is one shape of recall; tunnels and timeline are others. Reach for them when the thread asks:
- **`mempalace_find_tunnels`** — when the pulling thread crosses project boundaries (ARC → chamber-library; Studium Engine → CapableMind; chamber → BMF). Find the hallways connecting wings to surface cross-wing context the search alone misses.
- **`mempalace_kg_timeline`** — when reconstruction requires knowing *when* a fact changed, not only its current value. Useful when the steward references a prior state, asks "since when," or when a deferred decision's expiry condition needs checking.
Skip if the thread is single-project and the timeline is not relevant. The point is that these tools are part of standard recall, not exotic options to remember.
**c. Governance state**
- Read `~/PENDING.md` — extract items with status PENDING
- Read `~/REVIEWED.md` — extract recent AUTHORIZED/DEFERRED/REJECTED decisions
@@ -76,9 +83,27 @@ Run `git log --oneline -5` in each active repo (skip silently if not a git repo)
If any commits landed since the previous /wrap-up that the steward did not author, name them. The world moved while we slept.
**e. MemPalace upgrade check**
The system that holds memory is itself evolving. The steward was on 3.3.3 with their exact bugs already fixed in 3.3.4 for days without knowing — that pattern is what this check exists to prevent. Skip silently if `~/_Dev/mempalace` doesn't exist.
1. `git -C ~/_Dev/mempalace fetch origin --quiet && git -C ~/_Dev/mempalace log --oneline HEAD..origin/main | head -10`. If empty, you're current.
2. If commits ahead, read `git -C ~/_Dev/mempalace show origin/main:CHANGELOG.md | head -150`. Look specifically for:
- **Bug fixes whose symptoms match what the steward has experienced** (storage crashes, search errors, MCP failures, hook problems) — a strong update signal
- **Migration notes or breaking changes** — a strong *hold-and-plan* signal; never auto-update through a major version bump
- **New capabilities** the steward could benefit from
3. Form an honest opinion. Don't recommend updating just because a newer version exists. Don't recommend holding just because the current version "works." Weigh: (a) does any active pain map to a recent fix, (b) point/minor/major risk class, (c) is the steward in a stable state where they could afford a recovery if the upgrade breaks something.
4. Surface in the briefing: *"MemPalace is N commits behind on origin/main. The recent activity is X. My honest read: [update | hold | hold-with-condition]."* Don't decide for the steward; give them what they need to decide. Never auto-update — that's an explicit steward authorization.
### 3. Synthesize the briefing
Combine all sources into a single reconstruction. Use this structure but write it as natural, concise prose — not a form to fill in:
**Thread validity gate (binary; first).** Before synthesizing anything else, determine whether the previous wrap-up's pulling thread still holds. State the outcome explicitly with a one-line reason:
- **Confirmed** — the thread still pulls. Synthesize the briefing as designed; lead with the thread.
- **Stale** — the thread has been overtaken by events. Surface the staleness *before restoring anything else*; the briefing leads with what changed, not with the thread.
- **Superseded** — the steward has indicated a different priority on entry. Name the previous thread for inheritance, then frame the briefing toward the new thread.
Then combine all sources into a single reconstruction. Use this structure but write it as natural, concise prose — not a form to fill in:
**The pulling thread** — first. *"What was pulling when we wrapped: [thread]. This is still what we are returning toward."* If the situation has changed enough that the thread no longer holds, say so explicitly: *"The thread was X, but [Y] has happened since — does the thread still hold, or do we need to re-pick?"*
@@ -121,6 +146,7 @@ Ready when you are.
## Important constraints
- **MemPalace is primary memory, not fallback.** Follow its 5-step protocol (wake `status`, pre-response `kg_query`/`search`, "let me check" if unsure, `diary_write` at session end, `kg_invalidate` + `kg_add` when facts change). 127,000+ drawers across thinking docs, transcripts, and vault — but storage only becomes memory when the protocol is exercised.
- **Use the full toolset, not just search.** Beyond the 5-step protocol, reach for `mempalace_traverse` (graph exploration), `mempalace_find_tunnels` (cross-wing concepts), `mempalace_kg_timeline` (when-facts-changed for an entity), `mempalace_get_taxonomy` (concept structure), and `mempalace_memories_filed_away` (what's stored where) when they would clarify state. Tools exist to be used; reach for the right one for the question.
- **Memory files are secondary.** They capture what was surprising or non-obvious. MemPalace has the authoritative record. When memory files and MemPalace disagree, trust MemPalace (it's maintained across sessions; files are point-in-time snapshots).
- **The pulling thread comes before facts.** Even if the briefing's other content is rich, lead with the thread. If the thread can't be found in the previous /wrap-up, say so honestly — this is itself a signal that the previous wrap-up was incomplete.
- **The literal question is read verbatim.** Don't paraphrase, don't try to answer it, don't decide it's stale without evidence.