docs(verification): §4 merge editor PASS end-to-end + UX findings (continue-btn, multi-file, blocked-merge)

docs/open.md

@@ -41,6 +41,9 @@ Kein Code-Aufwand, nur Durchspielen mit explizit notiertem Pass-Kriterium. Der G
 - **[NIT, 2026-07-24] Diff-Viewer: reiner Rename wird schwach dargestellt:** Rename wird korrekt erkannt (`UnifiedDiffParser` → `DiffFileStatus.Renamed`, Badge `StatusCode="R"`), aber der File-Tree zeigt nur den neuen Namen + „+0 −0" ohne „alt → neu"-Pfad; ein reiner Rename liest sich dadurch wie „keine Änderung". Kein Korrektheitsfehler, nur UX. Optional: alten Pfad + „renamed"-Label anzeigen.
 - **[MINOR, 2026-07-24] Header-TurnsText zeigt `0/max` für abgeschlossene Runs:** `TurnsText => {Turns}/{EffectiveMaxTurns}` — `Turns` wird beim Laden eines terminalen Tasks nicht aus `task_runs.turnCount` restauriert (nur live gefüllt), also erscheint `0/<max>`. Kosmetisch.
 - **[BUG, 2026-07-24] Approve & Merge schluckt einen „blocked"-Merge still:** `DetailsIslandViewModel.ApproveReviewAsync` reagiert nur auf `result.Status == "conflict"` (öffnet den Resolver); bei `"blocked"` (z.B. Ziel-Working-Tree hat uncommittete getrackte Änderungen) und anderen Nicht-`merged`/Nicht-`conflict`-Status passiert **nichts** — kein Footer-Fehler, kein Dialog (der `catch` greift nur bei Exceptions, „blocked" ist aber ein normaler Rückgabewert mit `ErrorMessage`). User sieht „Klick tut nichts". Verifiziert 2026-07-24 (Merge gegen dirty `main`-Checkout). Fix: bei `blocked`/unerwartetem Status `result.ErrorMessage` via `ShowErrorAsync`/`FlashFooterError` surfacen. Verstößt gegen `feedback_ui_error_surfacing`. (Der eigentliche Konflikt-Resolver + 3-Pane-Editor funktionieren, sobald der Ziel-Tree sauber ist.)
+- **[UX, 2026-07-24] Conflict-Resolver: Continue/Merge-Button ist klickbar, obwohl noch nicht alle Konflikte gelöst — Klick tut dann nichts:** Das Continue-Gate greift funktional (merged erst wenn alle Konflikte in allen Dateien gelöst), aber der Button ist optisch nicht disabled/gegraut, solange offene Konflikte bestehen; ein früher Klick ist ein stummer No-op. Besser: Button disabled bis `AllResolved`, oder Hinweis „N Konflikte in M Dateien offen". Verifiziert 2026-07-24 (§4-Walkthrough).
+- **[UX, 2026-07-24] Conflict-Resolver: Mehrere Konfliktdateien schlecht erkennbar:** Beim 2-Datei-Konflikt war schwer zu sehen, dass **zwei** Dateien betroffen sind (File-Switcher/Anzahl zu unauffällig). Prominentere Datei-Liste / „x von y Dateien" wäre besser. (§4-Walkthrough 2026-07-24.)
+- **[FEATURE-WUNSCH, 2026-07-24] Conflict-Resolver: farbliches Hervorheben eingefügter Zeilen im Result-Pane** (grüner „flow" der übernommenen Zeilen) fehlt — kein Bug, UI-Verbesserung (User-Wunsch).
 - **Status-Bar Live-Update:** Prüfen, ob `RunNow`-Enable/Disable pro Task-Row bei Connection-Change sauber re-evaluiert. Connection-Status lebt in `IslandsShellViewModel` / `WorkerConnectionModalViewModel` (es gibt keinen `StatusBarViewModel` mehr). Erst messen, dann ggf. fixen. Klein.
 
 ## Nachklapp Refactoring-/Bug-Runde (2026-06-09/10)

docs/verification-handoff.md

@@ -33,12 +33,15 @@ Konsolidierte manuelle Verifikationen aus `docs/open.md` + Memory-Ständen — g
 
 Konflikt provozieren: gleiche Datei auf main ändern, während der Task-Branch sie ändert. Beide Wege testen: **(a)** Single-Task-Approve mit Konflikt, **(b)** Planning-Unit-Merge mit Konflikt in einem Subtask (`PlanningMergeConflict` → Editor öffnet pro Subtask).
 
-- [ ] Drei Panes: MAIN read-only | Result editierbar | INCOMING read-only; Konfliktblöcke rot, aufgelöst grün, in allen Panes.
-- [ ] Gutter-Toggle `›`/`‹`: Seite rein/raus, Klickreihenfolge = Reihenfolge im Result; main/incoming/beide/keine möglich.
-- [ ] Nur Konfliktregionen im Result editierbar (Stable read-only); Edits fließen in den Block zurück.
-- [ ] Synchrones vertikales Scrollen; File-Switcher bei mehreren Dateien; `M conflicts · K resolved`-Readout; Conflict-Ruler (Klick springt).
-- [ ] Continue erst aktiv, wenn ALLE Konflikte in ALLEN Dateien gelöst; Binär-Guard greift.
-- [ ] Abort: Tree sauber, Task bleibt WaitingForReview.
+**Verifiziert 2026-07-24 (Single-Task-Approve mit Konflikt, 2 Dateien, `verif §4`): End-to-End PASS** — Approve→Konflikt→3-Pane-Resolver→beide Dateien auflösen→Continue→Merge→Task Done (Merge-Commit gelandet). ⚠ **Vorbedingung-Fund:** ein dirty Ziel-Working-Tree (getrackte uncommittete Änderung) blockt den Merge und Approve schluckt das **still** (s. open.md „Approve & Merge schluckt blocked"). Planning-Unit-Merge-Konflikt (Weg b) noch offen → §3.
+
+- [x] Drei Panes: MAIN read-only | Result editierbar | INCOMING read-only; Konfliktblöcke rot, aufgelöst grün, in allen Panes. — **PASS**.
+- [x] Gutter-Toggle `›`/`‹`: Seite rein/raus, Klickreihenfolge = Reihenfolge im Result; main/incoming/beide/keine möglich. — **PASS**.
+- [x] Nur Konfliktregionen im Result editierbar (Stable read-only); Edits fließen in den Block zurück. — **PASS**.
+- [~] Synchrones vertikales Scrollen; File-Switcher bei mehreren Dateien; `M conflicts · K resolved`-Readout; Conflict-Ruler (Klick springt). — **PASS**, aber **Multi-File schlecht erkennbar** (2 Konfliktdateien schwer zu sehen — UX-Nit, open.md).
+- [~] Continue erst aktiv, wenn ALLE Konflikte in ALLEN Dateien gelöst; Binär-Guard greift. — **funktional PASS** (merged erst nach Auflösung beider Dateien), aber **Button ist klickbar statt disabled** solange offen → stummer No-op (UX-Bug, open.md). Binär-Guard hier n/a.
+- [ ] Abort: Tree sauber, Task bleibt WaitingForReview. — **nicht getestet** (User wählte Continue/Merge). Offen.
+- [FEATURE-WUNSCH] farbliches Hervorheben der übernommenen/eingefügten Zeilen im Result-Pane (open.md).
 - Bekannte Kanten (nur gegenprüfen, nicht als Fail werten): leere Ours-Seite → null-lange Result-Region (Accept geht, Handtippen fummelig); Gutter-Y-Ausrichtung bei sehr hohen Fenstern/großem Scroll; vertikaler Drift nachfolgender Blöcke nach Konflikt mit ungleicher Zeilenzahl.
 
 ## 5. Embedded ConPTY / Mission Control