# Planning Alignment
## Source
This document aligns the current repository design with the prior Obsidian planning note:
`KnowledgeVault/10-Projects/Rust 知识库上下文工具规划`
That note remains the original product seed and should be treated as upstream planning context.
## What The Earlier Plan Got Right
The previous plan established several decisions that still hold:
1. Obsidian is the knowledge source of truth
2. the product should serve multiple AI tools, not a single vendor
3. development should start from a CLI core
4. MCP should come before heavy desktop investment
5. deterministic routing should come before semantic or embedding-heavy systems
6. GUI should not distract from proving core retrieval value
## What Has Been Preserved
### Preserved Product Shape
The earlier three-phase sequence still makes sense:
1. CLI
2. MCP
3. desktop maintenance tooling
### Preserved Technical Bias
These older constraints remain valid:
- prefer structure-aware retrieval over premature vector search
- prefer stable explainable routing over magic summaries
- keep the tool close to the developer's existing workflow
## What Has Been Expanded
The current design extends the earlier plan in several important ways.
### 1. From Context Tool To Memory System
Earlier framing:
- a Rust knowledge-base context tool
Current framing:
- a local-first developer memory operating system
This is an expansion, not a contradiction. The original CLI router remains the first stable slice of the larger system.
### 2. Stronger Security Direction
The older plan emphasized local execution and Obsidian integration, but the current design makes security an explicit first-class product principle:
- local-first storage
- sensitivity tiers
- provenance
- policy-aware retrieval
- controlled exposure to AI clients
### 3. Separate Memory Ledger
The older plan treated Obsidian as the sole source of truth, which is still correct for curated knowledge.
The current design adds a distinction:
- Obsidian is the curated knowledge-of-record layer
- a separate local memory ledger should store raw captured session memory
This prevents transcript-style data from polluting curated notes.
### 4. Wake-Up And Long-Term Adaptation
The previous plan focused mainly on project and task context.
The current design adds:
- developer identity packets
- preference memory
- decision memory
- incident memory
- wake-up packets for cross-AI continuity
### 5. Benchmark And Cache Discipline
The prior plan was correct about proving CLI value first.
The current repository now also includes:
- retrieval benchmarks
- route explainability
- scan and build-path profiling
- early cache and indexing work
## Current Product Interpretation
The earlier planning note should be read as:
- the canonical origin of the project
- the first-scope definition
- the reason the repository began with CLI-first routing
The current docs should be read as:
- the expanded long-term architecture
- the security and memory-system interpretation
- the roadmap for turning the CLI into a broader cross-AI memory gateway
## Stable Direction Going Forward
Unless explicitly revised by a future ADR, the product direction is:
1. keep CLI stable and useful
2. add MCP next
3. treat desktop as a maintenance and inspection surface, not the primary product
4. keep Obsidian as curated truth
5. build separate local memory capture and distillation beside it
6. prefer secure, explainable retrieval over opaque memory magic
## Follow-Up Recommendation
Future significant strategy changes should be expressed as ADRs that explicitly say whether they:
- preserve the original three-phase plan
- narrow it
- replace it