Skip to content

Architecture

Mehmet Nuraydın edited this page Jul 19, 2026 · 2 revisions

The Architecture

Three lanes: Capture (Stop hook, PostToolUse, bookmarks, the RemSleep cycle, you) writes into the Store (_dream_context/ core, knowledge, state); the Store is read by Inject (SessionStart, UserPromptSubmit, PreToolUse, the compiled snapshot) which loads the agent with full context

Human brains don't store everything in one region. Your prefrontal cortex handles identity and decision-making. Your temporal lobe stores facts and relationships. You have procedural memory for skills you don't think about, and working memory for what you are actively doing. Different types of knowledge, different storage.

dreamcontext takes inspiration from this structure:

Brain Region dreamcontext What it holds
Prefrontal cortex 0.soul.md Identity, principles, rules, constraints
Episodic memory 1.user.md Your preferences, project conventions, workflow
Semantic memory 2.memory.md Decisions, known issues, technical context
Sensory cortex 3.style_guide_and_branding.md, 4.tech_stack.md Style, tech stack, data structures
Declarative memory features/ Feature PRDs with user stories, acceptance criteria, constraints
Long-term knowledge knowledge/ Deep docs, tagged with standard categories, pinnable for auto-loading
Working memory state/ Active tasks, in-progress work
Skill memory SKILL.md + references/ Teaches the agent the system itself

The _dream_context/ directory is the implementation. Everything lives in your repo, structured and version-controlled.

How each piece works

Soul (0.soul.md) defines who the agent is when working on your project. Project identity, core principles, behavioral rules, constraints, and warnings. For example: "Never use require() in this project" or "Always run tests before considering a change complete." This is the most stable file. It changes rarely and sets the foundation for everything else.

User (1.user.md) captures your preferences, communication style, and workflow conventions. For example: "No em dashes in writing, restructure the sentence instead" or "Make decisions directly, don't ask for permission on clear choices." Tech stack details go in their own extended core file. User is about how you work, not what you work with.

Memory (2.memory.md) is the working log of technical decisions, known issues, and session-level learnings. For example: "Chose Postgres over MongoDB because the data is highly relational" or "The auth middleware must run before rate limiting, not after." It follows LIFO ordering (newest at top) and is the file that changes most frequently. The sleep cycle keeps it from growing out of control.

Extended core files (slots 3-6) hold specialized context: style guide and branding, tech stack, data structures, and the system-flow reference. These are loaded as summaries in the snapshot with paths included, so the agent knows they exist without burning tokens loading the full content every session.

Knowledge (knowledge/) is where deep reference docs live. Architectural context, domain knowledge, research, design rationales. For example: a doc on "payment-flow-architecture" tagged with [architecture, payments, api] explaining the full Stripe integration and edge cases. Each file has frontmatter with tags and descriptions. The snapshot surfaces a complete index so the agent knows what docs exist. Files marked pinned: true get loaded in full every session for frequently-needed reference.

State (state/) holds active work: task files with progress logs and a sleep state file tracking consolidation debt. A task like "migrate-to-postgres" would have status, priority, and a LIFO log of every step taken. Tasks follow a lifecycle (pending, in-progress, blocked, completed).


Part of the dreamcontext deep dive — Home · README

Clone this wiki locally