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

0 Fork 0

Files

T

glm-5.3-flash 0ceecf582b docs: remove em dashes from repo prose and forbid them going forward

- Rewrote the remaining em dashes outside docs/reviews/ (preserved as
  historical record, matching the alktty precedent): tests/ (313),
  fuzz/ (34 plus one shell comment), tasks/ (671 plus 12 kept in
  fences), docs/research + sdd_process + plans (525 plus 25 in
  fences), docs/architecture/overview.md fence labels (13), README,
  CHANGELOG, AGENTS.md, fuzz/README.md (176), and the
  .opencode/agents prompts (110)
- Rewrote fenced content too: ASCII tree and module-map label
  separators, Rust snippet comments, and template placeholders; wire
  data, JSON/BAST examples, and transcripts survive verbatim
- Rewrote 6 assert/expect message literals in tests/ and 2 format
  strings in fuzz/shared/src; no test data changed
- Added Project Convention 18: no em dashes in prose (doc comments,
  markdown including docs/ and tasks/, agent prompts, commit
  messages); fence content rule, en-dash clause rule, and the
  no-spaced-hyphen prohibition follow alktty's convention 15

Follows 6b20924 (src doc comments) and cd0afe0 (docs/architecture).

Verification: cargo test (141 pass); cargo clippy --all-targets -D
warnings; cargo fmt --check; cargo doc --no-deps; wasm check and
clippy for wasm32-unknown-unknown with -D warnings; em dash grep over
the repo returns matches only in docs/reviews/

2026-11-03 14:12:46 +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