Module control

Expand description

The MultiplexerControl trait — every tear backend implements it.

tear-core::InProcess — embedded state machine. The native backend used when tear runs without a daemon, and the backend mado will eventually compose with directly (M5 — see project plan in CLAUDE.md).
tear-daemon — owns sessions across client disconnects, exposes a UDS RPC façade. Wraps InProcess rather than reimplementing.
tear-client — typed RPC client connected to a local or SSH-tunnelled tear-daemon. Implements MultiplexerControl so from the consumer’s perspective there’s no syntactic difference between local and remote.
tear-tmux-backend — passthrough to vanilla tmux. The escape hatch for remote hosts that have tmux but not tear.

All four backends share this trait so consumers (the CLI, mado, third-party drivers) author against ONE surface.

Enums§

ControlError: Failure modes a MultiplexerControl op can return. Variants stay narrow so consumers can pattern-match on the recoverable vs not-recoverable ones (e.g. RPC retries on Transport but gives up on NoSuchSession).

MultiplexerControl: The trait every tear backend implements. Operations are intentionally async-free at the trait level — backends that want async runtimes spin them up internally; consumers (CLI, mado) call these directly on a worker thread.