# Roadmap
## Current State
`spool` is currently a local-first developer memory toolchain with:
- project-based vault scanning
- heuristic note ranking
- multi-format rendering
- wakeup packet generation and policy-aware rendering
- append-only lifecycle ledger and latest-state projections
- CLI, MCP, GUI, daemon, and desktop-backend surfaces
- experimental GUI behind a feature flag
## Relationship To The Original Plan
The original planning note defined a three-step path:
1. CLI
2. MCP
3. desktop client
That sequence is still valid.
The current roadmap expands the scope around that sequence by adding:
- security and policy enforcement
- memory ledger separation
- wake-up packets
- cross-AI memory continuity
## Phase 0: Harden The Router
Status: mostly complete, still open for retrieval-quality improvements
Goals:
- improve retrieval precision
- add benchmarks
- stabilize config and cache behavior
- document product direction
Deliverables:
- better field-aware ranking
- note indexing or equivalent derived-state support
- scan cache
- retrieval and end-to-end benchmarks
- design docs and ADRs
## Phase 1: Developer Memory Core
Status: complete in minimum viable form
Goals:
- introduce memory object schema
- add wake-up packet generation
- distinguish curated vault notes from captured memory
Deliverables:
- `memory_type` aware retrieval
- source-of-truth boosting
- developer profile packet
- project wake-up packet
- retrieval policy by sensitivity
## Phase 2: Memory Ledger
Status: partially complete
Goals:
- capture raw memory events locally
- avoid polluting curated Obsidian notes
Deliverables:
- local append-only session ledger
- importers for transcript, git, and terminal metadata
- memory extraction pipeline for decision and incident candidates
- promotion flow from ledger to curated notes
## Phase 3: Cross-AI Gateway
Status: complete in minimum viable form
Goals:
- support multiple AI clients through one local interface
Deliverables:
- MCP server
- stable CLI subcommands for search, wake-up, and explain
- local daemon mode for optional read-side reuse
- client-specific policy shaping
## Phase 4: Retrieval Intelligence
Status: not started
Goals:
- increase precision and long-term maintainability
Deliverables:
- stale-memory detection
- contradiction detection
- confidence scoring
- semantic retrieval with local embeddings
- better excerpt extraction
## Phase 5: Optional Compact Memory
Status: not started
Goals:
- reduce context cost without sacrificing trust
Deliverables:
- layered summaries
- room digests
- dense wake-up packets
- optional compact memory representation
This phase should happen only after structure, provenance, and security are stable.
## Immediate Next Milestones
### Milestone A
Sync roadmap/product docs with the implemented memory lifecycle baseline so restart decisions match current code reality.
### Milestone B
Decide the next major build direction:
- harden and extend the new minimal desktop host on top of the existing desktop facade/Tauri adapter boundary, or
- move directly into retrieval intelligence work
### Milestone C
If desktop comes first:
- extend the new runnable desktop host beyond its initial bootstrap slice
- wire a minimal frontend shell to existing context / wakeup / lifecycle flows
### Milestone D
If core quality comes first:
- improve excerpt selection
- expose clearer score diagnostics
- evaluate heavier retrieval index work before semantic retrieval
### Milestone E
Resume unfinished Phase 2 work:
- transcript / git / terminal importers
- extraction pipeline for decision and incident candidates
- promotion flow from ledger to curated notes
## Decision Discipline
Any roadmap change that affects:
- product scope
- security guarantees
- memory storage model
- integration surface
should be written as an ADR in `docs/adr/`.