Feat/agent group

[FourWindff]

Summary

This branch introduces panel grouping to the tiling layout, grouping task panels by project and agent coordination mode (independent vs coordinator). Each group can be collapsed into a single representative panel, and expanded again on demand. The feature also includes new grouped-panel chrome, updated visual treatments for inactive panels, and persistence for collapsed-group state.

• Adds panelGroupCollapsed store state keyed by ${projectId}:${groupType} and persists it across sessions.
• Reworks TilingLayout to compute PanelGroup segments and render grouped panels with a shared background, collapse/expand controls, and adjusted resize handles.
• Updates styles.css with new .panel-group-wrapper, .panel-group-collapse-btn, .panel-group-expand-btn, and inactive-panel overlay styles.
• Skips terminal fit when the container has zero size, preventing resize errors for hidden grouped panels.

[johannesjo]

First off — thank you for this! 🙏 Panel grouping is a genuinely nice direction for the crowded-strip problem, the store/persistence/security plumbing is careful (project-id validation on load, fail-closed handling of corrupt state), and the test coverage on the pure planning helpers is appreciated. I ran a multi-perspective review (correctness, security, architecture, performance, simplicity, UX). Summary below — overall needs a few changes before merge, but the core is solid.

🔴 Must-fix: collapsing can hide the active panel

setActiveTask / jumpToTask / sidebar clicks (navigation.ts) and togglePanelGroupCollapsed (ui.ts) never touch collapse state — it's only reset on task create/uncollapse. So:

• Collapse a group, then select a non-first member → it becomes activeTaskId but its wrapper stays width:0; visibility:hidden (TilingLayout.tsx:743-755). Keyboard input goes to an invisible panel and scroll-into-view targets a hidden node, with no visible feedback.
• Same in reverse: collapsing a group whose active task is a non-first sibling makes the active panel vanish.
• In focus mode too: wrapperStyle() checks childHidden() before store.focusMode, so a hidden collapsed sibling stays blank even when focused.

Fix: force-expand a group when one of its members becomes active (and/or reassign activeTaskId to the visible first panel when a collapse would hide the current active task).

🟡 High-value cleanups

• renderSegmentCache is an unbounded module-level Map that's never evicted (TilingLayout.tsx:146-157) — 6 of 7 review passes flagged it. Because the key embeds positional fields (start/end/index/color), it grows monotonically over a session and only returns a stable reference when the exact same layout recurs — so it doesn't actually prevent the reorder remount it looks designed for. Suggest dropping it and letting panelCache (which already stabilizes the real TileChild/DOM) do the work, switching the outer <For> to <Index>.
• Reorder likely remounts ungrouped panels (terminal disposed → scrollback lost). The outer <For> now keys on single:${id}:${index} objects, so Cmd+←/→ or drag-reorder produces brand-new references → SolidJS recreates the row → TerminalView disposes. Worth confirming by running; fixing the cache the right way resolves it.
• Two grouping passes — computeTilingSegments already computes group boundaries (isFirst/panelCount), then buildRenderSegments rescans to rediscover them. Unifying into one pass removes the second algorithm + the cache (~60-80 lines).
• DRY: coordinatorMode || coordinatedBy ? 'coordinator' : 'independent' is duplicated in TilingLayout.tsx and tasks.ts (panelGroupKeyForTask, which also re-implements the key instead of reusing groupKey). One shared getPanelGroupType(task) would help.

🟢 Minor

• The ~9 *ForTest re-export shims could go away by extracting the pure helpers into a small tilingGroups.ts and exporting them normally (also fixes the file-size growth).
• groupWrapperPadding ignores its parameter and always returns '0 6px' — make it a const.
• Dead __collapsed handling (TilingLayout.tsx:164,617) — nothing creates that id anymore.
• void Object.keys(store.panelGroupCollapsed).join(',') allocates each run; the real subscription is the isPanelGroupCollapsed(...) read below it.
• styles.test.ts leans on regex-over-CSS and not.toContain('...source...') assertions, which break on harmless restyles without catching real regressions — a rendered-component test would be higher-signal.

💬 On the UX pattern

The grouping + colored background is good. The part I'd reconsider is collapse-to-first-panel: it hides count and identity (you see one arbitrary full-size panel + a faint chevron, with no signal of how many/which tasks are behind it), while reclaiming little space since the representative still renders full-width. Combined with persistence, reopening the app can leave running tasks silently hidden. A couple of directions worth considering:

• Add a count/identity affordance to the collapsed state (a +N badge / status dots) so hidden panels stay legible — especially on restore.
• Note we already have focus mode + sidebar collapse; three overlapping "hide panels" mechanisms is a lot of surface. If we can make group-collapse coexist legibly with focus mode (or lean on a tabs-within-group / count-badge-stack representation), that might serve "many parallel agent panels" better than collapse-to-first.

Also minor a11y: the collapse/expand buttons have only title (SVGs are aria-hidden) — an aria-label would help screen readers.

Happy to pair on the active-panel fix or the single-pass/<Index> refactor if useful. Thanks again for tackling this — really like where it's headed!

[FourWindff]

This PR is still rough — it's mainly meant to explore the grouping interaction. Once the direction is settled, I'll open a fresh PR for the real implementation. Before moving forward, I'd like to discuss a few key questions about the grouping UX:

1. Besides collapsing a group into the first panel, are there better ways to display grouped task panels?

2. How should we define which tasks belong to the same group?

   • Same project
   • Tasks created from the same branch
   • In coordinator mode: the coordinator and all its child task panels

   I think grouping by the same project is too broad. Usually I create multiple tasks from a single branch, and they tend to be similar kinds of work — e.g., adjusting UI, or cleaning up different categories of code (dead code, migration, compatibility). The point of grouping is to make it easier to manage related tasks, so grouping by branch or by coordinator mode seems more useful.

3. How should grouping interact with the sidebar's collapsed mode?
   Should task panels in the same group hide together? For example, show a collapse button only on the first task panel; clicking it hides the entire group. Then clicking any task from that group in the sidebar expands and shows all panels in the group.

4. When dragging a task panel, should the whole group move together?

Since these are grouped tasks, having them show, hide, and move together seems consistent.