Workspace navigator for repos with many jj workspaces

[rodion-m]

We use JayJay against repositories that regularly have many sibling jj workspaces (agent checkouts next to default). The current status-bar picker and Switch to palette items work when there are two or three workspaces and opening another window is fine.

They fall short when there are a dozen:

• the picker only shows names, so it is hard to tell which checkout holds which @
• Open / Switch to create or focus a window per path, so the desktop fills with nearly identical graphs
• there is no way to inspect another workspace’s @ vs parent without jj edit or opening it

Pinned repositories do not help here: these are workspaces of one repo, not separate remotes.

This is a direction question, not a request to reopen #143. You asked for an issue before layout/workflow work of this size.

What we are missing

1. See every workspace at a glance: name, @ description, file count vs parent, recency of that @.
2. Switch the current window to another workspace (or an equivalent that does not spawn a window per click).
3. Peek at another workspace’s committed @ without jj edit and without snapshotting every working copy on list refresh.

Prototype (fork only)

We tried a collapsible left Workspaces rail on CodeAlive-AI/agentic-jayjay to see if the workflow is even usable. Click rebinds this window; Open in New Window stays on the context menu. The list is jj workspace list --ignore-working-copy; timestamps and file counts come from the in-memory view, not a snapshot of each checkout.

Full window (default pinned with a trunk() chip; current workspace selected; @ description on the row and in the thin header):

Rail close-up:

That prototype is #143, which you closed — understood, and we are not asking to merge it.

Questions

Would any of this belong in JayJay?

• A. Keep one-workspace-per-window. Maybe only enrich the existing picker (description + file count + recency).
• B. An opt-in / hidden-by-default navigator of some kind, without making it the default chrome.
• C. This should stay a fork.

Happy to stop at discussion, or to reshape the prototype if one of those is interesting.

[hewigovens]

Thanks for the detailed issue and screenshots. I agree that workspace support needs more polish.
I’ve already found a few problems in the current experience:

• With multiple workspaces, the graph shows multiple empty working-copy commits without clearly identifying which workspace owns each one. These commits may be expected in jj’s model, but JayJay currently makes them confusing.
• Creating a workspace can fail to open it, particularly when a relative destination path is used.
• The existing workspace picker is too simple once a repository has more than a few workspaces.

I’m going to fix the correctness and clarity issues first, then think how we can enrich existing picker