terminal-uxlisted

# Terminal UX How a terminal program should behave. Two different things live here and their rules diverge: - **CLI**: a command that runs, prints, and exits. No persistent screen. State is communicated by printing what changed. - **TUI**: a full-screen interactive app that owns the terminal until it quits. A grid that redraws. Every rule below says which it applies to. A CLI rule does not automatically hold for a TUI, and the sources differ: `clig.dev`, the 12-factor CLI writeup, GNU, and POSIX are CLI-first, while the TUI material comes from ratatui, Bubble Tea, Textual, and accessibility practitioners. How solid a rule is: - **convention**: documented in a widely-adopted guide or standard. - **house style**: one project's stated choice. Reasonable, not universal. - unmarked: reasoning by analogy from graphical UI, with nothing behind it. Weigh it lower. Terminal accessibility gets its own file, `references/accessibility.md`. There is no WCAG equivalent for terminals, so nothing there is a conformance floor. Read it anyway: it holds the one rule most likely to make a TUI unusable for someone. --- ## 1. Output Streams **CLI, convention.** stdout carries the program's actual output. stderr carries everything about the run. **Do:** - Put primary output, the thing another program would consume, on stdout. - Put logs, warnings, errors, and human-watched progress on stderr, so a pipe does not swallow them and they do not corrupt the data stream. - Surface a subprocess's