The previous draft was mixing two layers (transport leaf and stream_type
multiplexing) and including side-topics (WsBidiStream home, etc.) that
weren't load-bearing, which confused agents into conflating tokio::io::
join/split (ADR-092's layer, settled) with the demux/mux stream_type
layer (this doc's layer, in progress).
Rewrite to be focused:
- Layering section upfront separates transport leaf (ADR-092, settled),
multiplexing (this doc), and channel protocol (ADR-072/073, settled).
The two questions that got conflated are explicitly separated.
- Drop the ADR-092 recap (it's in the ADR, not this doc's concern).
- Drop the 'five abstractions' table (ADR-092's framing, not this doc's).
- Drop the WS open question (irrelevant to multiplexing).
- Record that POC 1 (stderr split/recombine) is already answered by the
existing POC evidence: per-stream_type independent demux/mux (verified
in demux.rs:91-109, 161-181 and mux.rs:58-63, 152-177) means the
'unused write half' is an idle mpsc channel, not a wart. The mod-2
framing is trivially clean. No new POC needed.
- The mod-2-vs-mod-3 question is settled by existing evidence; ADR-093
is ready to draft.
- The one open question that benefits from a POC is POC 2
(TTY-direct-as-channels, for the format-convergence / retire-5-byte
call). POC 3 (recursive composition) is low leverage, deferred.
- The TTY control channel flaw is flagged as implementation-lag, not a
design question (fix specified in ADR-077, subsumed by mod-4 instance
framing).
This drops the scope to what the doc is actually about: the stream_type
convention and the TTY/channels convergence.
glm-5.2
b5397f61aa