The TUI isn't a demo

Most agent tools ship a web dashboard as the primary interface and a terminal UI as an afterthought — a single-screen status view with two keybindings, released late, maintained reluctantly.

opentine goes the other way. The TUI is the primary interface. The web dashboard is a mirror of it, for when you want to share a link.

The reason is specific to agent runs: you are always looking at them in the same context you built them in. Your terminal. Your editor. Your project directory. Switching to a browser tab to inspect a run that your CLI just produced is friction measured in seconds per lookup, many times per hour. It adds up.

Here is what the TUI actually does, which is not what most "TUIs" do:

Run list with live follow. The terminal workflow starts with `tine ls` and `tine show`: runs are listed by ID, and the selected run's graph is rendered directly in the shell. You inspect the agent step-by-step without opening a separate dashboard.

Step inspection in three panes. When you hit enter on a step, the right pane splits again: inputs, outputs, and metadata. Arrow keys navigate between steps. J and K move between siblings. H and L traverse parent/child. It is literally vim for run trees.

Fork-from-here. Select a step, hit F, type a new prompt in a modal, hit enter. A new run is queued. Switch back to the run list and watch the fork execute. The whole cycle — inspect failure, identify step, fork with fix, watch replay — takes under 15 seconds.

Diff mode. Select two runs with space, hit D. You get a side-by-side diff of the two run trees: which steps are shared (via content address), which diverged, where token counts changed. This is the feature I use most. It's also the feature that is genuinely painful in any web UI because you want it on wide monitors with monospace fonts.

Export to .tine. Hit E on any run. It writes the full content-addressed tree to a file in your project. Now you can commit it, share it, attach it to a bug report.

Every one of these is a keybinding. Every keybinding is documented by `?` in the TUI itself. There is no tutorial video. There is no onboarding modal. You open it, you see the list, you learn it in about four minutes.

The web docs exist as a reference, but the working interface is the CLI. Use saved `.tine` files when you want to send context to a colleague. Use `tine show`, `tine verify`, and `tine diff` when you want to stay close to the project directory.

A TUI shipped as the primary interface forces certain choices. It forces the data model to be navigable with arrow keys — which means the run tree has to be actually tree-shaped, not flattened into a timeline. It forces the step inspection to fit in three panes — which means step inputs have to be structured, not blobby JSON. It forces the fork loop to be keypress-fast — which means the fork machinery has to be local, not routed through an API.

In other words: optimizing for the TUI as the primary interface made opentine's internals better. That's the real argument for doing it.