Problem
Project groups can only be created/managed through the desktop UI. There is no CLI surface to create a project group or move a project into one. This blocks headless / agent-orchestration workflows: when you register several repos via the CLI (e.g. orca project setup-existing-folder for an umbrella repo plus its child repos), the project list becomes a flat, ungrouped clutter and there is no scriptable way to organize it.
What already exists (so this is mostly a surfacing task)
The data model and mutation logic are already implemented — only the runtime RPC + CLI entry points are missing:
- Store methods already present:
store.createProjectGroup(...), updateProjectGroup(...), deleteProjectGroup(...), moveProject(...).
- IPC handlers already wire them up for the desktop UI:
projectGroups:create / :update / :delete / :moveProject in src/main/ipc/repos.ts.
- Runtime RPC already exposes read-only
projectGroup.list (src/main/runtime/runtime-rpc.ts), but no create/move method.
- CLI has
project command specs/handlers (src/cli/specs/project.ts, src/cli/handlers/project.ts) but nothing under project group.
So projectGroups in the persisted data starts as [] and there is no non-UI way to populate it.
Proposal
Add runtime RPC methods that mirror the existing IPC handlers, plus CLI commands:
orca project group create <name> [--parent-path <path>] [--json]
orca project group list [--json]
orca project group add --project <selector> --group <id> [--json] # wraps moveProject
orca project group rm --group <id> [--json]
Implementation sketch:
src/main/runtime/rpc/methods/ — add projectGroup.create / projectGroup.moveProject (and optionally update/delete) calling the same store.* methods the IPC handlers use.
src/cli/specs/project.ts + src/cli/handlers/project.ts — add the group subcommands.
- Keep
registry-parity tests green.
Related (UI-side, not CLI)
I'm happy to open a PR for this.
Problem
Project groups can only be created/managed through the desktop UI. There is no CLI surface to create a project group or move a project into one. This blocks headless / agent-orchestration workflows: when you register several repos via the CLI (e.g.
orca project setup-existing-folderfor an umbrella repo plus its child repos), the project list becomes a flat, ungrouped clutter and there is no scriptable way to organize it.What already exists (so this is mostly a surfacing task)
The data model and mutation logic are already implemented — only the runtime RPC + CLI entry points are missing:
store.createProjectGroup(...),updateProjectGroup(...),deleteProjectGroup(...),moveProject(...).projectGroups:create/:update/:delete/:moveProjectinsrc/main/ipc/repos.ts.projectGroup.list(src/main/runtime/runtime-rpc.ts), but no create/move method.projectcommand specs/handlers (src/cli/specs/project.ts,src/cli/handlers/project.ts) but nothing underproject group.So
projectGroupsin the persisted data starts as[]and there is no non-UI way to populate it.Proposal
Add runtime RPC methods that mirror the existing IPC handlers, plus CLI commands:
Implementation sketch:
src/main/runtime/rpc/methods/— addprojectGroup.create/projectGroup.moveProject(and optionally update/delete) calling the samestore.*methods the IPC handlers use.src/cli/specs/project.ts+src/cli/handlers/project.ts— add thegroupsubcommands.registry-paritytests green.Related (UI-side, not CLI)
I'm happy to open a PR for this.