# Transport Seam
`transport` defines a message-shaped boundary between transport-agnostic channel
logic and transport backends. Today the abstract-socket daemon consumes it; a
Binder backend can later. Generic over the domain command and reply types.
## Types
- `TransportEvent<C, R>` — the channel's event vocabulary:
- `Command { cmd: C, calling_uid, reply: ReplySink<R> }` — an inbound
command with the caller's identity and a one-shot reply target.
- `WatcherClosed(WatcherId)` — a watcher's channel closed.
- `WatcherDied(WatcherId)` — a watcher's process died.
- `ReplySink<R>` — a one-shot reply target, consumed exactly once. `send(reply)`
delivers or reports the error.
- `WatcherId` — a persistent, long-lived watcher identity (u64).
- `WatcherSink<U>` — a persistent push target for watcher updates
(`push(&U)`).
## Design
Client (`ReplySink`, one-shot) and watcher (`WatcherId`, long-lived) are
distinct concepts. A watch registration is itself a command, so watcher-registry
mutation is single-owner by construction: the registry changes only inside the
handler for the register/unregister commands, never from a concurrent push.
The seam keeps channel logic independent of the wire: a channel processes
`TransportEvent`s and pushes updates through `WatcherSink`s, while the backend
(orchestrating daemon) owns sockets, connection lifecycle, and peer identity.