[idea] Add tab.reorder / tab.move to socket API + CLI

[donovan]

Reposting from #770 (closed by triage — feature requests belong in Discussions per CONTRIBUTING). This is the tab-level sibling of #323 (workspace reorder, planned).

Summary

The socket API exposes tab.{create,list,get,focus,rename,close}, but no operation to change a tab's position within its workspace. Requesting an API verb (and matching herdr tab CLI subcommand + optional keybinding) to reorder tabs.

This is the tab-level sibling of #323 (workspace reorder, already planned) — structurally identical, and likely able to share event/persistence plumbing.

Confirmed reorder isn't in the current surface by enumerating the socket methods (sending a bogus RPC and reading the server's expected one of … list): the tab verbs are exactly tab.create, tab.list, tab.get, tab.focus, tab.rename, tab.close.

Note the reorder primitive already exists server-side: dragging a tab in the UI reorders it, persists to session.json, and tab.list subsequently returns tabs in display order (not creation/number order). This request is purely about exposing that existing capability over the socket/CLI for keybindings and scripted layout.

Use case

Tools that drive herdr over the socket and spawn tabs programmatically want deterministic placement. Example: an external orchestrator creates agent tabs and wants to group them — keep task/agent tabs ahead of scratch shells, or keep a pinned tab in a fixed slot. Today new tabs land in creation order and can only be repositioned by mouse drag, which isn't scriptable or keybindable.

Plus the interactive-parity case (matching #323's workspace example and tmux's swap-window -t +1): rebind e.g. Cmd+Shift+H/L to move the current tab left/right.

Proposed API

Two reasonable shapes (mirroring #323):

Option A — relative move (matches focus/cycle ergonomics):

tab.move { tab_id, direction: "left" | "right" }

Option B — absolute position (matches rename's "set this property" shape):

tab.reorder { tab_id, position: u32 }

Option A covers the keybinding case; Option B covers drag-and-drop and scripted layout restore. They're not mutually exclusive — A can be a thin wrapper over B. An ergonomic relative-to-target variant (--before / --after another tab_id) would also help scripted placement.

A tab.reordered event (covering the existing mouse-drag path) would let socket subscribers stay in sync — same as the proposed workspace.reordered in #323.

Proposed CLI

herdr tab move <tab_id> --direction left|right
herdr tab reorder <tab_id> --position <n>

(optionally herdr tab move <tab_id> --before <tab_id> | --after <tab_id>)

Proposed keybinding config

Add to the [keys] schema, both unset by default to match the existing previous_tab / next_tab pattern:

# move_tab_left = ""   # optional, unset by default
# move_tab_right = ""  # optional, unset by default

Open questions

• Share implementation + event plumbing with Add workspace.reorder (or workspace.move) to socket API + CLI #323 (workspace.reorder)? The two are the same operation (reposition an item in an ordered list + emit a *.reordered event that also covers the existing mouse-drag path).
• Does position clamp or error when out of range? (Probably wants the same answer as Add workspace.reorder (or workspace.move) to socket API + CLI #323.)
• Scope to within-workspace only (a tab's parent workspace doesn't change), keeping cross-workspace tab moves out of scope?

---

Drafted with Claude Code.

[Solido]

I use a very standardized procedure with every project. Important tooling that drive the whole project and we created a plugin to setup Herdr but the tab can be created last or land in the middle of other cli. Support for this feature can ensure it stay at opne first position at any time and we can enrich the plugin with other Herdz features. Thanks for the suggestion!