Let plugins surface actions in the UI (context menus / command palette), not just via keybinds

[Gandalf-Le-Dev]

Problem

I'm writing a herdr plugin that adds a pane (a code-review view). I'd like users to be able to open it straight from the UI — most naturally an item in the workspace right-click menu (next to Rename / Close / New worktree), or a command-palette entry — instead of only from the CLI (herdr plugin pane open …) or a [[keys.command]] binding.

Today there's no way for a plugin to contribute an interactive entry point to the interface:

• The workspace / tab / pane context menus are fixed item lists, so a plugin can't add to them.
• Plugin [[actions]] already carry a contexts field (global / workspace / tab / pane / selection), which reads exactly like it was meant for this — but those actions are never rendered in any menu. contexts currently only surfaces in the plugin action list API response.

So the only ways to trigger a plugin action or pane are non-UI: a [[keys.command]] binding, an event hook, or the CLI. That makes plugin features hard to discover — every user has to hand-configure a keybind.

Proposal

Surface enabled plugins' [[actions]] in the UI, filtered by their declared contexts:

• workspace-context actions → the workspace right-click menu
• tab-context → the tab menu, pane-context → the pane menu
• global → the global/launcher menu (and/or a command palette)

Selecting one invokes the action's command (which can call herdr plugin pane open …, run a script, etc.). Since the contexts field already exists on the manifest, this is largely wiring it into the menu builders — it would give plugins a discoverable, clickable entry point without every user editing their config.

Related

• Customized command palette #114 (customized command palette) — a palette would be a natural home for global plugin actions too.
• Temporary floating popup panes for plugins #1125 (floating popup panes for plugins) — complementary plugin-UI work.

[atyrode]

Agreed. Relates to my proposition too: #1609