This site is driven by two keys, like the machine it came from. Reading: j and k scroll, d and u move half a page, gg goes to the top, G to the bottom, H and L switch windows, ? opens the help. Space is the Neovim leader and handles content: Space then h home, r research, p projects, g gear, a about, / tags, or Space then a digit to jump to that window. Home is the tmux prefix and handles windows: Home then c opens a terminal, Home then & closes a window, Home then space goes to the next one. While focus is on the keyboard, h j k l move between keys and Enter opens one.

ResearchR AboutA Gear — G for gear — keyboard, terminal, editor, homelab.G
    ProjectsP Tags — / as in vim: search./
    ×
    Menu

    tmprl: A Temporal Client for the Keyboard

    A terminal client for Temporal, aiming at parity with the web UI. Four days old: the gRPC layer exists, the TUI does not. This is what it is honest to claim at that stage.

    rust temporal grpc tui in-progress
    View Source

    There is no TUI yet. That belongs in the first line rather than in a footnote, because a repository named after a terminal client that cannot draw a terminal interface will otherwise waste somebody’s afternoon.

    What exists is the gRPC access layer — connecting, profile handling, and the four RPCs the interface will be built on — plus design documents for everything else. If you need a working Temporal TUI today, galaxy-io/tempo is Go and tview and does the job now. That is in this project’s README too, at the top, for the same reason.

    The part that is real

    connected  profile=default  namespace=default

namespaces (2):
  - default
  - temporal-system

total workflows in `default`: 1

workflows (1 shown):
  Running    Demo    demo-1

history of demo-1 (2 events):
     1  WorkflowExecutionStarted
     2  WorkflowTaskScheduled

    Four RPCs behind thin wrappers — ListNamespaces, CountWorkflowExecutions, ListWorkflowExecutions, GetWorkflowExecutionHistory — with an integration suite that pins those contracts against a live server. You can read data. You cannot yet browse it.

    No connection config of its own

    tmprl reads the same profiles the temporal CLI reads: the same ~/.config/temporalio/temporal.toml, the same TEMPORAL_* environment variables, the same precedence of flags then environment then file.

    That is the whole design decision, and it is worth stating as one. A new tool that invents its own connection format asks everyone to describe their cluster a second time, in a second place, that then drifts from the first. If the CLI can reach your cluster, this can.

    Tests that skip, and CI that refuses to

    The integration tests skip when no server is reachable, so cargo test stays green on a machine that has never run Temporal. That is the right default for someone cloning the repo to look around.

    It is the wrong default for CI, where a skip and a pass look identical in the output. TMPRL_REQUIRE_SERVER=1 turns the skip into a hard failure, and CI sets it — so a broken connection layer cannot ride through as a green build.

    protoc, and an error that reads like something else

    temporalio-protos compiles Temporal’s protobufs from source at build time, so protoc is required. Without it the build fails inside a build script with Could not find protoc.

    That message is easy to misread as a network problem, because it appears in the middle of a long dependency build and looks like a fetch that failed. It is not. It is a missing local binary, and the README says so in the sentence directly after the error, where somebody looking at that error will actually be.

    Debug info is off in the dev profile for a related reason: the dependency tree is 228 crates, the generated protos dominate it, and with debug info on target/ runs to several gigabytes. cargo build --profile dbg exists for when a debugger is genuinely needed.

    What it is meant to become

    A modal, keyboard-driven client covering what the web UI covers — workflows, histories, schedules, batch operations, task queues, workers, nexus endpoints — plus the things a browser cannot do: following a running workflow like tail -f, piping payloads through jq, yanking to the system clipboard, and diffing two runs side by side.

    The crate split is already drawn for that, and only the first one exists:

    crates/tmprl-client   all network IO — gRPC, TLS, profiles     ← the only crate that exists
crates/tmprl-core     domain logic — history, queries, keymap   (planned)
crates/tmprl-ui       window tree — splits, tabs, focus         (planned)
crates/tmprl-tui      ratatui rendering and input               (planned)

    The point of the split is that the hard logic — reconstructing histories, compiling visibility queries, diffing runs — lands in a layer needing neither a terminal nor a server to test.

    docs/ARCHITECTURE.md and docs/INTERFACE.md describe that code, and both say section by section which parts are not written. A design document that reads as though the thing exists is worse than no document, because it is the one artefact a reader trusts to tell them where they are.

    Whether it should exist

    tempo already works. This differs in intent — full web-UI parity including batch operations, nexus, worker deployments, reset and codec servers, and a modal editor model rather than a menu.

    Whether that difference is worth a second implementation is a fair question, and the answer is not in yet. The roadmap runs M0b through M7; one of eight milestones is done.

    id en
    rss gh in