- Hoist `refs/heads/<name>` into a single quoted token before the verify
call so the shell-quote boundary is unambiguous in the rendered
command.
- Append `--` to the recovery `git checkout` so a same-named tracked
path cannot win the DWIM resolution. The ref existence was already
verified, so this can only resolve as the branch.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Follow-up to a3ec2e55c addressing code-review feedback:
- Restrict the existence check to local heads via
`git show-ref --verify --quiet refs/heads/<name>` so a stray tag or
remote ref with the same name cannot satisfy the check and lead the
subsequent `git checkout` to a detached HEAD on the wrong object.
- Use `git branch -M` (force) instead of `-m` for the rename path so
case-only renames succeed on case-insensitive filesystems (macOS,
default Windows).
- Document the FN-5456 invariant on the function's doc comment.
- Add a real-git regression suite covering the three paths the fix
governs: no creation when expected ref is missing, switch-only when
it exists, and rejection of same-named tags.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
`attemptBranchAutocorrect` was the only branch-creation site in the
engine that ran `git checkout -B <expected>` without a start point.
When the worktree's HEAD was at a previous occupant's tip, the new
label silently captured that commit — the "branch: Created from HEAD"
contamination pattern that the cross-contamination guard then refuses
to auto-resolve (see FN-5456: orphan FN-5477 commit 268574b9a stranded
on fusion/fn-5456).
Replace the unsafe fallback with verify-then-`git checkout`: only switch
to an existing expected ref; return `failed` when it does not exist so
upstream recovery — which knows the proper base SHA — can re-anchor via
`prepareForTask` / `reanchorBranchToBase`.
Tests updated for the new command sequence; new case covers the
"expected ref missing → fail without creating from HEAD" guarantee.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
