alknet/tasks/architecture/oq-44-tty-modes-use-case.md at c6eef730e4d0f81fbf0d09472ccbb0cd2ddd40e3

alkdev/alknet

0 Fork 0

Files

T

glm-5.2 df5d04af1d tasks(arch): adopt taskgraph for architecture work — blocker tasks for deferred OQs, level mapping, status fixes

Establishes the tasks/architecture/ blocker-task half of the Safe Exit
protocol. Each deferred OQ now has an external-trigger tracker task
representing its unblocking condition, and the OQ's Blocked on field names
the tracker task ID — closing the gap where the deferral field existed but
the task-graph half was unenforced.

Changes:
- Add 6 external-trigger tracker tasks for the deferred OQs (OQ-09, 10, 32,
  41, 44, 46) under tasks/architecture/, tagged [external-trigger, deferred-oq]
- Add structured Blocked on field to OQ-09 and OQ-10 (previously used legacy
  'deferred' status with the reason in the Resolution prose); index now
  surfaces all 6 deferred OQs with concrete conditions, no placeholders
- Document the architecture-task level mapping (level: implementation for
  ADRs/specs, decomposition for spec-to-ADR breakdown, planning for backlog
  seeding, research/review direct fits) and the deferred-OQ blocker-task
  pattern in docs/sdd_process.md
- Mark architecture/safe-exit-blocker-task-mechanism and
  architecture/oq-09-10-blocking-conditions completed (implemented by this pass)
- Fix 4 pre-existing ADR-050 implementation tasks: status: done → completed
  (taskgraph enum is 'completed', not 'done') — taskgraph validate now passes
  for all 100 tasks

2026-07-06 16:34:01 +00:00

1.9 KiB

Raw Blame History

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

name

status

depends_on

scope

risk

impact

level

Description

External-trigger tracker for OQ-44 (Terminal Modes / TTY modes). This is not actionable work — it tracks whether a concrete deployment has emerged that needs to set TTY modes (echo, raw, canonical, etc.) on a PTY beyond the backend's defaults.

Trigger condition

A concrete deployment that needs to control TTY modes beyond the defaults the backends already provide (portable_pty, docker tty: true, russh pty_request all have defaults that work for the common terminal case). The modes field in TerminalParams is serde_json::Value (reserved as {} in v1) for when this arrives.

What unblocking looks like

When a mode-control use case arrives:

Mark this task status: completed.
Move OQ-44 from deferred(scope) to open.
Specify the modes JSON shape (SSH's pty_request carries TTY modes as a packed bitmask; the Rust analogue extends the modes field). Adding mode control is additive (extend the modes JSON shape) and does not break downstream — the architectural commitment is two-way-door.

Why this is a task, not just an OQ field

The OQ's Blocked on: field in open-questions.md is the human-readable visibility surface. This task is the machine-readable half: it lives in the task graph so taskgraph tools can reason about it, and so downstream work that depends on TTY mode control can declare depends_on: [architecture/oq-44-tty-modes-use-case].

Verification

This task is "completed" when a concrete mode-control use case is documented and OQ-44 has been moved to open.

1.9 KiB Raw Blame History