Worktree-first review flow for parallel agent sessions (exploration)

[jonassaa]

Exploration, not a spec. Opening it to capture evidence found during the
competitor research sweep, because it points at an unoccupied niche that sits
almost exactly on top of features we already shipped.

The observed behaviour

Developers now run several coding agents in parallel, each in its own git
worktree, and the hard part has moved from writing the code to reviewing and
reconciling what came back. From Hacker News:

• "I purchased GitKraken, because they have a decent automated 'AI' merge conflict
  resolution tool. My use case is resolving conflicts from multiple parallel coding
  agent sessions." — someone buying a git GUI specifically for this.
• "VS Code Copilot workflows use git worktrees for AI-generated code changes,
  allowing step-by-step review of modifications before integration."
• "if you can review things in GitKraken or another program with diffs, things are
  closer to what you want" — on catching LLM slop before it lands.
• "AI agents successfully built a specialized GUI git client for managing 200
  monorepo submodules" — people building throwaway tooling because nothing fits.

This is also, concretely, how this repository is developed: every assistant session
gets its own worktree under .claude/worktrees/, per CLAUDE.md.

Why we are unusually well placed

We already have, shipped: worktrees (#93), multi-repo tabs (#90), a conflict
resolver in its own window with a file list (#108), branch compare (#131), fast
windowed diffs, and multi-select commits. The pieces of "compare and reconcile
several parallel lines of work" exist — they are just not pointed at this.

And the constraint that makes incumbents awkward here is one we don't have: the
tools currently serving this are cloud/account/subscription products, while this
workflow is intensely local — the worktrees are on your disk.

Possible directions, cheapest first

• Make worktrees a first-class surface rather than a management screen. See all
  worktrees for a repo with, for each: branch, ahead/behind, dirty state, last
  commit. Switch and compare between them without leaving the app. This is mostly
  presentation over data we already fetch, and it is useful to anyone using
  worktrees at all — no AI framing required.
• Diff two worktrees / branches side by side, extending Branch compare — diff branch↔branch and branch↔working tree #131's compare.
• A review-oriented pass over an unfamiliar diff: "what changed here, in what
  order, what should I look at first". Bigger, vaguer, needs its own design.

Open questions to settle before any of this becomes a plan

• Is this a real audience or a temporary one? The workflow is ~18 months old.
• Does it need anything AI-specific at all, or is "excellent worktree support" the
  whole product? The first bullet is valuable either way, which argues for doing
  that first regardless of the answer.
• Anything model-backed collides with Pin the "no telemetry, no account" promise with a guard test #226's no-account/no-telemetry promise unless
  it is local-only or explicitly opt-in with the user's own key. That promise is
  worth more than this feature; it constrains the design rather than the reverse.

Suggested next step: do the worktree-surface bullet, which stands on its own merits,
and let the rest wait for evidence.

From the competitor research sweep (Aug 2026).

[jonassaa]

Tightening one line in the body above. It said anything model-backed is fine if it is "local-only or explicitly opt-in with the user's own key". Having now checked the exact published wording, opt-in with your own key is not sufficient: README.md:58 and site/src/pages/index.astro:104 both state unconditionally that "your repositories and history never leave your machine", and README.md:88 gives an exhaustive outbound-traffic list (git remotes, the update check, configured forge APIs). An opt-in cloud call still contradicts both. Only genuinely local inference (Ollama / LM Studio) preserves them as written — and note a locally installed agent CLI like Claude Code or Codex is cloud-backed, so it does not count as local. Whatever gets decided on #250 governs here too; this issue should inherit it rather than decide separately.