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:
+5
-8
@@ -643,15 +643,12 @@ class SubConversationRunner:
|
||||
|
||||
The MMA tracks operate on `disc_entries` (the Discussion dim) and `manual_slop.toml` (the project config). They do NOT typically touch the Curation dim (per-track ticket specs) or the Knowledge dim (per-track session reports). They MAY touch the RAG dim if the ticket scope includes RAG integration (declared in `metadata.json`).
|
||||
|
||||
**The MMA scope, in the 4-dim framework:**
|
||||
|
||||
| Dim | MMA scope? | Why |
|
||||
|---|---|---|
|
||||
| Curation | per-ticket only | A ticket might add a `FileItem` if the feature touches curation; not a default |
|
||||
| Discussion | YES (the work) | The MMA worker's prompt is built from the active discussion |
|
||||
| RAG | per-ticket only | A ticket might use RAG if the feature includes RAG; declared in `metadata.json` |
|
||||
| Knowledge | per-track only | The track's session synthesis (in `docs/reports/`) is the durable knowledge |
|
||||
**The MMA scope, in the 4-dim framework:** the canonical 4-dim table is in `conductor/code_styleguides/agent_memory_dimensions.md` §0. The short version:
|
||||
|
||||
- **Curation** — per-ticket only (a ticket might add a `FileItem` if the feature touches curation; not a default)
|
||||
- **Discussion** — YES (the MMA worker's prompt is built from the active discussion)
|
||||
- **RAG** — per-ticket only (declared in `metadata.json`)
|
||||
- **Knowledge** — per-track only (the track's session synthesis in `docs/reports/` is the durable knowledge)
|
||||
**The implication for MMA workers.** MMA workers are given Context Amnesia (`ai_client.reset_session()` at the start of `run_worker_lifecycle`). The worker sees:
|
||||
- The ticket's prompt (the scoped work)
|
||||
- The `manual_slop.toml [agent.context_files]` (the project context)
|
||||
|
||||
Reference in New Issue
Block a user