[idea] Plugin-contributed sidebar areas (plugin owns the content)

[senna-lang]

idea / problem

Plugins can register actions, event hooks, and panes, but they cannot add a new region to the sidebar. The sidebar is fixed to Spaces + Agents.

For plugins that want always-visible chrome — usage meters, CI status, queues, digests, and similar — the useful host primitive is not only:

• inject $token into an Agent/Space row, or
• open a plugin pane / popup on demand

It is: contribute a dedicated sidebar area whose content the plugin implements.

Today those plugins have awkward options:

• Metadata tokens in [ui.sidebar.agents] / [ui.sidebar.spaces] — persistent, but cramped, shared with Herdr's own rows, and not a first-class area
• Plugin panes / popups — rich UI, but not always-on sidebar chrome
• Forking Herdr — works, but shouldn't be required for a contributed region

requested change

Allow a plugin to declare and own a new sidebar area. Herdr provides the host surface (placement, sizing/collapse, focus, lifecycle, multi-client consistency). The plugin owns what is shown inside.

Sketch (illustrative only — not attached to a specific design):

# herdr-plugin.toml
[[sidebar]]
id = "usage"
title = "Agent Usage"
placement = "below_agents"
# plugin-owned content surface — exact mechanism TBD

I am not attached to the implementation shape. Acceptable directions include:

1. Plugin-owned sidebar slot that hosts plugin content (for example a bounded terminal/TUI surface, or another plugin-rendered surface)
2. A more constrained push API (structured rows/bars) if that is only a v1 transport, as long as the area itself is plugin-contributed rather than hardcoding vendors into Herdr or only decorating Agents/Spaces rows

What matters most:

• plugins can add a sidebar area (not only decorate Spaces/Agents rows)
• content ownership stays with the plugin
• multiple plugins can coexist without fighting over agent-row metadata tokens
• the area is always-on chrome (not only a click target that opens a separate pane)

why you want this

Herdr is already the always-visible control surface for coding agents. Usage, CI, queues, and similar plugin UIs belong there as first-class areas, without forking Herdr or abusing agent-row metadata.

I maintain an agent-usage style plugin that currently has to live inside Agent rows via $limit / $context tokens (and a separate plugin pane for detail). A plugin-contributed sidebar area would be the natural host surface for that kind of tool — and for other plugins that need persistent sidebar presence with their own content.

related

These are close but not the same request:

• [idea] feat: plugin sidebar slots — persistent sidebar entries for plugins #1220 — plugin sidebar slots / persistent clickable entries (presence + open action), not a plugin-owned always-rendered area
• [idea] Let plugins own a persistent sidebar section #1609 — persistent sections with server-rendered rows/bars via sidebar.report_section (Herdr draws; plugin pushes data). Welcome direction, but my ask is stronger on plugin-owned content, not only a fixed row grammar
• Show Claude/Codex subscription usage in the spaces sidebar #1361 — Claude/Codex subscription usage in the sidebar as a product feature / compact line; this discussion is the general host capability (plugin contributes the area) rather than hardcoding one usage UI

If a smaller v1 lands first (e.g. #1609-style sections), I'd still hope the long-term boundary is: plugin contributes area, plugin owns content.