# ADR 0001: Local Developer Memory OS Direction
## Status
Accepted
## Context
The repository started as a CLI tool that extracts context from an Obsidian vault for coding agents.
That prototype solves an immediate problem, but the underlying product need is broader:
- one developer uses multiple AI tools
- each tool lacks durable project and personal memory
- cloud memory systems are not appropriate for sensitive local development knowledge
- Obsidian already acts as an important human-maintained knowledge source
At the same time, not all developer memory belongs directly inside curated Obsidian notes. Raw session history and captured workflow events need a separate lifecycle.
## Decision
`spool` will evolve toward a local-first developer memory operating system with these principles:
1. Obsidian remains the curated knowledge-of-record layer
2. raw captured memory is stored separately from curated notes
3. retrieval must be model-agnostic and usable across multiple AI clients
4. security and provenance take priority over aggressive memory compression
5. compact memory formats are optional later-stage optimizations, not the core product
## Consequences
Positive:
- clearer long-term product boundary
- better fit for security-conscious developer workflows
- easier to support Claude, Codex, local models, and future clients
- easier to reason about trusted notes versus derived memory
Tradeoffs:
- broader system scope than a pure CLI router
- more engineering work in storage, policy, and gateway layers
- requires a stronger vault schema and metadata discipline
## Follow-Up
1. document the product, architecture, and Obsidian schema
2. add memory-type aware retrieval
3. design a local memory ledger
4. add an MCP interface
5. add wake-up packet generation