[idea] Let plugins own a persistent sidebar section

[atyrode]

#1220 asks for persistent sidebar presence for plugins, and #1361 wants provider usage in the sidebar — ending on an open question: is "an external source pushes into a server-owned slot that herdr renders" the right boundary? I'd been wanting the same thing, so I built a working version of that boundary on a fork, and I think it generalizes both asks.

Concretely: a sections region in the sidebar plus a sidebar.report_section socket/CLI API. An external provider — today any process; a v1 plugin can call it via HERDR_BIN_PATH from a manifest command or hook — publishes structured rows, styled spans or bars. A section is owned by whichever source reports it first, with seq + TTL so stale content self-evicts, and it's inert when unconfigured. To be precise about scope: this is v1-compatible transport, not manifest-integrated — declaring a section still goes through config, and ownership is by source string, not plugin identity.

Working branch with tests: https://github.com/atyrode/herdr/tree/sidebar-sections. My usage meter running on it (the #1361 use case):

Before any PR I'd like to know whether some form of this fits herdr's direction. The fork is a baseline to ask changes on, not a demand — happy to rename, reshape, split, or rewrite it, including making it manifest-native. The design question I'd most value a take on: should section ownership bind to plugin identity (manifest / plugin_id, lifecycle cleanup) rather than caller-supplied source strings?

[Lotto724]

This is a useful prototype, especially the layout and overflow work, but after comparing it with current master I think the durable boundary should be neutral plugin-owned summary data rather than sidebar.report_section.

The newer agent.view.set/clear path seems like a strong precedent: semantic server state, plugin identity and lifecycle cleanup, with client-owned rendering across expanded, collapsed, mobile, and future surfaces.

Two concrete implementation issues may be useful if this branch remains a test bed:

• SidebarReportSection is missing from request_changes_ui, so an accepted report does not reliably trigger a redraw or remote frame.
• SidebarSections::report inserts unbounded section IDs even for empty or unconfigured reports, allowing permanent map growth.

Live handoff also preserves the section height but drops current reports, ownership, sequence state, and remaining TTL.

I’d keep the UI experiments, but reshape the public contract around manifest-declared (plugin_id, summary_id) facts with bounded semantic state, sequence/TTL/stale semantics, lifecycle cleanup, bootstrap/list plus events, and let each client decide whether that becomes a bar, row, badge, or nothing.

If this semantic-summary direction is sufficiently different from the sidebar-specific proposal, I’m happy to move it into a separate discussion rather than split the design conversation here.

[unger1984]

I strongly support the neutral plugin-owned summary direction over a sidebar.report_section API.

My use case is session-wide, always-visible information that does not belong to any specific Space or Agent: a clock, current keyboard layout, exchange rates, or a short background-task status.

Today, placing such values in Space metadata duplicates them for every workspace. A small session-level summary would avoid that while keeping the sidebar useful as an at-a-glance surface.

For a first version, I would keep the contract deliberately narrow:

plugin.summary.replace {
  summary_id,
  title,
  lines: [plain_text]
}

For example:

STATUS
18:42:07
⌨ RU
$ 78.20 · € 91.40

I would prefer:

• manifest-bound (plugin_id, summary_id) ownership;
• plain text only — no ANSI, colors, arbitrary rendering, embedded terminals, links, or interactivity;
• bounded line count and line length;
• atomic replacement of the full summary;
• sequence / TTL support for stale-data handling;
• automatic cleanup when a plugin is disabled or unlinked;
• client-owned rendering, so the sidebar is one possible surface rather than the API boundary.

This feels like a useful middle ground: more appropriate for persistent, session-wide status than Agent/Space tokens, but much smaller and safer than a general plugin UI framework.

Would this constrained, semantic-summary model fit Herdr’s direction?

[DarkPhilosophy]

I completely 101% agree with this direction. A persistent sidebar showing context usage, token consumption, cost, model, session duration and current agent state would make Herdr much more useful when managing multiple agents at the same time!

The most valuable part for me would be seeing context usage and cost without switching between sessions. It would make it much easier to notice when an agent is close to compaction, consuming too many tokens or running longer than expected.

I totally agree that the sidebar should stay compact and configurable, with only the most important values shown by default and the detailed statistics available on demand. A normalized usage interface for different agents would probably be the main architectural challenge, but the concept itself fits Herdr extremely well!!! I am grateful for you work, keep the good job!

[mpazik]

Thanks for sharing the branch. I was looking for that feature to list modified files by agent.
Something like: