Use worktrunk for worktrees instead of building our own?

[kaminskypavel]

Hey @webdevcody ,

Next on my list for worktrees is setup hooks, branch cleanup and a local merge. Before I build any of it, I think we should use worktrunk instead. It's a Rust worktree manager built for parallel agents, and it already has all of it.

My own pain, day to day: every new worktree means copying .env over by hand before the agent can run anything, and after deleting worktrees I end up cleaning out the branches they left behind myself. worktrunk handles both: wt step copy-ignored in a post-start hook copies .env (and other gitignored files) in, and removal takes the branch with it.

What we're missing today

• hooks live in git config, cover only create/delete, and time out after 30s
• new worktrees start cold: nothing copies .env, target/ or node_modules
• deleting a worktree always leaves the branch behind
• the path is fixed to <repo>-worktrees/<branch>
• no local merge

What worktrunk gives us

• hooks in the repo's .config/wt.toml for create, switch, commit, merge and remove, with approval for project hooks
• wt step copy-ignored copies build caches copy-on-write (their repo: 68s down to 3s for a new worktree)
• remove deletes the branch, but refuses unmerged work
• wt merge: squash, rebase, fast-forward, pre-merge gate
• a configurable worktree path

It isn't nebula-specific, so repos already set up for worktrunk work in nebula as is, and wt and nebula see the same worktrees. It's actively maintained (~8.8k stars, 18 releases since July), so we don't have to maintain a hook format, runner and merge flow ourselves.

Importing it

I checked it with a scratch crate: worktrunk = { version = "0.80", default-features = false } builds on our edition and toolchain, and adds 75 crates we don't have. The repo model, config, removal with branch cleanup and the copy-on-write code are public. The hook runner and merge are private to the wt binary. Max made the removal API public on request before (#2227), so I'd ask him to do the same for hooks. Until then we can call wt when it's installed.

Plan, in small PRs

1. Use worktrunk's removal so branches get cleaned up.
2. Read worktree-path from worktrunk's config, with our current layout as the default.
3. Run worktrunk hooks on create.
4. Maybe a merge key that runs wt merge in a pane.

Sync, adoption, relocation and PR status stay as they are.

Questions

1. OK with the dependency, or should we only shell out to wt?
2. Should project hooks show worktrunk's approval prompt, or should nebula pass --yes?
3. Do you want local merge in nebula, or PR-only?