Openrig Herdr

openrig-herdr

OpenRig decides which agents make up a view (a rig, a pod, a mission, a slice, or a saved group); herdr renders the pixels. A view opens as live, interactive terminal tiles — each tile is a nested tmux attach to a daemon-owned agent session, so you get the real session, not a snapshot. OpenRig owns the semantics; herdr owns the surface. You drive it entirely through the rig terminal CLI, which rides the installed herdr binary at arm's length — never link, embed, or plugin it.

The whole surface — three verbs

rig terminal open <view> [--provider herdr|cmux] [--json]   # herdr is the default provider
rig terminal views [--json]                                 # list openable views (saved + derived)
rig terminal status [--provider] [--json]                   # provider liveness / health

<view> resolves, in order, to one of:

• a rig name — every live agent in that rig, auto-laid-out;
• pod:<rig>/<podNamespace> — every live agent in one pod of a rig (the rig's inventory filtered by pod);
• mission:<id> — the agents working that mission (derived live from topology);
• slice:<id> — the agents working that slice (derived live);
• a saved-view name — a user-defined group (see Saved views).

Compose a view from a sentence

An agent asked "open all my rigs plus a mission as views" runs one open per target:

rig terminal open acme-web                     # a whole rig, live agents as tiles
rig terminal open mission:site-relaunch        # exactly the agents working the mission
rig terminal open slice:search-filters      # the agents working one slice

No hand-listing of seats: the mission/slice membership is derived from live topology at open time.

Read the result honestly — partial and degrade

The result is a partition — every seat lands in exactly one bucket, each named:

• opened — the live agents now showing as tiles.
• absent — seats in the view that aren't currently live: named and skipped, never silently dropped. A view that opens some of its seats is a success (the partial is disclosed) and exits 0. Only a view where no pane opens exits non-zero.
• degraded — an agent that structurally cannot tile, named with the reason. The v1 case: an agent on a host registered over HTTP has no ssh path, so its tile can't be composed — it reads as "host <id> is http-registered; tiles need ssh" and is skipped, never dropped. (ssh-reachable hosts tile via an ssh-wrapped attach; full http-host tiling is deferred to the cross-host transport seam.)

Read --json to branch on the partition programmatically; the exit code alone tells you opened-something (0) vs opened-nothing (non-zero).

Read-only — who's interactive, who's watch-only

Read-only is composed into the pane at open time — a read-only tile is a tmux attach -r, the client reports readonly=1, and it physically cannot send input. The current policy, by view kind:

• A rig view or a pod: view is interactive — you asked for that rig (or pod) directly, so you can drive its agents.
• mission: and slice: views are read-only by construction — these derived views cut across rigs; you watch and scroll, you don't keystroke into them.
• A saved view is per-member — each member carries its own readOnly (omit = interactive; true = attach -r).

So you don't have to remember to be careful: the view kind (and, for a saved view, the per-member flag) sets it at open time.

Safety rails (hard — the fleet-safety rail)

• A tile is a view (a nested tmux attach) of a daemon-owned session. Never move, join, kill, or re-parent a daemon-owned pane. Closing a tile detaches one tmux client — the daemon's session is untouched and its addressing (send/capture/nudge) is unaffected.
• Host-local read-only viewing mutates nothing. Anything that would change a live daemon session's shared state (e.g. flipping a tmux option on a running seat) is a config/design change — prove it in an isolated environment, never live-flip in production.