B-0H4P-sdlc-backlog-create-strands-the-caller-s-checkout-on-backlog
Status: promoted/task
sdlc backlog create leaves the caller’s working checkout stranded on the rolling backlog-capture
branch and does not restore it.
Root cause — manageBranch() in plugin/cli/backlog_cli/create.ts:252-270 runs
git checkout -B backlog-capture <base> (line 257 open-PR path; line 267 no-open-PR path) to move
onto the rolling branch, commits + pushes the new backlog file there, and never switches back to
the caller’s original branch. There is no save-current-branch/restore and no worktree- or temp-index
isolation; the tail assumes a throwaway/CI context.
Impact — run from (or resolving against) a real working checkout that is on main, it strands
that checkout on backlog-capture. Any uncommitted changes are git-autostashed to permit the
checkout and are also not restored, leaving an orphan autostash entry. Observed 2026-06-09: a
routine /sdlc:backlog-capture left the primary main checkout on backlog-capture with the
working-tree dirt parked in a stash; manual recovery (switch back to main, recover the stash) was
required. The tail is also not git-worktree-aware, so running it from an isolated worktree does NOT
confine the checkout — it still hits the primary working tree.
Proposed fix — isolate the tail’s git ops so they never touch the caller’s checkout: either (a)
create a scratch git worktree add for the rolling branch, do the commit/push there, and
git worktree remove it; or (b) record the caller’s branch + autostash before the checkout and
deterministically restore both in a finally-style guard
(branch=$(git symbolic-ref --short HEAD); ...; git checkout "$branch"; git stash pop if it
stashed). Add a regression test asserting the caller’s HEAD/branch and working tree are unchanged
after create.