Worktree Isolation

Ensure the current work happens in an isolated workspace, without disturbing the user's main checkout. Most coding harnesses now create a worktree by default at session start, so the common case is that isolation already exists — detect that first and do not create a redundant one.

Order of operations: detect existing isolation -> prefer a native worktree tool -> fall back to plain git. Never create a worktree the harness cannot see.

Two modes, set by the caller's need:

• New work (default). No specific ref named — create a fresh branch from a base (trunk). This is what ce-work uses.
• Isolate an existing ref. The caller names a ref to work on in isolation — a PR head, an existing branch, or a commit. Attach the worktree to that ref instead of creating a new branch. One hard git rule governs this mode: a branch can be checked out in only one worktree at a time. If the named ref is already checked out somewhere (most commonly because it is the current branch in the primary checkout), do not create a second worktree for it — report that it is already checked out at <path> and let the caller act (work there in place; or, only if a clean separate tree is essential, create a detached worktree at the same commit). Never put one branch in two worktrees.

The steps below (detect -> native tool -> git fallback) apply to both modes; the mode only changes what gets checked out and is reported back to the caller.

Step 0: Detect existing isolation

Before creating anything, check whether the current directory is already a linked worktree. Compare the resolved absolute git dir against the resolved absolute common git dir — resolve each to an absolute path first and compare those, not the raw git rev-parse output. Git mixes absolute and relative forms depending on the current directory (from a subdirectory of a normal checkout, --git-dir comes back absolute while --git-common-dir may be relative), so a raw string compare yields a false "already isolated":