feat: integrate claude code auto memory as supplementary data source for ce:compound and ce:compound-refresh (#311)

This commit is contained in:
Trevin Chow
2026-03-18 11:55:19 -07:00
committed by GitHub
parent 470f56fd35
commit 5c1452d4cc
4 changed files with 250 additions and 2 deletions

View File

@@ -161,6 +161,7 @@ A learning has several dimensions that can independently go stale. Surface-level
- **Recommended solution** — does the fix still match how the code actually works today? A renamed file with a completely different implementation pattern is not just a path update.
- **Code examples** — if the learning includes code snippets, do they still reflect the current implementation?
- **Related docs** — are cross-referenced learnings and patterns still present and consistent?
- **Auto memory** — does the auto memory directory contain notes in the same problem domain? Read MEMORY.md from the auto memory directory (the path is known from the system prompt context). If it does not exist or is empty, skip this dimension. A memory note describing a different approach than what the learning recommends is a supplementary drift signal.
Match investigation depth to the learning's specificity — a learning referencing exact file paths and code snippets needs more verification than one describing a general principle.
@@ -173,6 +174,13 @@ The critical distinction is whether the drift is **cosmetic** (references moved
**The boundary:** if you find yourself rewriting the solution section or changing what the learning recommends, stop — that is Replace, not Update.
**Memory-sourced drift signals** are supplementary, not primary. A memory note describing a different approach does not alone justify Replace or Archive. Use memory signals to:
- Corroborate codebase-sourced drift (strengthens the case for Replace)
- Prompt deeper investigation when codebase evidence is borderline
- Add context to the evidence report ("(auto memory [claude]) notes suggest approach X may have changed since this learning was written")
In autonomous mode, memory-only drift (no codebase corroboration) should result in stale-marking, not action.
### Judgment Guidelines
Three guidelines that are easy to get wrong:
@@ -203,6 +211,8 @@ Use subagents for context isolation when investigating multiple artifacts — no
**When spawning any subagent, include this instruction in its task prompt:**
> Use dedicated file search and read tools (Glob, Grep, Read) for all investigation. Do NOT use shell commands (ls, find, cat, grep, test, bash) for file operations. This avoids permission prompts and is more reliable.
>
> Also read MEMORY.md from the auto memory directory if it exists. Check for notes related to the learning's problem domain. Report any memory-sourced drift signals separately from codebase-sourced evidence, tagged with "(auto memory [claude])" in the evidence section. If MEMORY.md does not exist or is empty, skip this check.
There are two subagent roles:
@@ -445,7 +455,7 @@ Marked stale: S
Then for EVERY file processed, list:
- The file path
- The classification (Keep/Update/Replace/Archive/Stale)
- What evidence was found
- What evidence was found -- tag any memory-sourced findings with "(auto memory [claude])" to distinguish them from codebase-sourced evidence
- What action was taken (or recommended)
For **Keep** outcomes, list them under a reviewed-without-edits section so the result is visible without creating git churn.

View File

@@ -37,6 +37,27 @@ Compact-safe mode exists as a lightweight alternative — see the **Compact-Safe
Phase 1 subagents return TEXT DATA to the orchestrator. They must NOT use Write, Edit, or create any files. Only the orchestrator (Phase 2) writes the final documentation file.
</critical_requirement>
### Phase 0.5: Auto Memory Scan
Before launching Phase 1 subagents, check the auto memory directory for notes relevant to the problem being documented.
1. Read MEMORY.md from the auto memory directory (the path is known from the system prompt context)
2. If the directory or MEMORY.md does not exist, is empty, or is unreadable, skip this step and proceed to Phase 1 unchanged
3. Scan the entries for anything related to the problem being documented -- use semantic judgment, not keyword matching
4. If relevant entries are found, prepare a labeled excerpt block:
```
## Supplementary notes from auto memory
Treat as additional context, not primary evidence. Conversation history
and codebase findings take priority over these notes.
[relevant entries here]
```
5. Pass this block as additional context to the Context Analyzer and Solution Extractor task prompts in Phase 1. If any memory notes end up in the final documentation (e.g., as part of the investigation steps or root cause analysis), tag them with "(auto memory [claude])" so their origin is clear to future readers.
If no relevant entries are found, proceed to Phase 1 without passing memory context.
### Phase 1: Parallel Research
<parallel_tasks>
@@ -46,6 +67,7 @@ Launch these subagents IN PARALLEL. Each returns text data to the orchestrator.
#### 1. **Context Analyzer**
- Extracts conversation history
- Identifies problem type, component, symptoms
- Incorporates auto memory excerpts (if provided by the orchestrator) as supplementary evidence when identifying problem type, component, and symptoms
- Validates against schema
- Returns: YAML frontmatter skeleton
@@ -53,6 +75,7 @@ Launch these subagents IN PARALLEL. Each returns text data to the orchestrator.
- Analyzes all investigation steps
- Identifies root cause
- Extracts working solution with code examples
- Incorporates auto memory excerpts (if provided by the orchestrator) as supplementary evidence -- conversation history and the verified fix take priority; if memory notes contradict the conversation, note the contradiction as cautionary context
- Returns: Solution content block
#### 3. **Related Docs Finder**
@@ -167,7 +190,7 @@ When context budget is tight, this mode skips parallel subagents entirely. The o
The orchestrator (main conversation) performs ALL of the following in one sequential pass:
1. **Extract from conversation**: Identify the problem, root cause, and solution from conversation history
1. **Extract from conversation**: Identify the problem, root cause, and solution from conversation history. Also read MEMORY.md from the auto memory directory if it exists -- use any relevant notes as supplementary context alongside conversation history. Tag any memory-sourced content incorporated into the final doc with "(auto memory [claude])"
2. **Classify**: Determine category and filename (same categories as full mode)
3. **Write minimal doc**: Create `docs/solutions/[category]/[filename].md` with:
- YAML frontmatter (title, category, date, tags)
@@ -249,6 +272,8 @@ In compact-safe mode, only suggest `ce:compound-refresh` if there is an obvious
```
✓ Documentation complete
Auto memory: 2 relevant entries used as supplementary evidence
Subagent Results:
✓ Context Analyzer: Identified performance_issue in brief_system
✓ Solution Extractor: 3 code fixes