content-allocationlisted

# Content Allocation A methodology for keeping project context lean and unambiguous. Every piece of content has exactly one canonical home; every other appearance is a one-line pointer. ## Methodology: One Topic, One Home **Core rule**: If a piece of content lives in two places, one of them is wrong. The canonical store owns the content; every other location is a one-line pointer to it. Why this matters: - `CLAUDE.md` and `MEMORY.md` are loaded **every turn**. Every line there has compounding cost across the project's lifetime. - Duplication drifts. When the same fact lives in two files, the next edit will update one and leave the other stale. - Readers (humans and assistants) waste tokens hunting through redundant copies for the authoritative version. The pattern works in three moves: 1. **Identify the canonical home** for a topic using the routing table below. 2. **Move the content** to that home. Compress all other appearances to a single-line pointer (`See: docs/RUNBOOK.md`). 3. **Enforce size budgets** so the canonical home does not bloat into a second copy of the wider docs tree. --- ## Routing Table The canonical stores in a typical Claude Code project, in load-order: | Store | Loaded | Owns | Does NOT own | |-------|--------|------|--------------| | `~/.claude/CLAUDE.md` (global) | every turn, every repo | Assistant default behaviour; user's machines, SSH, session history queries | Anything project-specific | | `CLAUDE.md` (project root) | every turn, this