# Next Steps
## Status Baseline
As of `2026-04-14`, `spool` has already reached this implementation baseline:
- retrieval and wakeup flows are implemented
- memory lifecycle core is implemented in minimum viable form
- CLI and MCP surfaces are implemented
- optional daemon-backed lifecycle reads are implemented
- desktop now includes a minimal Tauri host/bootstrap slice plus a static frontend shell
This means the next work should not restart from routing or ledger basics.
## Recommended Default Direction
Default recommendation:
1. finish the desktop host boundary
2. then move into retrieval intelligence
3. then resume unfinished ingestion/distillation work
Reason:
- the backend contract for desktop already exists, so the shortest path to a visibly more complete product is to wire a real host on top of it
- a first host/bootstrap slice now exists, so the next desktop work should harden and widen that slice instead of rebuilding it
- retrieval intelligence work will matter more once a clearer product surface exists for real usage and debugging
- importer/distillation work should follow after the main operator surfaces and retrieval diagnostics are easier to exercise
## Path A: Finish Desktop Host
Use this path if the goal is product usability first.
### Objective
Turn the current minimal Tauri host/bootstrap slice into a real desktop product surface.
### Deliverables
- harden and extend the runnable Tauri host over the existing `src/desktop.rs` + `src/desktop/tauri.rs` boundary
- minimal desktop shell for:
- context retrieval
- wakeup generation
- review queue inspection
- record detail/history inspection
- manual/proposed memory creation
- accept / promote / archive actions
- consistent error handling using `DesktopErrorEnvelope`
### Suggested Execution Order
1. preserve and verify the existing desktop-to-Tauri request/response mapping
2. convert the current `src-tauri/` scaffold into a real host bootstrap
3. expose a narrow initial screen flow instead of building a full shell at once
4. wire lifecycle read flows first
5. wire create/propose/action flows second
6. keep presentation logic reusing shared lifecycle summary/format helpers where possible
### Risks To Avoid
- do not fork lifecycle response formats just for desktop
- do not bypass `src/desktop.rs` and call lower layers directly from the host
- do not expand into batch editing before single-record flows are stable
## Path B: Retrieval Intelligence
Use this path if the goal is core retrieval quality first.
### Objective
Improve retrieval precision, inspectability, and long-term maintainability without destabilizing the existing lifecycle core.
### Deliverables
- better section excerpt selection
- clearer score diagnostics in machine-readable output
- benchmark coverage for larger vaults
- decision on whether a heavier retrieval index is justified
- later-phase evaluation of semantic retrieval / contradiction detection / confidence scoring
### Suggested Execution Order
1. improve best-section excerpt selection
2. expose richer score breakdowns in `json`
3. add large-vault benchmark cases
4. measure bottlenecks before introducing a heavier index
5. only then evaluate semantic retrieval or contradiction/confidence layers
### Risks To Avoid
- do not jump to embeddings before current heuristic/debuggability limits are measured
- do not add opaque scoring layers that weaken explainability
- do not introduce new derived-state artifacts without clear invalidation rules
## Path C: Ingestion And Distillation
Use this path after either desktop or retrieval work has clarified the next operational bottleneck.
### Objective
Move from manual/proposed memory entry toward workflow-derived memory capture.
### Deliverables
- transcript importer
- git activity importer
- terminal metadata importer
- extraction pipeline for decision / incident / pattern candidates
- promotion flow from ledger records into curated Obsidian notes
### Suggested Execution Order
1. define importer boundaries and source metadata contracts
2. add one importer at a time behind explicit file formats
3. keep raw imports append-only and separate from curated notes
4. add extraction pipeline after raw import shape is stable
5. add promotion flow only after extracted records are inspectable and reviewable
### Risks To Avoid
- do not write raw imported memory directly into curated Obsidian notes
- do not hide provenance during extraction
- do not couple importers too tightly to one AI client or transcript format
## Immediate Recommendation
If no new external requirement forces a different priority, choose this sequence:
1. finish a minimal desktop host
2. improve retrieval diagnostics and excerpt quality
3. add importer/distillation foundations
## Canonical Files To Read Before Continuing
1. [SESSION_HANDOFF.md](/Users/long/Work/spool/docs/SESSION_HANDOFF.md)
2. [ROADMAP.md](/Users/long/Work/spool/docs/ROADMAP.md)
3. [PRODUCT.md](/Users/long/Work/spool/docs/PRODUCT.md)
4. [src/desktop.rs](/Users/long/Work/spool/src/desktop.rs)
5. [src/lifecycle_service.rs](/Users/long/Work/spool/src/lifecycle_service.rs)
6. [src/lifecycle_summary.rs](/Users/long/Work/spool/src/lifecycle_summary.rs)
7. [src/mcp.rs](/Users/long/Work/spool/src/mcp.rs)
8. [src/daemon.rs](/Users/long/Work/spool/src/daemon.rs)