polyphony branch ensure-feature fails when branch is checked out in a sibling worktree
Symptom
polyphony branch ensure-feature --branch feature/3043 exits 3 with:
fatal: 'feature/3043' is already used by worktree at 'C:/Users/dangreen/projects/polyphony-item-3043'
When invoked from the main worktree while the branch is checked out at a sibling worktree (the polyphony parallel-fleet convention).
Why it matters
The verb's purpose is "make sure feature/{apex_id} exists". Existence IS satisfied — the branch is there, in another worktree. Bubbling git's checkout error is over-strict UX: the verb should either succeed silently (branch confirmed to exist) or emit a structured friendly hint pointing at the worktree path.
Live impact: blocks apex-driver's preflight whenever conductor is launched from a directory that doesn't own the apex worktree. Surfaced during apex #3043 iter 14 relaunch. Compounded with #209 (gh stdin hang) when the failure cascaded to a gate that crashed (#210).
Suggested behavior
Two acceptable resolutions:
-
Idempotent success. Detect the "already used by worktree" git error. Treat as success. Include worktree_path in the success envelope so workflow consumers can route to it if they want.
-
Structured friendly error. Emit error_code: branch_in_other_worktree with worktree_path in the routing-style envelope, so the gate can give the operator an actionable next step ("cd <path> and relaunch from there").
Option 1 is simpler and matches the verb's stated purpose. Option 2 is more correct if we want the workflow to be aware that "the branch isn't currently MY checkout".
Related
polyphony branch ensure-featurefails when branch is checked out in a sibling worktreeSymptom
polyphony branch ensure-feature --branch feature/3043exits 3 with:When invoked from the main worktree while the branch is checked out at a sibling worktree (the polyphony parallel-fleet convention).
Why it matters
The verb's purpose is "make sure feature/{apex_id} exists". Existence IS satisfied — the branch is there, in another worktree. Bubbling git's checkout error is over-strict UX: the verb should either succeed silently (branch confirmed to exist) or emit a structured friendly hint pointing at the worktree path.
Live impact: blocks apex-driver's preflight whenever conductor is launched from a directory that doesn't own the apex worktree. Surfaced during apex #3043 iter 14 relaunch. Compounded with #209 (gh stdin hang) when the failure cascaded to a gate that crashed (#210).
Suggested behavior
Two acceptable resolutions:
Idempotent success. Detect the "already used by worktree" git error. Treat as success. Include
worktree_pathin the success envelope so workflow consumers can route to it if they want.Structured friendly error. Emit
error_code: branch_in_other_worktreewithworktree_pathin the routing-style envelope, so the gate can give the operator an actionable next step ("cd<path>and relaunch from there").Option 1 is simpler and matches the verb's stated purpose. Option 2 is more correct if we want the workflow to be aware that "the branch isn't currently MY checkout".
Related