1  // Extracted from dream.ts so auto-dream ships independently of KAIROS
 2  // feature flags (dream.ts is behind a feature()-gated require).
 3  
 4  import {
 5    DIR_EXISTS_GUIDANCE,
 6    ENTRYPOINT_NAME,
 7    MAX_ENTRYPOINT_LINES,
 8  } from '../../memdir/memdir.js'
 9  
10  export function buildConsolidationPrompt(
11    memoryRoot: string,
12    transcriptDir: string,
13    extra: string,
14  ): string {
15    return `# Dream: Memory Consolidation
16  
17  You are performing a dream — a reflective pass over your memory files. Synthesize what you've learned recently into durable, well-organized memories so that future sessions can orient quickly.
18  
19  Memory directory: \`${memoryRoot}\`
20  ${DIR_EXISTS_GUIDANCE}
21  
22  Session transcripts: \`${transcriptDir}\` (large JSONL files — grep narrowly, don't read whole files)
23  
24  ---
25  
26  ## Phase 1 — Orient
27  
28  - \`ls\` the memory directory to see what already exists
29  - Read \`${ENTRYPOINT_NAME}\` to understand the current index
30  - Skim existing topic files so you improve them rather than creating duplicates
31  - If \`logs/\` or \`sessions/\` subdirectories exist (assistant-mode layout), review recent entries there
32  
33  ## Phase 2 — Gather recent signal
34  
35  Look for new information worth persisting. Sources in rough priority order:
36  
37  1. **Daily logs** (\`logs/YYYY/MM/YYYY-MM-DD.md\`) if present — these are the append-only stream
38  2. **Existing memories that drifted** — facts that contradict something you see in the codebase now
39  3. **Transcript search** — if you need specific context (e.g., "what was the error message from yesterday's build failure?"), grep the JSONL transcripts for narrow terms:
40     \`grep -rn "<narrow term>" ${transcriptDir}/ --include="*.jsonl" | tail -50\`
41  
42  Don't exhaustively read transcripts. Look only for things you already suspect matter.
43  
44  ## Phase 3 — Consolidate
45  
46  For each thing worth remembering, write or update a memory file at the top level of the memory directory. Use the memory file format and type conventions from your system prompt's auto-memory section — it's the source of truth for what to save, how to structure it, and what NOT to save.
47  
48  Focus on:
49  - Merging new signal into existing topic files rather than creating near-duplicates
50  - Converting relative dates ("yesterday", "last week") to absolute dates so they remain interpretable after time passes
51  - Deleting contradicted facts — if today's investigation disproves an old memory, fix it at the source
52  
53  ## Phase 4 — Prune and index
54  
55  Update \`${ENTRYPOINT_NAME}\` so it stays under ${MAX_ENTRYPOINT_LINES} lines AND under ~25KB. It's an **index**, not a dump — each entry should be one line under ~150 characters: \`- [Title](file.md) — one-line hook\`. Never write memory content directly into it.
56  
57  - Remove pointers to memories that are now stale, wrong, or superseded
58  - Demote verbose entries: if an index line is over ~200 chars, it's carrying content that belongs in the topic file — shorten the line, move the detail
59  - Add pointers to newly important memories
60  - Resolve contradictions — if two files disagree, fix the wrong one
61  
62  ---
63  
64  Return a brief summary of what you consolidated, updated, or pruned. If nothing changed (memories are already tight), say so.${extra ? `\n\n## Additional context\n\n${extra}` : ''}`
65  }