Merge branch 'claudedo/75514ee68371402b814638290af47cca'

docs/explore-notes/review-merge.md

@@ -138,6 +138,23 @@ mid-merge conflicts **without re-starting the merge** and routes continue/abort
 `ContinuePlanningMerge` / `AbortPlanningMerge`, so a unit-merge conflict re-opens the editor
 per subtask via the `PlanningMergeConflict` broadcast.
 
+**Except when an MCP session is driving the merge.** `PlanningMergeOrchestrator.StartAsync` takes
+an `externallyDriven` bool (default `false`; `ExternalMcpService.review_task`'s parent-with-children
+path passes `true`, since a running Claude session — not the UI — will resolve conflicts via
+`continue_merge`/`abort_merge`). The flag rides along on the `PlanningMergeConflict` broadcast
+(4th arg); `IslandsShellViewModel.OnPlanningMergeConflict` only auto-opens the resolver when it's
+`false` — otherwise it shows a persistent, non-auto-dismissing banner
+(`IsExternalMergeBannerVisible`) with a manual "Open resolver" button, cleared on
+`PlanningMergeAborted`/`PlanningCompleted`. This exists because two parties (a human and the
+driving session) could otherwise end up editing the same shared checkout at once.
+`PlanningMergeOrchestrator.GetActiveExternalConflictsAsync` (hub: `GetActiveExternalPlanningMergeConflicts`)
+re-derives this state by checking `GitService.IsMidMergeAsync` rather than trusting the in-memory
+flag alone, so a UI restart mid-merge (or a stale entry left behind if something resolved the
+repo outside the normal Continue/Abort path) can't show a phantom banner — the Ui calls it on
+`ConnectionRestoredEvent`. The childless single-task conflict path
+(`TaskMergeService.ApproveAndMergeAsync`) has no equivalent broadcast — it only sends the generic
+`TaskUpdated` — so it never auto-opened the resolver and needed no change.
+
 ### View
 
 Three **AvaloniaEdit** panes showing the whole file: MAIN/ours (read-only) | editable Result |