π File detail
services/autoDream/consolidationPrompt.ts
π§© .tsπ 66 linesπΎ 3,225 bytesπ text
β Back to All Filesπ― Use case
This file lives under βservices/β, which covers long-lived services (LSP, MCP, OAuth, tool execution, memory, compaction, voice, settings sync, β¦). On the API surface it exposes buildConsolidationPrompt β mainly functions, hooks, or classes. It composes internal code from memdir (relative imports). What the file header says: Extracted from dream.ts so auto-dream ships independently of KAIROS feature flags (dream.ts is behind a feature()-gated require).
Generated from folder role, exports, dependency roots, and inline comments β not hand-reviewed for every path.
π§ Inline summary
Extracted from dream.ts so auto-dream ships independently of KAIROS feature flags (dream.ts is behind a feature()-gated require).
π€ Exports (heuristic)
buildConsolidationPrompt
π₯οΈ Source preview
// Extracted from dream.ts so auto-dream ships independently of KAIROS
// feature flags (dream.ts is behind a feature()-gated require).
import {
DIR_EXISTS_GUIDANCE,
ENTRYPOINT_NAME,
MAX_ENTRYPOINT_LINES,
} from '../../memdir/memdir.js'
export function buildConsolidationPrompt(
memoryRoot: string,
transcriptDir: string,
extra: string,
): string {
return `# Dream: Memory Consolidation
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.
Memory directory: \`${memoryRoot}\`
${DIR_EXISTS_GUIDANCE}
Session transcripts: \`${transcriptDir}\` (large JSONL files β grep narrowly, don't read whole files)
---
## Phase 1 β Orient
- \`ls\` the memory directory to see what already exists
- Read \`${ENTRYPOINT_NAME}\` to understand the current index
- Skim existing topic files so you improve them rather than creating duplicates
- If \`logs/\` or \`sessions/\` subdirectories exist (assistant-mode layout), review recent entries there
## Phase 2 β Gather recent signal
Look for new information worth persisting. Sources in rough priority order:
1. **Daily logs** (\`logs/YYYY/MM/YYYY-MM-DD.md\`) if present β these are the append-only stream
2. **Existing memories that drifted** β facts that contradict something you see in the codebase now
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:
\`grep -rn "<narrow term>" ${transcriptDir}/ --include="*.jsonl" | tail -50\`
Don't exhaustively read transcripts. Look only for things you already suspect matter.
## Phase 3 β Consolidate
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.
Focus on:
- Merging new signal into existing topic files rather than creating near-duplicates
- Converting relative dates ("yesterday", "last week") to absolute dates so they remain interpretable after time passes
- Deleting contradicted facts β if today's investigation disproves an old memory, fix it at the source
## Phase 4 β Prune and index
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.
- Remove pointers to memories that are now stale, wrong, or superseded
- 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
- Add pointers to newly important memories
- Resolve contradictions β if two files disagree, fix the wrong one
---
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}` : ''}`
}