Concurrent-session / worktree handling: adopting another session's PR; harmless --delete-branch local failure #45

Template gap

The loop assumes it is the only agent operating in the project working tree. When a concurrent session holds the tree and/or an open PR, two frictions arise:

1. Phase 1 treats an open PR as the loop's own; it has no guidance for adopting/landing (or closing) a PR authored by a concurrent session.
2. To avoid colliding with the other session's tree, work is done in a git worktree while the main checkout stays on main. gh pr merge --delete-branch then errors fatal: 'main' is already checked out at <path> during local cleanup — the merge and remote branch deletion still succeed, but the error looks like a failed merge.

Rule to add to the template

• Phase 1: add guidance for adopting an open PR from another author/session — bring it current with main, re-run full CI, review, merge if green (rather than misreading "don't open a new PR while one is open" as "do nothing").
• Phase 8 / Edge cases: under a worktree workflow, gh pr merge --delete-branch's local-branch deletion can fail harmlessly; verify merge state via gh pr view --json state and delete the remote branch separately rather than treating the error as a failed merge.

Consolidates (close on merge)

• example-|-dev-loop#8 — single-agent assumption breaks under concurrent sessions / worktrees

Consolidated upstream from per-loop self-audit findings. drafted by Claude on behalf of Daniel Stephenson