Skip to content

refactor: decompose daemon handlers by capability-owned concern #2132

Description

@thymikee

Blocked by: #2131. Do not start implementation until replay has one accepted daemon seam and the child plan is rebased onto current main.

Outcome

Decompose the remaining src/daemon/handlers hotspot by capability-owned concerns, with one executable child issue and reviewable PR per concern. This is an umbrella, not authorization for one directory-reorganization PR.

Required concern children

  • session lifecycle: open, close, inventory, binding
  • test-suite hosting only if it remains outside replay after the replay extraction
  • perf and observability
  • interaction execution and deferred outcomes

Each child issue must name exact source files, commands, current writer owners, store/state reads, capability imports, destination module, route adapter, behavior tests, structural boundary plants, and prerequisite PRs.

Interface rules

  • One external façade per concern, shared by routing and contract tests.
  • Compare a capability aggregate with existing owner operations; do not preselect either.
  • No anonymous Pick<SessionState>/Pick<SessionStore> or copied state record.
  • Foreign writes continue through existing R7 owners.
  • A new abstraction needs either two real production consumers/implementations or a deletion argument strong enough to justify one implementation. A test adapter is not a second production seam.
  • Shrink SessionCommandInput only by fields exclusive to the migrated concern; fields needed by unmigrated concerns remain until their slice.

Size constraint

This program exists to delete handler plumbing and narrow authority. Each child PR must target net production shrinkage, report gross additions/deletions and move-adjusted LOC, and remove superseded modules/tests/baseline slack. New façade ceremony without compensating deletion is a stop condition.

Proof per child

  • Behavior contract through the current route before moving implementation.
  • Planted behavior violation plus both forbidden deep-import directions.
  • Exact focused tests, pnpm check:layering, fallow audit, and pnpm check:affected --run.
  • Before/after state-shape, store-authority, capability, and cross-concern edges are diagnostic evidence; no arbitrary numerical pass threshold.

Done criteria

  • Every concern has an executable child issue and dependency chain.
  • Minimal handlers perform routing only.
  • Session writes remain with declared owners and broad read/capability surfaces shrink.
  • No sibling concern deep-imports another concern's internals.
  • The full program produces a net reduction in production LOC.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions