TacidOS
DevelopersGitHub

Decision 0020

The TUI ships first and is complete; the daemon is headless-first

Architecture decision record 0020: The TUI ships first and is complete; the daemon is headless-first

Status
Accepted
Date
2026-09-03

Context

Grok’s Q-5 and Q-14: GUI in year one? Daily driver or appliance? “Any device” means servers, boards and serial consoles as much as laptops.

The three plans

  • Grok: the TUI is the desktop; boot to a prompt in eight seconds; readable at 80×24.
  • Fable: both a ratatui TUI and a GTK4 panel in 0.1, thin clients with enforced parity.
  • Codex: a Quickshell desktop as Phase 1; a CLI that is first-class, not an afterthought.

Decision

tacid with no arguments is a full ratatui client, readable at 80×24 in 16 colours on a serial console, with modal keyboard approvals and deterministic : verbs. It ships in Phase 2, before the graphical shell (Phase 4), and it is complete rather than a fallback. The daemon is headless-first: the same nervous system runs on a server, a board and a laptop, with the shell as an optional layer. Parity between the TUI and the shell is enforced by the protocol carrying UI state (ADR-0005). Both daily driver and appliance are profiles of the same system.

Consequences

  • The ISO with only the TUI is a complete product (Phase 3), which is why it precedes the GUI.
  • Every feature is designed for the protocol first and rendered twice.

Alternatives rejected

  • GUI first: delays the self-updating body and excludes headless bodies.
  • TUI only: not a daily driver for most builders.