The terminal isn't a demo

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

opentine goes the other way. The current beta's working interface is the CLI. A richer TUI can sit on top of it, but the primitive workflow starts in the terminal.

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 terminal workflow actually does:

Run list and graph inspection. Start 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 model steps, tool steps, errors, costs, and durations without opening a separate dashboard.

Trust checks. `tine verify` recomputes the artifact checksum before you trust a file copied from another machine. It is not a signature, and the CLI says exactly what it is: a digest check on the saved artifact body.

Fork-from-here. `tine fork failed.tine --from-step 3 --save retry.tine` gives you a branch that preserves the known-good prefix. Nothing has to be routed through a hosted service before you can try the next move.

Replay. `tine replay failed.tine --mode cache --save replayed.tine` writes a cached replay artifact. `--mode rerun` is deliberately stricter: it requires a native runtime or an explicit external harness, because blindly re-executing side-effectful tools is how replay becomes a footgun.

Diff. `tine diff old.tine retry.tine` shows the common ancestor and the steps only present on each side. That is the core loop: inspect, fork, replay, diff.

This is why the CLI matters. It forces the data model to be local, serializable, and inspectable. A dashboard can make that nicer, and a dedicated TUI can make it faster, but neither should invent private state that is not in the .tine file.

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

A terminal-first workflow forces certain choices. It forces the run graph to be understandable without a service. It forces replay and resume claims to be explicit. It forces fork and diff to operate on files, not opaque hosted sessions.

In other words: optimizing for the terminal makes opentine's internals better. That's the real argument for doing it.