the merge queue serializes worktree merges in dependency order, so two passing worktrees never run their merges concurrently. if a worktree's branch has drifted from main while the agent worked, bernstein attempts a 3-way merge; on conflict it triggers the resolver role with a prompt that includes both sides of the diff and the merge-base. if the resolver fails, the task moves to dead-letter rather than committing a botched merge (fail-closed). speculative worktrees (the optional plan-ahead mode) are rebased and re-gated before they enter the queue. source: src/bernstein/core/git/ and src/bernstein/core/orchestration/merge_queue.py.
canonical answer