Sidebar: group the inbox by environment, project or provider — with rows that stop repeating themselves

[BarretoDiego]

Update — the prototype now covers the full sidebar workflow

The first version of this proposal only grouped the inbox. After using it as my daily sidebar, I kept following the same rule: the structure that tells you where work lives should also be the place where you act on it.

The current prototype now covers grouping, ordering, section actions, project removal, per-project settled history, and navigable environment/project scopes. It is still one working branch, but the commits are layered so maintainers can take only the pieces that fit the product direction.

Screenshots — current prototype

Full sidebar with environment → project grouping, compact thread rows, per-project history, and scope-owned actions.

Grouping controls	Sorting controls
Choose one or two grouping axes without changing the provider filter.	Sort by activity, creation time, alphabetical order, or switch to custom ordering.

Custom section order	Environment scope
Reorder sections in place while nested groups remain inside their parent.	Breadcrumb navigation opens an environment page with its projects and threads.

Project scope keeps active, snoozed, and settled work together and exposes the same project actions as the sidebar.

What is in the current version

• Environment → Project is the useful default. A flat list remains available, but the default now answers “which machine?” and “which project?” without repeating both on every thread.
• Grouping and filtering remain orthogonal. Group by environment, project, or provider; add a second axis; filter all shelves by provider; sort by activity or creation time.
• Sections can be ordered. Busiest-first, alphabetical, or custom. Drag a section or use Move up/Move down; nested sections only move within their own parent.
• Quiet projects stay visible. A project with zero live threads still has a section, so it remains one click away from new work instead of disappearing from the navigation.
• Actions live on the scope they affect. Environment headers add a project. Project headers create a thread or open project settings. The same actions are available from the context menu.
• Remove project is reversible in the right place. It is kept in the project-section context menu, shows the path/environment/thread count, and confirms before removing the project from the sidebar.
• Settled history belongs to the project. When grouped by project, every project ends with its own collapsed Settled shelf and incremental Show more row. Other grouping modes keep the global shelf.
• Collapsed sections summarize attention. Approval, input, failure, unseen completion, and running counts use the same status classifier as their child rows.
• The breadcrumb is navigation, not decoration. Environment and project names above a thread open scope pages with their projects/threads and the same Active, Snoozed, and Settled model as the sidebar.
• Cards only say each fact once. A grouped row removes metadata already stated by its ancestors while keeping status, pin, snooze, settle, and PR affordances.

Why this is one model instead of several sidebar features

Grouping alone exposed two dead ends: empty projects vanished, and a visible project header could not start work. Adding actions without ordering made active sections jump around. Adding ordering without per-project history let the global Settled shelf grow without context. The pieces reinforce one small mental model:

A section represents a real scope, remains visible, owns its actions, and owns the history that belongs to it.

The implementation keeps that model client-side where possible. Grouping, sorting, attention rollups, and row compaction are pure derivations over thread shells already in memory. There is no sidebar polling, continuous animation, or new websocket traffic for layout.

Branch and commit layers

Working branch: feat/sidebar-plan-limits

The sidebar work can be reviewed or cherry-picked in layers:

1. fbd582567 — group, filter, and sort the inbox
2. d88d9e899 — start a thread from a project section
3. 1eb9b4d0a — open the project picker in a chosen environment
4. 3b59e63f7 + 342acabfd — make headers own their actions and settle the compact-row UX
5. 2828bb2b8 — remove a project from its section
6. 781dc6ff3 — custom section ordering
7. 21583f9e0 — navigable environment/project scopes

The branch tip also contains the provider plan-limit meter. I am opening that as a separate Discussion because its server/provider contracts deserve an independent product decision.

Surfaces and compatibility

• Web and desktop get the full grouped sidebar and scope navigation.
• Settings are client-local with decode defaults, so older and newer clients can connect to the same server.
• Provider filtering uses driver kind rather than instance id, so multiple accounts of the same provider do not create unstable filters.
• Project removal uses the existing project command path; it is not a client-only disappearance.
• User documentation lives in docs/user/thread-sidebar.md; vocabulary additions are in the internal glossary.

What I deliberately kept out

• No subagent counts: the sidebar shell does not currently carry the activity data needed to do this honestly.
• No replacement of the existing flat card design.
• No new server-side grouping projection.
• No mobile redesign hidden inside a web-sidebar proposal.

The original problem

The v2 sidebar becomes hard to scan once one user has multiple environments, projects, and providers. A single project filter is too narrow, while one flat list repeats metadata and makes the user reconstruct scope row by row.

The prototype keeps today’s thread semantics and makes scope visible, actionable, and stable. Is this the sidebar direction maintainers want? If yes, the commit stack above is intentionally shaped so it can land in smaller PRs rather than as one large change.