alktunnels/tasks/architecture/oq-tn-14-tracker.md at f315b0e0ca7829da96b09fef87366358ee25a56f

Files

T

glm-5.3-flash 3a447273a8 docs: resolve OQ-TN-14 — unix in via local, stdio out (alktty owns process stdio)

Split the last open substrate-placement question:

- Unix: ships with the local feature v1 (dial_unix — same halves
  shape as TCP; the wire enum already carried unix per ADR-001;
  the params task's schema list includes all three values)
- Stdio: OUT of scope — a spawned process's stdin/stdout/stderr IS
  alktty's pipe mode (LocalTtyBackend + tokio::process + Stdio::piped,
  alktty tty-local.md): three multiplexed logical streams + the
  exit-code control chunk (alktty ADR-004) + signal forwarding
  (REQ-TTY-02). A stdio bridge here would be alktty's runner mode
  with the terminal stripped out — a strictly worse duplicate that
  also drops the semantics that matter (a byte tunnel has neither
  exit codes nor signals). Remote command execution composes via
  alktty on the same channels substrate.

Updated: open-questions.md OQ-TN-14 (resolved), overview.md feature
gate + deps + OQ summary, producer.md OQ ref, OQ-TN-10 promotion
(#3 split), phase-0-findings + both POC summaries' resolution notes,
params task (schema enum includes unix), local-socket-halves task
(unix ships, stdio does NOT — with the composition rationale),
oq-tn-14-tracker task repurposed (boundary-maintenance: re-opens only
if a consumer needs stdio-without-process-semantics — which would
need its own ADR, or if the alktty/alktunnels boundary needs
sharpening).

Verified: taskgraph valid (12 tasks, no cycles)

2026-09-07 19:44:03 +00:00

2.1 KiB

Raw Blame History

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

name

status

depends_on

scope

risk

impact

level

Description

OQ-TN-14 is resolved (open-questions.md, 2026-09-07): unix ships with the local feature v1 (tunnels/local-socket-halves); stdio is OUT of scope — a spawned process's stdio is alktty's pipe mode (exit codes + signals are tty semantics, not tunnel semantics); remote command execution composes via alktty.

This task stays open as the boundary-maintenance tracker (research level — not implementation work). It re-opens the question only if a concrete consumer demonstrates the resolved posture is wrong:

A consumer needs stdio tunneling with NO process semantics (no exit code, no signals) — e.g. piping an already-running long-lived process's existing stdio. That is a different resource shape (the pipe IS the resource, no dial); it would need its own ADR, not a silent addition to local.
A consumer reports confusion about when to use alktunnels vs alktty for a stdio-like flow — the composition boundary in OQ-TN-14 needs sharpening in the docs, not code.

If neither arrives, this task closes with the implementation phase.

Work

Re-read OQ-TN-14 + alktty's tty-local.md §pipe mode at triage; confirm the boundary held (no stdio-shaped resource got registered as a tunnel resource).

Verification

Tracked (this file existing and being reviewed at triage time IS the tracking mechanism — no code or doc change is expected unless a boundary condition above arrives)

Out of scope

Implementing stdio bridging (would need its own ADR per the conditions above)

References

docs/architecture/open-questions.md OQ-TN-14 (the resolution)
alktty docs/architecture/tty-local.md §pipe mode (the owner of process stdio)
docs/sdd_process.md §Deferred OQs and the blocker-task half

Notes

Agent fills during implementation.

Summary

Agent fills this on completion.

2.1 KiB Raw Blame History