a3ec2e55c8
`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>
1018 B
@fusion/engine
| @fusion/engine |
|---|
| patch |
fix(engine): never create task branches from arbitrary HEAD in autocorrect
attemptBranchAutocorrect previously fell back to git checkout -B <expected> with no start point when rename was not applicable. If the
worktree's HEAD happened to be at a previous occupant's commit (e.g. an
orphaned tip from a different task), the new branch label silently
captured that commit — the "branch: Created from HEAD" contamination
pattern that the cross-contamination guard then refuses to auto-resolve.
This is the only branch-creation site in the engine that did not thread
a resolved base SHA; every other path (prepareForTask,
reanchorBranchToBase) already passes the base explicitly.
Autocorrect now verifies the expected ref exists and uses a plain
git checkout, so it can only switch to an already-existing branch.
When the ref is missing it returns failed, letting upstream recovery
(which knows the proper base) re-anchor with prepareForTask /
reanchorBranchToBase.