sessions: group the list by project (`by project` chip)

[grimmerk]

The ask

A by project grouping of the session list — the default list, and inside a scope (a saved list, the live view) — as an alternative order to plain recency. project:xxx already answers "every session of a project I can name"; grouping answers the browsing question: which projects have I been in lately, and what is in each, without typing a name and without knowing it first.

Measured 2026-09-06 (anchor account history.jsonl, sessions in recency order)

Window	Distinct projects	Projects with ≥ 2 sessions	Adjacent rows that change project
last 30 sessions	7	6	18 / 29 (62%)
last 100	18	10	77 / 99 (78%)
last 300	45	24	228 / 299 (76%)

So the recency list is genuinely interleaved: two out of three neighbouring rows belong to different projects, and finding "the session of project X" means scanning project names down the list.

The largest bucket is ~/git itself — 12 of the last 30, 26 of the last 100 — sessions started from the parent folder: some are tests, some quick one-off tasks, some cross-repo work. Grouped by folder name they form one git group. That is less of a problem than it first looks (the small tasks are not what one goes back to), but it is the case that decides whether one level is enough — see open question 1.

Value — ★★☆

• Why not ★★★: it competes with recency, which answers the commonest question ("what was I just doing"); group headers cost vertical space, the scarce resource in the popup; and project:, saved lists and the Projects tab already cover the "one named project" case.
• Why not ★☆☆: the interleaving above is measured, not felt; nothing today gives the overview (which projects, how many sessions each, when last touched); and in the live view, grouping by project is exactly the view one wants when deciding which processes to close — "which projects still have something running".

Shape (a proposal, not a decision)

• A chip by project beside by match: off by default, remembered, applied within whatever scope is active. Not a tab, not a default mode — a tab would break the single-list keyboard model.
• Groups ordered by their most recent member; recency inside a group. Header: name · count · last activity · live count.
• Expanded by default (collapsing hides the newest session); click the header, or ← / → on the selected row, to collapse / expand its group; state remembered for the app run. "Collapsed by default" and "one group open at a time" were considered and are not preferred, for the same reason.
• The pinned zone stays on top, ungrouped — pins are cross-project by nature. The minor-session fold applies inside a group.
• by match + by project together: project decides the outer order, the other chip the order inside.
• Grouping key, first cut: one level, the project folder name (the same key the row shows today).

Not doing (decided 2026-09-06)

A "sessions of this project" action on the Projects tab, or clicking the project name on a row to prefill project: — grouping makes both unnecessary, and neither is a preferred interaction.

Open questions

1. Container folders such as ~/git: keep one level (a git group that mixes cross-repo work with ~/git's own sessions), or sub-group its members by the session's repo context (sessionRepos from feat(sessions): query operators, PR refs in any spelling, persisted cache, open N #151: the PR badge plus mined PR references), with the rest as git (other)? ~/git has sessions of its own either way, so the sub-group is an addition, not a replacement. Undecided.
2. One grouping mechanism, two keys. sessions: /branch creates generation chains — 23.9% of transcripts, and CodeV cannot tell them apart #142 C1/C3 (folding a /branch chain under its task) is also a grouping, keyed by chain rather than by project. If both are built, the list should carry one "group" concept with two keys rather than two implementations — this repo's recurring failure mode.

Cost

Medium. The list already has four interacting orders (pins, the minor-session fold, by match, the scope); a fifth touches keyboard navigation (data-session-index) and the render loop. Expect review rounds like #151's (4–5).

Part of the Sessions tab work tracked in #144.

🤖 On behalf of @grimmerk — generated with Claude Code