# Daemon Boundary Round 11 Plan
## Summary
Round 11 should define and implement the first explicit daemon boundary for spool without collapsing the existing CLI/MCP contracts.
The work is sequenced in this order:
1. define the smallest resident-process responsibility
2. keep CLI/MCP as thin clients or direct fallbacks
3. verify daemon/no-daemon parity where possible
## Key Changes
### Boundary
- choose one narrow responsibility for the daemon:
- long-lived cache ownership
- repeated retrieval service
- lifecycle projection serving
- avoid moving all business logic into the daemon in one step
### Compatibility
- keep the current direct code path available as fallback
- avoid forcing CLI/MCP clients to require the daemon in the first version
## Test Plan
- daemon startup/shutdown checks
- parity tests between direct and daemon-backed reads
- fallback tests when the daemon is unavailable
## Assumptions
- Round 11 does not remove current direct CLI/MCP paths
- Round 11 does not redesign the lifecycle domain
- Round 11 keeps correctness ahead of background complexity
## Completion Status
Last checked: `2026-04-13`
Completed in this round:
- added `spool-daemon` as a minimal lifecycle read stdio daemon
- kept the daemon boundary narrow:
- `ping`
- `workbench`
- `record`
- `history`
- kept CLI/MCP direct paths unchanged as fallbacks
- current `DaemonClient` integration now reuses a shared stdio daemon session keyed by `(daemon_bin, config_path)` across repeated reads and across client instances in one process
- if the shared daemon session dies, the next request drops the stale session, rebuilds it once, and then continues; direct fallback remains intact when daemon transport still fails after rebuild
- hardened daemon stdio parsing so malformed JSON now returns structured `ok: false` errors instead of terminating the process immediately, and the daemon continues serving subsequent requests on the same stdio session
- added shared-session recovery coverage for both daemon read helpers and MCP lifecycle read integration
- added daemon module coverage and end-to-end daemon smoke coverage
- verification completed with full test and check passes
- downstream lifecycle surfaces now also share formatter/summary helpers so daemon-backed reads feed more consistent CLI/GUI/MCP result shapes
Checked for omissions against this plan:
- no missed items inside the scoped implementation baseline
- current direct CLI/MCP paths remain intact
- lifecycle domain remains unchanged
- daemon complexity remains intentionally narrow