# 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
