Show + (create workspace) on a group

[skalahonza]

What problem are you trying to solve?

I often want to create new workspace and assign it to a group. I think there should be a + button on each group.

Proposed solution

No response

Workarounds you've tried

No response

[github-actions]

This is a feature request (not a bug), so the notes below are about where the feature would land rather than a root cause.

Summary

The ask is for a + (create workspace) affordance on sidebar groups — the user-created sections inside a project in the dashboard sidebar — so a workspace can be created directly into a group instead of being created at the project level and then moved. Today only the project row has a +; a group header exposes only rename / set colour / delete, so getting a new workspace into a group takes two steps (create, then drag or Move to group). The request is plausible and consistent with existing UI precedent; nothing is broken, the wiring just doesn't exist end-to-end.

Affected code

Group header and its actions:

• apps/desktop/src/renderer/routes/_authenticated/_dashboard/components/DashboardSidebar/components/DashboardSidebarSection/components/DashboardSidebarSectionHeader/DashboardSidebarSectionHeader.tsx:89-102 — the header's single hover-revealed action slot, a fixed size-5 box that currently holds only the actions node.
• apps/desktop/src/renderer/routes/_authenticated/_dashboard/components/DashboardSidebar/components/SortableSectionHeader/SortableSectionHeader.tsx:102-109 — passes DashboardSidebarSectionActionsDropdown into that slot.
• .../DashboardSidebarSectionContextMenu/components/SectionActionsMenuItems/SectionActionsMenuItems.tsx:121-167 — the group menu: Rename group, Set group color, Delete group. No create action.

Existing precedent for the button being asked for:

• .../DashboardSidebarProjectSection/components/DashboardSidebarProjectRow/DashboardSidebarProjectRow.tsx:100-121 — the project row's hover + with aria-label="New workspace", calling onNewWorkspace.
• .../hooks/useDashboardSidebarProjectSectionActions/useDashboardSidebarProjectSectionActions.ts:132-134 — handleNewWorkspace = openModal(project.id). (The v1 sidebar has the same pattern at screens/main/components/WorkspaceSidebar/ProjectSection/ProjectHeader.tsx:320.)

Where the plumbing stops:

• apps/desktop/src/renderer/stores/new-workspace-modal.ts:27-63 — the modal store carries preSelectedProjectId / preSelectedSession only; there is no notion of a target section.
• apps/desktop/src/renderer/stores/workspace-creates/writeWorkspacePaneLayout.ts:60-74 — every newly created workspace's sidebar row is inserted with sectionId: null, so a create can't land in a group.
• apps/desktop/src/renderer/routes/_authenticated/hooks/useDashboardSidebarState/useDashboardSidebarState.ts:373-437 — moveWorkspaceToSection(workspaceId, projectId, sectionId) already exists and does the placement work (sets sectionId, appends tabOrder, unhides). Group membership is purely local sidebar state (v2WorkspaceLocalState.sidebarState.sectionId + v2SidebarSections), never sent to the host, which keeps this change client-side.

Suggested direction

1. UI: add a second hover-revealed button in the group header's action area, mirroring DashboardSidebarProjectRow's + (same HiMiniPlus, tooltip, stopPropagation on click/keydown so it doesn't toggle collapse). The slot at DashboardSidebarSectionHeader.tsx:90 is a fixed size-5 box, so it needs to become a flex row sized for two controls. Add a matching New workspace in group item to SectionActionsMenuItems so the context menu and dropdown stay in sync. If the group is collapsed, expand it on click (the project + has the analogous behaviour via handleNewSection's toggleProjectCollapsed).
2. Target plumbing: extend the modal store with a preSelectedSectionId (set by openModal, cleared in closeModal, and preserved through stashDraft/restoreStashedDraft at new-workspace-modal.ts:101-121, otherwise a failed-create retry silently drops the group).
3. Placement: the simplest robust option is to call moveWorkspaceToSection(result.workspaceId, projectId, sectionId) off the submit(...).completed handle rather than only seeding sectionId at insert time — useWorkspaceCreates.ts:395-398 deletes the optimistic row and re-writes it under the host's canonical id when the two differ, so a value written only at first insert can be lost. If you want the row to appear in the group immediately (before the create settles), thread an optional sectionId through writeWorkspacePaneLayout and re-apply it after settle.

Reproducing / verifying

Current behaviour: open the dashboard sidebar, right-click a project → new group, hover the group header — only the ⋯ dropdown appears; hover the project row above it and the + does appear.

For a regression test, the placement half is the testable part and already has a harness: apps/desktop/src/renderer/routes/_authenticated/hooks/useDashboardSidebarState/sidebarMutations.test.ts drives these collections in-memory (localStateRow("ws-placed", "proj-1", { sectionId: "sec-1" })). A bun:test case asserting that a create submitted with a target section ends with sidebarState.sectionId === "sec-1" — including the canonical-id-swap path in useWorkspaceCreates — would cover the part most likely to break. The button itself is best verified via CDP per .agents/skills/cdp-verification/SKILL.md.