From 45fb7efbfc9b2c0552a8f6468cc1ab72d45f8b5f Mon Sep 17 00:00:00 2001 From: "glm-5.2" Date: Sun, 5 Jul 2026 13:08:29 +0000 Subject: [PATCH] docs(research): remove hedging language from alknet-ssh and alknet-tty research MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - alknet-ssh: remove paragraphs describing old hedging problem in channel decomposition section and DP-4 — state the insight directly - alknet-tty: replace 'defer for v1' / 'reserved for future use' with 'not needed for the current scope' in OQ-TTY-02 --- docs/research/alknet-ssh/phase-0-findings.md | 14 ++++---------- docs/research/alknet-tty/phase-0-findings.md | 7 ++++--- 2 files changed, 8 insertions(+), 13 deletions(-) diff --git a/docs/research/alknet-ssh/phase-0-findings.md b/docs/research/alknet-ssh/phase-0-findings.md index cde27db..fd225ae 100644 --- a/docs/research/alknet-ssh/phase-0-findings.md +++ b/docs/research/alknet-ssh/phase-0-findings.md @@ -71,14 +71,9 @@ copied and also since rewritten. ## The Channel Decomposition (Core Insight) -The initial research framed alknet-ssh's scope as a single massive v1: server -+ client + SOCKS5 + bidirectional port forwarding, all at once. That framing -made the crate feel unmanageably large and produced hedging language -("v1 default," "can be revisited later," "two-way door, decide later") that -proposed shipping non-functional or half-built versions. This revision -dissolves that problem by recognizing that **SSH's channel multiplexer is the -natural decomposition point**, and the features that felt like a massive scope -are layers that stack on top of it — each functional on its own. +SSH's channel multiplexer is the natural decomposition point. The features +that make up alknet-ssh are layers that stack on top of it — each functional +on its own. ### How SSH channels work @@ -427,8 +422,7 @@ choice in the ssh spec. ### DP-4: Client + forwarding + SOCKS5 + SFTP scope — reframed as layer order *(Recommended: one-way door on "all in alknet-ssh"; two-way door on extraction)* -The initial research framed this as "is all of this in v1?" — a massive scope -question. The channel decomposition dissolves it. The question is not "do we +The channel decomposition answers the scope question. The question is not "do we ship it all at once" but "what's the build order, and are all the layers in alknet-ssh?" diff --git a/docs/research/alknet-tty/phase-0-findings.md b/docs/research/alknet-tty/phase-0-findings.md index 5fc4c8f..a6fd9d3 100644 --- a/docs/research/alknet-tty/phase-0-findings.md +++ b/docs/research/alknet-tty/phase-0-findings.md @@ -546,9 +546,10 @@ channel and PTY-specific paths. extension informs the decision. - **OQ-TTY-02 (terminal modes)**: SSH's `pty_request` carries TTY modes (echo, raw, canonical, etc.) as a packed bitmask. Does alknet-tty - support these, or defer to the backend's defaults? Likely defer for v1 - (the common case is "default terminal modes"); the `modes` field in - `TerminalParams` is reserved for future use. + support these, or use the backend's defaults? The common case is + "default terminal modes" — the `modes` field in `TerminalParams` is + reserved for when a concrete use case requires mode control. Not + needed for the current scope. - **OQ-TTY-03 (flow control)**: the chunk format has no windowing (QUIC provides flow control on the bidi stream). Is this sufficient for high-throughput stdout (e.g., `cargo build` output)? QUIC's per-stream