docs: reduce redundant content across files; map references to canonical sources
Per user 'a bunch of docs just committed had redundant content across files. Can we do a reduction of that and instead map references to other files?' This commit reduces content duplication across 9 files. The canonical sources are kept as detailed references; the other files now point to them. Reductions (table replaced with 'see canonical' reference): 1. data_oriented_design.md §9: the 4-dim memory table (canonical: conductor/code_styleguides/agent_memory_dimensions.md §0) 2. guide_agent_memory_dimensions.md §0: the 4-dim memory table (canonical: conductor/code_styleguides/agent_memory_dimensions.md §0) 3. guide_caching_strategy.md §1: the 12-layer model (canonical: conductor/code_styleguides/cache_friendly_context.md §1) 4. guide_ai_client.md 'Cache strategy' section: the 12-layer model recap (canonical: conductor/code_styleguides/cache_friendly_context.md §1) 5. guide_knowledge_curation.md §1: the 5 category file details (canonical: conductor/code_styleguides/knowledge_artifacts.md §1) 6. product-guidelines.md 'Memory Dimensions' section: the 4-dim table (canonical: conductor/code_styleguides/agent_memory_dimensions.md §0) 7. guide_mma.md '4 memory dimensions' section: the MMA scope table (canonical: conductor/code_styleguides/agent_memory_dimensions.md §0) 8. docs/AGENTS.md §0 + §5-§8: 4-dim table + caching/knowledge/RAG/ feature flag tables (canonical: the per-topic styleguides in conductor/code_styleguides/) 9. AGENTS.md 'Code Styleguides' section: the 6-styleguide list (canonical: docs/AGENTS.md §2) The principle: each piece of content has ONE source of truth; other places point to it. The data-oriented way. Files retain their narrative flow and the 'what this is' intros, but the detailed tables are now in their canonical home. Net effect: -2100 bytes across 9 files (without losing any information - the canonical sources are unchanged). The 'cross-references' sections are kept; the duplicated content is removed.
This commit is contained in:
@@ -10,14 +10,9 @@
|
||||
|
||||
## 0. The 30-second version
|
||||
|
||||
Manual Slop has 4 memory dimensions for the conversation data:
|
||||
Manual Slop has 4 memory dimensions for the conversation data. **The full canonical table is in `conductor/code_styleguides/agent_memory_dimensions.md` §0** (curation / discussion / RAG / knowledge, with the SSDL shape tag per dim).
|
||||
|
||||
| # | Dim | Where it lives | What it stores | Status |
|
||||
|---|---|---|---|---|
|
||||
| 1 | **Curation** | `FileItem` + `ContextPreset` + Fuzzy Anchors | *How to render a file* in the AI's context window | Existing, strong |
|
||||
| 2 | **Discussion** | `app.disc_entries` + branching + UISnapshot | *What was said* in the conversation | Existing, strong |
|
||||
| 3 | **RAG** | `src/rag_engine.py` (ChromaDB) | *Semantic fingerprints* of indexed files | Opt-in |
|
||||
| 4 | **Knowledge** | `~/.manual_slop/knowledge/*.md` + per-file + digest | *Durable learnings* from past sessions | Proposed (Candidate 8) |
|
||||
**The one-line summary:** curation is per-file structural; discussion is per-turn conversational; RAG is opt-in semantic; knowledge is per-project durable. Pick the matching dimension; don't reach for the wrong shape.
|
||||
|
||||
**The decision tree:**
|
||||
|
||||
|
||||
Reference in New Issue
Block a user