- plan file status → closed; wave-5 row → published; §Plan closure
added (the freeze inventory one-way, the still-booked upstream asks)
- w5-publish task: the checklist record (manifest sanity, the full
verification set, dry-run, package list) + status, over the green
review-wave-5 verdict
- Seven task files under tasks/implementation/: w5-decline-matrix,
w5-e2e-server, w5-e2e-client, w5-fuzz-harness, w5-release-readiness,
review-wave-5 (pure review), w5-publish (over the gate)
- Four independent implementation tasks (disjoint files) over the
landed waves; release readiness over all four; the gate stays a
pure review; the publish is its own task (the alkgit pattern)
- Interpretations recorded: gate-then-publish split, e2e vehicle
placement, matrix-runner vehicle, fuzz exposure shape, the
crate-qualified alkssh-v0.1.0 tag, no version bump (0.1.0 is the
manifest value)
- Plan doc: wave-5 row -> decomposed + the decomposition record
Verification: taskgraph validate (42 tasks) clean
Eight implementation tasks + the gate under tasks/implementation/,
folding the wave-3 gate's four booked findings in as dedicated tasks
(the gate's own disposition — wave-4 material, not wave-3 backports).
Hardening set (server-side, independent of the client chain,
scheduled first as cheap remediation):
- w4-git-exit-close: booked item 1 — the git row's status-before-close
by construction (the seam/shape decided + recorded in-task; the
saturated-buffer scenario pinned on the wire)
- w4-channel-not-held-rows: booked item 2 — the guard's wire rows on
git/tty pipe/shell, per build (test-only)
- w4-tty-coverage: booked item 3 — the channel_close-fired cancel
path + the Closed/Break no-exit-chunk rows + the write_all
no-deadline known-limit record
- w4-router-collision: booked item 4 — the ListenRouter
token-collision fail-closed pre-check
Client chain (sequential logistically — one client Handler impl):
- w4-dial: the russh client stack + the connection handle + the
client Handler skeleton at fail-closed defaults, over an in-process
fake-sshd server double
- w4-op-rows: exec/pty, direct-tcpip, git exec over the shared
grammar, the sftp client-side decline — the POC-3 §D.3 mechanics
- w4-reverse-listen: the -R leg — forward requests + the acceptor
registry + late-install (the wave's highest-risk task)
- w4-lifecycle: the OQ-12 primitives (cancellable handles, clean
disconnect, no reconnect policy)
review-wave-4 depends on all eight. The gate's item 5 (upstream asks)
stays booked with its owners — no task. Plan wave-4 section carries
the decomposition record + four flagged interpretations; wave table
status updated.
Verification: taskgraph validate ✓ (35 tasks)
Six implementation tasks + the gate under tasks/implementation/,
chained sequentially (the mappings replace stubs in the same Handler
impl and share the decline-matrix test binaries):
- w3-seam-config: the serve-config's per-feature seam handles
(alktty backends/ownership/selector; the alkgit quartet/pipeline/
push-options flag) + the optional sibling deps — wave 3's first
course correction to the wave-1 config surface
- w3-decline-tracing: the wave-2 gate's booked finding — the
decline/serve-path tracing vocabulary, landed before the mappings
- w3-git-mapping: the full exec grammar replaces the wave-2 probe +
the serve_duplex_resolved dispatch + the store-and-take handoff
- w3-tty-session: the translation bridge + the exit-derivation
contract (rules 1-6, the signum table)
- w3-tunnel-direct: the route-1 bridge (accept only after the fabric
open succeeds) + set_identity propagation + the capacity-across-
fabric-window mechanics
- w3-tunnel-listen: the -R listen flow + the forwarded-tcpip data
leg (the POC-untested leg; the stop-and-book provision)
- review-wave-3: the gate
The plan carries the wave-3 decomposition record with four
interpretations flagged for the gate (the serve-config course
correction, the already-discharged server-side sftp bullet, the
w3-tunnel-listen open mechanics, the booked-items' wave-3 homes).
taskgraph validate: 26 tasks, clean.
Sibling pins verified against crates.io at decomposition time:
alktty 0.8.1 / alkgit 0.1.0 / alktunnels 0.4.1 / alkcall 0.10.1.
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.
The format contract (ADR-004 decision 1) is SHA256: + unpadded
standard base64 — not url-safe. The ssh-key re-export and ssh-keygen
both emit the +/ alphabet (visible in the recorded fingerprints); the
'url-safe' wording in ADR-004/auth.md/plans/implementation.md and the
POC-1 §1 finding was a misnomer. Wording corrected; the parity
contract itself unchanged on both sides.
glm-5.3-flash