Manual, collapsible thread groups with optional colors

[coreldh]

Problem

A project is the right execution boundary, but it is not always the right organizational boundary.

For example, within one project I may have several related threads:

• Galeno — Fable 5.1
• Galeno — Astra
• Galeno — Sol

They belong to the same project, but represent different roles or workstreams. As the number of threads grows, a flat project list becomes hard to scan and it is easy to lose the relationship between them.

Proposal

Add user-created thread groups inside a project.

A group would be a named, collapsible section in the project’s thread list:

Pergamum
  ▾ Galeno
      Galeno — Fable 5.1
      Galeno — Astra
      Galeno — Sol
  ▸ Catena Aurea
  ▾ Other threads
      ...

Users could:

• Create, rename, delete, reorder, and optionally color groups.
• Move a thread into a group through the context menu or drag-and-drop.
• Keep unassigned threads in an Ungrouped section.
• Collapse or expand a group with one click.
• See an aggregate activity indicator on a collapsed group when it contains a working thread, an approval request, or something needing review.

A small per-thread color accent could be a useful follow-up, but group colors are the important first step. Color should be supplementary rather than the only status signal, so the UI remains accessible.

Why manual groups

This is deliberately not a request for automatic grouping, AI-generated tags, or grouping solely by worktree.

Those approaches can be useful, but the person managing the work understands the meaningful relationship between threads: they may be different models reviewing the same task, separate stages of a rollout, or parallel roles in one initiative.

Manual grouping gives that person a lightweight way to express the structure without changing repository, project, branch, or worktree ownership.

Smallest useful scope

• Groups are scoped to a project.
• Manual create / rename / reorder / delete.
• Manual thread assignment and removal.
• Collapsible group headers.
• Persistent group membership and collapsed state.
• A visible aggregated status badge for collapsed groups.

Out of scope for a first pass:

• AI-generated tags or automatic grouping.
• Changes to worktree, branch, project, or provider behavior.
• Replacing search, filters, attention ordering, or Spaces.
• Nested groups.

Related ideas, but not duplicates

• [Feature]: Thread grouping / filtering #5653 proposed tags for grouping/filtering threads.
• [Feature]: Group threads by worktree #3697 proposed grouping automatically by worktree.
• [Feature]: Multiple Spaces for organizing projects and threads (Arc/Zen-style) #2293 proposed higher-level Spaces for projects and threads.
• [Bug]: Collapsing a project with many visible threads blocks the UI for seconds #3962 confirms that project-level collapsing already exists, though it has a performance issue for very large lists.

This proposal is a manual, user-defined layer inside the existing project/thread hierarchy.

Question for maintainers

Would this fit the Sidebar V2 direction? In particular, should group membership be durable server-side user metadata, while presentation choices such as collapse state and color remain device-local?

I am looking for product direction first and will not open an implementation PR without it.

[umitaltintas]

Manual groups make more sense than automatic ones here.

I have around 25 projects in t3code, arranged on disk under a few parent folders. Roughly half have no git remote, so the existing repository grouping produces nothing for them. Anything derived from git identity keeps missing that shape. A manual group doesn't care.

Same gap one level up, for the project list itself (#6754). If a group were just a named, collapsible, user-ordered container, one implementation could cover both.