glm-5.3-flash
3a447273a8
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)
66 lines
2.1 KiB
Markdown
66 lines
2.1 KiB
Markdown
---
|
|
id: architecture/oq-tn-14-tracker
|
|
name: "OQ-TN-14 follow-through: unix lands with local v1; stdio stays alktty's"
|
|
status: pending
|
|
depends_on: []
|
|
scope: single
|
|
risk: trivial
|
|
impact: isolated
|
|
level: research
|
|
tags: [architecture, external-trigger, unix, stdio, alktty]
|
|
---
|
|
|
|
## 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:
|
|
|
|
1. 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`.
|
|
2. 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. |