alkssh/tasks/implementation/w2-loopback-harness.md at 18ef55c60dc20ba634409d9343ece236cc71048e

alkdev/alkssh

0 Fork 0

Files

T

glm-5.3-flash 18ef55c60d docs(tasks): decompose wave 2 — the server stack

Six implementation tasks + the gate under tasks/implementation/,
chained sequentially (the auth hooks, dispatch, and channel cap all
edit the same per-connection Handler impl):

- w2-server-mount: SshAdapter::handle mount + russh Config
  construction from the serve-config (honest advertisement, host-key
  decrypt-at-construction, the Limits knob mapping) + the Handler
  skeleton at fail-closed defaults
- w2-auth-bridge: the ADR-004 dispositions (ed25519-only explicit
  decline, fingerprint-only resolution, explicit declines for every
  non-publickey method)
- w2-loopback-harness: the in-process client/server contract-test
  vehicle over the wave-1 doubles
- w2-dispatch-decline-core: parse-only dispatch + the fail-closed
  decline core, contract-tested per feature build
- w2-spawn-return: the structural constraint pinned by test + the
  exit-reporting mechanics via the cloned Session::handle()
- w2-bounded-resources: the in-crate concurrent-channel cap at the
  handler surface
- review-wave-2: the gate

The plan carries the wave-2 decomposition record with four
interpretations flagged for the gate (skeleton-level git probe,
declining routing stubs, the adapter error surface, the harness
transport choice). taskgraph validate: 19 tasks, clean.

2026-10-28 07:38:04 +00:00

3.2 KiB

Raw Blame History

id, name, status, depends_on, scope, risk, impact, level

name

status

depends_on

scope

risk

impact

level

w2-loopback-harness

Wave 2 — the loopback harness (in-process client/server test pair)

pending

w2-auth-bridge

w1-test-doubles

moderate

medium

phase

implementation

Description

Land the in-process client/server test pair every later contract test runs through — the decline matrix, every mapping's contract tests (wave 3), and the client-direction smokes all drive the crate through this harness. In-memory doubles from wave 1; real-tool smokes ride the mapping waves (wave 3+) and the e2e wave (wave 5).

Server side — the SshAdapter from w2-server-mount over an in-process transport. The transport choice (tokio duplex pair vs 127.0.0.1:0 TCP loopback) is pinned here — both work with run_stream/russh's client connect; decide on determinism and portability and record the choice.
Client side — a russh client driven directly (the wave-4 dial surface does not exist yet; the harness builds the russh client config from the doubles): in-memory key from the ed25519 fixtures (FIXTURE_KEYS), the MemHostKeyPolicy double with the permissive test posture (with_default(true) — the accept-all posture exists only as a test choice, never a crate built-in), the keepalive posture from Limits.
Harness helpers — the vocabulary the contract tests speak: authenticate with a fixture key (and observe auth failure shapes), open a channel type (and observe the open-failure reason), send a session request (and observe success/failure), await exit-status / close. Helpers stay thin — the russh client API is the vocabulary; the harness removes boilerplate, not semantics.
Convention — lives with the wave-1 doubles under tests/common/ (or a sibling harness module — same convention, decide and record); documented as the contract-test vehicle for the crate.

The harness's first consumer is its own acceptance test: a full in-process connect → authenticate (fixture key through MemIdentityProvider) → authenticated-session observation, proving the wave-1 doubles work live through the wave-2 stack.

Acceptance Criteria

In-process server/client pair connects and authenticates end to end (fixture key → MemIdentityProvider → authenticated session) with no TCP port dependency (or the TCP choice recorded, if taken)
Harness helpers cover: auth (success + failure observation), channel open (success + open-failure reason), session requests (success/failure), exit-status/close observation
The transport choice and module placement are recorded
The harness is documented as the contract-test vehicle; the wave-1 doubles are exercised live through it
cargo test, cargo clippy --all-targets -- -D warnings, cargo fmt --check pass

References

docs/plans/implementation.md §Wave 2 (the loopback-harness bullet)
docs/architecture/mapping.md §Decline matrix (the rows the harness will drive)
docs/research/poc-1-auth-bridge.md (the decline-observability facts the helpers must be able to observe)
tests/common/mod.rs (the wave-1 doubles this harness drives)

Notes

To be filled by implementation agent

Summary

To be filled on completion

3.2 KiB Raw Blame History