Trau 2.0: the hub
A CLI grew a web app, and then the web app ate the product. Why the loop needed a persistent surface — and what stays terminal-first.
By The trau herd
Trau started as a terminal program: point it at a repo, label a ticket, walk away. That story still works. But three things kept not fitting in a TUI: run history you can trust after a restart, triaging half-formed ideas into buildable tickets, and keeping an eye on more than one repo at a time.
From trau serve to the product
v1.6 shipped trau serve as an embedded status view — a board, live transcripts, a costs page. Over the next ten releases it grew a backlog, a queue, a repo switcher, and its own design language. In v2.0 the hub becomes the primary surface: registered repos, run history, and internal issues now live in a durable machine-local database, and every screen scopes to one repo or to all of them.
The Inbox: idea in, ticket out
The biggest new muscle is the Inbox. Drop in a raw idea and an agent runs an Interview — one question at a time — until the idea is a ticket the loop can actually build: acceptance criteria, non-goals, the works. Impatient? Ask ahead batches the remaining questions. The PRD planning module this replaces is gone; the Interview is how ideas enter the herd now.
The Run ledger
Every tracked run lands in the ledger, newest first, bucketed by what it needs from you: needs attention, active, stopped, merged. Run detail shows per-phase cost, the verify verdict, and the handoff brief — the receipts for every merge the loop makes.
What stays terminal-first
- The engine is unchanged: cold, isolated phases; fresh-eyes verify; bounded self-heal.
- Bare trau in a repo still opens the full TUI — and autostarts the hub for you.
- The hub is machine-local by design: loopback-first, token-gated beyond it, one hub per machine. No accounts, no cloud.
Next up: parallel tickets in local worktrees, and splitting verify into evidence-gathering and cold grading. The full changelog from v1.1 to v2.0 is on the changelog page.