Roadmap question: support herdr-core as an optional backend?

[odfalik]

Herdr now has two official, separate products alongside the existing TUI:

• herdr-core, a headless terminal runtime with an OpenRPC API
• herdr-app, the native desktop client built on that runtime

The existing Herdr TUI remains supported. The official FAQ says the TUI and core do not share agents, so this would not be a transparent socket swap or a live migration of running sessions.

Core already exposes much of what an Ovis backend needs: terminals, input, status, labels, ordered events, remote machines, and framed attach streams. Its API is still marked preview (generation 1, version 0.x), with an additive compatibility policy within that generation.

Important external-client contracts are still being discussed upstream:

• herdr-core#15: a producer-owned session or resume identity that can bind a terminal to its native transcript
• herdr-app#43: a supported way for another client to read spaces, tabs, and ordering without depending on the app's opaque document format

Would herdr-core support fit Ovis's roadmap? If so, which direction would the maintainers prefer?

1. Add core as an optional second backend while keeping today's Herdr TUI backend.
2. Plan a later migration after the session-identity and app-structure contracts settle.
3. Keep core support in a separate adapter or companion until its API matures.

I would also appreciate guidance on continuity and scope:

• Since TUI and core do not share agents, should Ovis present them as separate runtimes rather than offer a migration flow?
• Which generation-1 APIs are considered ready for an external client to depend on now?
• Should an eventual adapter live in Ovis itself, an extension, or a separate companion project?

This question is about the official herdrdev/herdr-core and herdrdev/herdr-app. It is separate from the unaffiliated penso/herdr-gpui project.

I am asking before building a port so the first prototype follows the intended boundary rather than committing Ovis to an unsupported app document or agent-specific session discovery.

[devswha]

Thanks for the thoughtful write-up, @odfalik. We went with your option 1: herdr-core is an optional second backend, and the Herdr TUI backend stays the default.

It's on main now and lands in the next release. Start the server with OVIS_RUNTIME=herdr-core (Linux and macOS for now) and Ovis:

• shows the terminals of the Herdr app and of herdr-core itself (feat(server): show the Herdr app's terminals with OVIS_RUNTIME=herdr-core #2442, thanks @nahwan-kim)
• streams them over the server's own hc connection, without an extra hc attach or PTY host per pane (feat(herdr-core): stream core terminals over the server's hc connection #2447)
• creates and closes workspaces, tabs and panes and starts agents, labeled so the Herdr app picks them up (feat(herdr-core): create and close workspaces, tabs and panes, and start agents, on herdr-core #2449, fix(herdr-core): start agents only in a real shell, keep labeled terminals' ids, resume with the core's environment #2456)
• hides the actions core doesn't support, and shows "done" only when the program reports it itself over OSC 7501 (feat(herdr-core): offer only what herdr-core can do on its workspaces, tabs and panes #2451, fix(herdr-core): show done only when the program itself reported its turn finished #2455)
• is checked in CI against a real, pinned hc (test(herdr-core): check the hc client against a real hc, in CI on a pinned hc 0.1.14 #2445)

On continuity: since the TUI and core don't share agents, Ovis treats them as separate runtimes, chosen when the server starts. There's no migration flow.

We're still looking into more ways to make use of herdr-core. Personally, I'd love a single TUI that brings the two together. If there's anything else you'd like Ovis to do on core, please let us know here.