source-control:babysit-prs: worker assigned a detached-HEAD worktree (branch checked out in a sibling worktree) + stale local branch behind origin — happy-path checkout/merge/push is unsafe

[kyle-sexton]

Category: operational

Context: Babysitting PR #456 in the assigned worktree .../worktrees/melodic-software__claude-code-plugins__pr-456.

Observed: The assigned worktree was in detached HEAD, not on the PR branch, because feat/373-babysit-safety-enhancements was already checked out in a sibling worktree (D:/repos/.../.claude/worktrees/373-babysit-enhancements). Additionally, that sibling's local branch ref was stale — it pointed at 632d739 (one commit behind), while origin/feat/373 and the PR head were at 4211d31.

Two concrete hazards from this state:

1. git checkout <pr-branch> in the assigned worktree fails (fatal: '<branch>' is already used by worktree at ...). A worker following a happy-path "checkout the branch, merge main, push" script dead-ends here.
2. The detached HEAD happened to be at the origin PR head (4211d31), so operating on it was safe — but had it been left at the stale local tip (632d739), a naive git merge origin/main + push would have silently reverted the newest branch commit (the advisory-alias fix) onto the PR. The safety of the operation depended on luck, not on a guard.

Workaround that worked this cycle: verify HEAD == origin/<pr-branch> (the true PR head), do the merge in detached HEAD, and push via explicit refspec git push origin HEAD:<pr-branch> rather than relying on branch checkout. Fast-forwarded 4211d31..48a3096 cleanly, no force.

Suggested direction: the worker/worktree setup should (a) explicitly assert the assigned worktree HEAD equals origin/<pr-branch> before any merge/edit (safety.md already says "re-check PR head SHA before editing/pushing" but does not cover the detached-HEAD/stale-local-branch worktree assignment), and (b) prefer refspec push over branch checkout so a branch locked by a sibling worktree is not a dead-end. Distinct from the existing safety.md "two open PRs sharing one head" guard — this is two worktrees sharing one branch.

Filed per babysit self-observation. Not blocking — PR #456's conflict was resolved and pushed successfully.

[kyle-sexton]

This was generated by AI during triage. · Category: operational (bug / worktree-safety) · Priority: priority: high (source-control north-star; a near-miss where a naive merge origin/main + push would have silently reverted the newest branch commit — safety depended on luck, not a guard). Routed status: ready.

Plan

A babysit worker was assigned a worktree in detached HEAD (the PR branch was checked out in a sibling worktree), and that sibling's local branch ref was stale (one commit behind origin). Two hazards: (1) git checkout <pr-branch> dead-ends (already used by worktree at …); (2) had HEAD been at the stale local tip instead of the origin head, a naive merge origin/main + push would have silently reverted the newest commit. This is distinct from safety.md's "two open PRs sharing one head" guard — here it's two worktrees sharing one branch.

Fix (behavioral contract):

• (a) Assert HEAD == origin/<pr-branch> before ANY merge/edit/push. safety.md already says "re-check PR head SHA before editing/pushing" but does not cover the detached-HEAD / stale-local-branch worktree-assignment case — extend it to assert the assigned worktree's HEAD equals the true origin/<pr-branch> head, refusing to operate on a stale local tip.
• (b) Prefer refspec push over branch checkout — git push origin HEAD:<pr-branch> (the workaround that worked this cycle: fast-forwarded cleanly, no force) so a branch locked by a sibling worktree is not a dead-end.

Acceptance

• A worker in a detached-HEAD assigned worktree whose HEAD ≠ origin/<pr-branch> STOPS/refuses rather than merging onto a stale tip.
• A worker whose PR branch is locked by a sibling worktree completes via refspec push, not a failing git checkout.
• No force-push introduced; the fast-forward-only invariant holds.

Distinct from #524 (worker-lease cross-session exclusivity) — that's which session may work the PR; this is the git mechanics of the assigned worktree being unsafe.

Decision defaulted: assert HEAD==origin/ before mutate + use refspec push (HEAD:<pr-branch>) instead of branch checkout — veto before merge

[kyle-sexton]

Confirming example, babysit lane, 2026-07-20: worker dispatched for PR #569 found the branch (feat/507-morning-ritual-dashboard) already checked out in a pre-existing sibling dev worktree (D:/repos/.../claude-code-plugins-issue-507, not the plugin's managed worktree root) — git refuses a second worktree on the same branch. Worker used the existing worktree directly (verified clean at head SHA first) rather than failing. No corruption resulted this time, but it confirms the gap: no plugin-native fallback exists for "branch already checked out elsewhere."

[kyle-sexton]

Claimed by tower overnight worker, 2026-07-21 ~17:xxZ. Implementing the defaulted contract: assert the assigned worktree HEAD equals origin/<pr-branch> (the true PR head) before any merge/edit/push — refuse to operate on a stale local tip — and prefer refspec push (git push origin HEAD:<pr-branch>) over branch checkout so a branch locked by a sibling worktree is not a dead-end; fast-forward-only, no force. Extending safety.md's existing head-SHA guard to cover the detached-HEAD / stale-local-branch worktree-assignment case. PR to follow (Closes #548).