# 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
