Skip to content

feat(sidebar): show which computer each Move to group target belongs to - #35501

Open
jbamlee wants to merge 2 commits into
stablyai:mainfrom
jbamlee:feat-project-group-host-label
Open

jbamlee wants to merge 2 commits into
stablyai:mainfrom
jbamlee:feat-project-group-host-label

Conversation

@jbamlee

@jbamlee jbamlee commented Oct 29, 2026

Copy link
Copy Markdown
Contributor

ELI5

A project group lives on the computer that made it, and a project can only be put in a group on its own computer. With paired computers, Move to group lists everyone's groups, but only by name. So you can't tell whose group is whose, or why a move is refused. When the listed groups come from more than one computer, each item now shows its computer next to its name.

What Changed

This is a proposal for #35499; happy to adjust or drop it.

Before:

  • Orca A is paired with Orca B. Orca A has "Group A" and Orca B has "Group B".
  • A workspace card's Move to group lists "Group A" and "Group B". Nothing says that "Group B" is on Orca B, or that a project on Orca A cannot join it ("Could not move project to group").

After:

  • The items read "Group A" with "Local Mac" and "Group B" with "Orca B".
  • They use the label that project headers already show when two computers have a project with the same name: the host icon and name, muted, text-xs.
  • When every group is on one computer, nothing changes.

Nothing is hidden or disabled. Every group stays listed, and the store guard (isProjectGroupJoinableFromCatalog) still refuses a cross-computer move and explains why. Sidebar group headers are unchanged.

Mechanism:

  • project-header-host-context.ts:
    • The host label resolution moved into one resolver, createHostContextResolver, which project headers already used: registry label, getHostContextLabel fallback, managed-orcad annotation, alias canonicalization.
    • New getProjectGroupHostContexts resolves each group's computer from getRepoExecutionHostId(group), which is what getProjectGroupHostId and the store guard read. It returns them only when the groups span more than one canonical computer.
    • getProjectHeaderHostContexts keeps its behavior and now uses the same resolver.
  • New ProjectGroupMoveMenuItems.tsx: the Move to group items for both the workspace card menu (WorktreeContextMenuView) and the project header menu (RepoHeaderProjectActionsMenu), which had the same inline list. It mounts only while the submenu is open.
  • New sidebar-host-options-context.ts: the viewport provides the sidebar's own host registry (hostOptions) to its rows. The menus read it instead of building host options again, so they add no read of the focused host (focus-read-ratchet) and no per-card store subscription. Workspace cards outside the sidebar (the Kanban drawer, the folder workspace panel) get no registry, so their menus list names only, as today. A bare runtime id is not a name to show.
  • ProjectHeaderHostLabel takes an optional className. The menu passes max-w-48, because the label's max-w-1/2 clipped "Local Mac" in a shrink-to-fit menu row.

Why

Problem: a group is stored on one computer, and a row can join only its own computer's groups. The menu showed groups from every paired computer by name only. So picking the right group was guesswork, and a refused move came as a surprise. When two computers each had a group with the same name, the menu showed identical items, and one of them always refused.

Why this approach:

  • Label only, like project headers. It reuses the label and the host resolution that project headers already use for the same "which computer?" question, and it adds no routing decision.
  • Only when the groups span computers. This follows the rule workspace cards use for their computer chips, so one-computer setups stay as they are.
  • Menus, not group headers. In this window a group header can show projects whose rows are on other computers: the window copies a group onto other computers' copies of the same project (applyInheritedProjectGroups). A single machine label on the header would claim it owns them all. Keep project names short and show their machine #28250 rules that out for multi-machine projects and manual groups ("does not assign a singular owner to manual project groups"). In the menu the label describes the move target itself.

Alternatives considered:

Linked Issue

Closes #35499

Visual Proof

Two Orca apps ran in the background on main 79dbada2c8 and on this branch: a paired Electron client (Orca A) and a headless host (Orca B). Each added its own clone of demo-test with the same origin. Orca A created "Group A" and Orca B created "Group B". The images are CDP screenshots of Orca A's hidden window, with the card menu of Orca A's workspace open on Move to group.

main 79dbada2c8 this branch
main: Move to group lists Group A and Group B by name only This branch: Move to group shows Group A with Local Mac and Group B with Orca B; the sidebar group headers are unchanged

Text read from the rendered DOM:

# main 79dbada2c8
group headers         Group A | Group B
Move to group items   Group A | Group B

# this branch
group headers         Group A | Group B
Move to group items   Group A  Local Mac | Group B  Orca B

Testing

  • I manually tested these changes locally

  • Automated tests added/updated, or explained why not below

  • New ProjectGroupMoveMenuItems.test.tsx (real Radix menu): items name each group's computer when the groups come from two computers. They list only names when every group is on one computer, and outside the sidebar.

  • project-header-host-context.test.ts passes unchanged, including "does not assign a singular owner to manual project groups".

  • pnpm check:changed --maxWorkers=2 (format, lint, typecheck, affected tests, ratchets including focus-read-ratchet: 22 checks) passes.

  • pnpm test src/renderer/src/components/sidebar src/shared/sidebar-list: 3365 passed, 1 skipped (386 files).

  • npx electron-vite build --mode e2e succeeded on both commits for the E2E above; I did not run the full pnpm build locally.

  • Platforms: macOS (unit tests and the two-app background E2E above). The change is renderer-only with no platform branches.

AI Disclosure

Implemented with Claude Code (Claude Opus 5.5). Reviewed by GPT-6.1 Sol (xhigh reasoning).

  • Fixed: cards outside the sidebar would have labeled groups with raw runtime ids, because no host registry reaches them. They now list names only.
  • Not changed: the tests match item text, not the label's classes; the label is the existing ProjectHeaderHostLabel.

Review

Agent skill upstream boundary

  • Not applicable, or this change copies or mechanically translates no upstream skill-installer source, tests, fixtures, registry entries, path tables, comments, or documentation.

Notes

Ensure no issues in: Security, Cross-platform support (Linux, Windows, Mac), Remote SSH, Mobile, general backwards compatibility, performance

  • No IPC, RPC or persisted-state change, so mixed-version peers are unaffected.
  • SSH: a folder-scan group on an SSH target resolves to that ssh: host through the same resolver, with aliases canonicalized as for projects.
  • Mobile: the phone has no Move to group action, and it lists project groups per host screen (mobile/src/host-screen). No phone change.
  • Cost: labels are computed only while Move to group is open.
  • Overlap: fix(sidebar): place a multi-host project in the group any of its rows is in #34720 also edits the project header's Move to group list (repo-header-project-actions.tsx, to act on the row that placed the project). Whichever lands second needs a small rebase there.

Checklist

  • This PR is small and focused
  • I explained what changed and why (ELI5, the user-facing before/after, the mechanism, and why over the alternatives)
  • Before/after screenshots or videos attached for UI changes, or N/A with reason
  • Self-reviewed for correctness, security, and performance
  • Cross-platform, SSH/remote, and path/shortcut impact considered (or N/A)
  • pnpm lint, pnpm typecheck, pnpm test, and pnpm build pass (or CI will cover; local preferred)

🤖 Generated with Claude Code

A project group is saved on the computer that created it, and a project row
can join only its own computer's groups. The Move to group menus listed only
group names, so with groups from several paired computers (or the same name on
each) there was no way to tell them apart or to see why a move was refused.
When the listed groups come from more than one computer, each item now shows
that computer with the host label project headers use. Group headers stay
unlabeled: in this window a group can hold rows from several computers, and
a single machine label would claim it owns them all (stablyai#28250).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@greptile-apps

greptile-apps Bot commented Oct 29, 2026 •

Copy link
Copy Markdown

RetriggerView in GreptileConfidence Score: 5/5

[Low impact] The reviewed changes appear safe to merge.

Summary

Adds computer labels to “Move to group” targets when groups span computers.

  • Move-to-group menus name each target’s computer when groups span computers.

No new actionable issues were found in the changes since the previous review. No previous review threads were supplied.

Reviews (2) · Last reviewed commit: "fix(sidebar): label same-id group copies..." · Reviewed by Greptile

@coderabbitai

coderabbitai Bot commented Oct 29, 2026 •

Copy link
Copy Markdown
Contributor

Review in Change Stack →

No actionable comments were generated in the recent review.

Recent review info
Run configuration
  • Source mode: Auto
  • Repository: Unavailable
  • Branch: Unavailable
  • File: No configuration file from this repository applied
  • Commit: Unavailable
  • Layers: Repository UI
  • Review profile: CHILL
  • Plan: Advanced
  • Run ID: f51b7a9c-3f63-4ab1-90d5-7b742284e302
Commits

Reviewing files that changed from the base of the PR and between db430c3 and 37ba3cc.

Files selected for processing: 3
  • src/renderer/src/components/sidebar/ProjectGroupMoveMenuItems.test.tsx
  • src/renderer/src/components/sidebar/ProjectGroupMoveMenuItems.tsx
  • src/renderer/src/components/sidebar/worktree-list/rows/project-header-host-context.ts

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 6 remain after this review.

Walkthrough

The change adds host labels to project-group move targets when the groups resolve to more than one computer. A shared resolver supplies host contexts, and the virtualized sidebar provides host options to the move-menu component. The worktree context menu and repository project-actions menu both use that component. The current group remains disabled, and selecting another group calls the existing move callback. Tests cover labels for groups on different computers and name-only entries when host data is unavailable or groups share one computer.

Priority: Normal

Merge Risk: Low · up to 37ba3

Choosing a host-labelled duplicate group can appear successful while targeting the same-ID copy on the project’s host; this is a narrow follow-up risk.

Pre-merge checks: Passed 4 · Failed 1

Failed Failed checks: 1 warning

Check name Status Explanation Resolution
Docstring Coverage Warning Docstring coverage is 20.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documenta… Write docstrings for the functions missing them to satisfy the coverage threshold.
Passed Passed checks: 4 passed
Check name Status Explanation
Title check Passed The title "feat(sidebar): show which computer each Move to group target belongs to" matches the main change. The PR adds a computer label to each Move to group item when the groups span more than one …
Description check Passed The description follows the repository template. It includes ELI5, What Changed, Why, Linked Issue (Closes #35499), Visual Proof with before and after images plus DOM text, Testing with checked boxes …
Linked Issues check Passed Issue #35499 requires host labels for Move to group targets only when groups span computers. The changes add shared host resolution and getProjectGroupHostContexts, then use `ProjectGroupMoveMenuIte…
Out of Scope Changes check Passed The changes support #35499. The shared resolver removes duplicated host-label logic. The sidebar context reuses existing host options. The reusable menu component replaces two equivalent lists. The op…
Full details: Title check

Explanation

The title "feat(sidebar): show which computer each Move to group target belongs to" matches the main change. The PR adds a computer label to each Move to group item when the groups span more than one computer. The title is specific and in conventional commit form. It is 71 characters, which is within a normal length for a title.

Full details: Description check

Explanation

The description follows the repository template. It includes ELI5, What Changed, Why, Linked Issue (Closes #35499), Visual Proof with before and after images plus DOM text, Testing with checked boxes and test commands, AI Disclosure, Review and Agent skill boundary, Notes covering security, cross-platform, SSH, mobile, and performance, and the Checklist. The Testing section names macOS as the tested platform and lists the tests added. The Visual Proof section gives before and after images, so the UI change is covered. The Notes section covers the required areas. Minor gaps: the template asks for ELI5 and Why, and both are present. The Linked Issue uses a closing keyword with an actual issue number, which satisfies the outside-contributor rule. The description is complete.

Full details: Linked Issues check

Explanation

Issue #35499 requires host labels for Move to group targets only when groups span computers. The changes add shared host resolution and getProjectGroupHostContexts, then use ProjectGroupMoveMenuItems in both requested menus. The menu keeps all groups enabled except the current group, preserves the existing move callback and guard, and omits labels for single-host or non-sidebar contexts. The sidebar group headers remain unchanged. The added test covers multi-host labels, single-host lists, and missing host registries.

Full details: Out of Scope Changes check

Explanation

The changes support #35499. The shared resolver removes duplicated host-label logic. The sidebar context reuses existing host options. The reusable menu component replaces two equivalent lists. The optional label class supports the requested menu layout. Tests cover the new behavior. No unrelated persistence, IPC, platform, mobile, filtering, disabling, group-header, or duplicate-group feature is shown.

Full details: Docstring Coverage

Explanation

Docstring coverage is 20.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff with cyclomatic complexity of at least 2. Documentation-only edits and deletions within surviving functions are included; unchanged diff context and fully deleted functions are excluded. Analyzed 5 functions across 8 files.

Resolution

Write docstrings for the functions missing them to satisfy the coverage threshold.

  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

Comment @coderabbitai help to get the list of available commands.

@coderabbitai coderabbitai Bot left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1


Review info
Run configuration
  • Source mode: Auto
  • Repository: Unavailable
  • Branch: Unavailable
  • File: No configuration file from this repository applied
  • Commit: Unavailable
  • Layers: Repository UI
  • Review profile: CHILL
  • Plan: Advanced
  • Run ID: 3d7d7135-ba71-4fc0-8a4c-68f39c555dd5
Commits

Reviewing files that changed from the base of the PR and between b2feed0 and db430c3.

Files selected for processing: 8
  • src/renderer/src/components/sidebar/ProjectGroupMoveMenuItems.test.tsx
  • src/renderer/src/components/sidebar/ProjectGroupMoveMenuItems.tsx
  • src/renderer/src/components/sidebar/WorktreeContextMenuView.tsx
  • src/renderer/src/components/sidebar/sidebar-host-options-context.ts
  • src/renderer/src/components/sidebar/worktree-list/rows/ProjectHeaderHostLabel.tsx
  • src/renderer/src/components/sidebar/worktree-list/rows/project-header-host-context.ts
  • src/renderer/src/components/sidebar/worktree-list/rows/repo-header-project-actions.tsx
  • src/renderer/src/components/sidebar/worktree-list/viewport/VirtualizedWorktreeViewport.tsx

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 8 remain after this review.

…ately

Same-id copies of a group can sit on several computers (stablyai#30045). Keying the
menu labels by group id kept only the last copy's computer, so both items read
the same label, and the computer count could miss the copies entirely. Align
the labels with the listed groups by position, and key the items by host and
id so the copies are distinct React children.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Feature]: Show which computer each Move to group target is on

1 participant