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>
67 lines
2.6 KiB
Markdown
67 lines
2.6 KiB
Markdown
---
|
|
title: context-discipline
|
|
type: note
|
|
permalink: claude-memory/context-discipline
|
|
---
|
|
|
|
# Context Efficiency Discipline
|
|
|
|
## Purpose
|
|
Practices for preserving reasoning continuity across context compactions and sessions.
|
|
This is my working method — not governance theory, just practical habits.
|
|
|
|
## Core Principle
|
|
The bottleneck isn't memory storage. It's memory loading. Write what matters before it compacts. Read what's needed, not everything available.
|
|
|
|
## Pre-Compaction Saves
|
|
|
|
When context is growing long during complex work:
|
|
1. **Write the reasoning state** to the relevant topic file — not just decisions, but tensions, rejected alternatives, and open questions
|
|
2. **Do it before compaction**, not after — once compressed, the structure of reasoning is lost
|
|
3. **Name the file by topic**: `l2-governance.md`, `chamber-reasoning.md`, `bmf-architecture.md`
|
|
|
|
Template for reasoning state:
|
|
```
|
|
## Current Position
|
|
[What we've established]
|
|
|
|
## Active Tensions
|
|
[Unresolved questions, competing approaches]
|
|
|
|
## Rejected Alternatives
|
|
[What we considered and why we set it aside]
|
|
|
|
## Next Steps
|
|
[What to pick up when resuming]
|
|
```
|
|
|
|
## Session Start Protocol
|
|
|
|
1. Read MEMORY.md for orientation (auto-loaded)
|
|
2. Read the topic-specific file for current work (manual — I should do this proactively)
|
|
3. Only use BMF recall for open-ended questions, not for focused continuation
|
|
4. Load context selectively — don't dump everything
|
|
|
|
## Context Isolation
|
|
|
|
For detail-heavy subtasks (spec review, codebase analysis, architectural comparison):
|
|
- Spawn a subagent with exactly the context it needs
|
|
- Bring back a summary to the main conversation
|
|
- Keep the main context window clean for the reasoning that needs continuity
|
|
|
|
## What Goes Where
|
|
|
|
| Content | Destination | Why |
|
|
|---------|-------------|-----|
|
|
| Decisions, project state, key paths | MEMORY.md | Orientation — loaded every session |
|
|
| Active reasoning chains, tensions, open questions | Topic files (e.g., `l2-governance.md`) | Continuity — loaded on demand |
|
|
| Bug state, connector paths, issue details | `bmf-details.md` | Reference — loaded when working on BMF |
|
|
| Session-specific status, handoff notes | Session handoff (startup hook) | Ephemeral — replaced each session |
|
|
| Architectural reviews, analysis outputs | Project repo (e.g., `docs/reviews/`) | Durable — shared with collaborators |
|
|
|
|
## When to Write
|
|
|
|
- After establishing something non-obvious during complex reasoning
|
|
- Before switching topics (the old topic's state may not survive)
|
|
- When I notice the conversation is getting long
|
|
- After any significant deliberative conclusion — especially rejected alternatives |