docs(installer,worker): document Environment Checks + note unmerged prerequisite gap

Documents the Checks/ + SystemCheckPage feature (gating rule, check list,
FreshInstall-only placement) and the ExecutableResolver/.cmd-shim wiring in
ClaudeDo.Worker's ClaudeCliPreflight/ClaudeProcess. Adds docs/explore-notes/installer-preflight.md
(bumped/corrected against the actual implementation) and links it from the
explore-notes README and root CLAUDE.md.

The underlying code lives only on unmerged task branches (06aca9b3.../40272c0b...),
not on main yet, and two follow-up features ("Claude Help Me" button, Config-mode
Diagnose section) were never implemented because they blocked on that same missing
merge. Both gaps are called out explicitly in the new docs and in docs/open.md's
verification checklist, instead of being asserted as done.

docs/open.md

@@ -55,6 +55,7 @@ Offene Entscheidungen dazu:
 ## Beobachtung (offen — Entscheidung Mika)
 
 - **`--permission-mode auto` + Modell `haiku` → Writes werden denied:** Kontrolliert verifiziert (CLI 2.1.207): unter dem Default-Mode `auto` bekommt **sonnet** Writes auto-approved (`permission_denials:[]`), **haiku** wird `denied` (`permission_denials:[Write]`, keine Datei) — eine haiku-Task macht unter `auto` still nichts und landet ohne Änderung in `WaitingForReview`. Normalbetrieb (Default = sonnet) nicht betroffen. KEINE CLI-Regression, sondern modellabhängiges `auto`-Verhalten. Optionen falls es nervt: haiku aus der Auswahl nehmen, ODER Runner auf `acceptEdits`/`bypassPermissions` (modell-unabhängig). Mika: erstmal beobachten. Siehe Memory `auto_permission_haiku_footgun`.
+- **`QueueServiceTests.UsageGate_TransitionLogging_FiresOncePerChange` ist zeitbasiert flaky, unabhängig von dieser Session:** Schlägt reproduzierbar fehl (`Expected 1, Actual 0` Warn-Log-Aufrufe), sowohl solo (`--filter`) als auch im Vollauf, auf einem sauberen `git worktree add` gegen `main` (bdee731) — also **kein** durch diese Abschluss-Session verursachter Regress (die Session hat keine `.cs`-Datei angefasst). Ursache: der Test verlässt sich auf einen festen `Task.Delay(200)`, um mehrere 50-ms-Backstop-Ticks abzuwarten (Kommentar im Test: „Several backstop ticks (50ms interval) all observe the same blocked state"); auf einer stark ausgelasteten Maschine (hier: viele parallele ClaudeDo-Worktrees/Builds) reicht das Fenster nicht immer. Zum Vergleich: derselbe Test lief in einer zweiten, isolierten Verifikation (Scratch-Merge für den Environment-Checks-Task) sauber durch (876/876). Fix wäre ein Poll-basiertes Warten statt fixem Sleep — aber außerhalb des Scopes dieser Doku/Verifikations-Session (keine Code-Änderung angefasst).
 
 ---
 
@@ -137,6 +138,49 @@ verifiziert**:
   beim Laden übernommen und beim Speichern nur unverändert zurückgeschrieben (kein Clobber),
   aber nicht editierbar. Falls gewünscht, ein eigenes Feld ergänzen.
 
+## Offene Verifikation (2026-08-05, Environment Checks / SystemCheckPage)
+
+**Voraussetzung, bevor irgendeiner der Punkte unten geprüft werden kann:** die Branches
+`claudedo/06aca9b3afec4b939f59b627bfe21737` (Checks + SystemCheckPage) und
+`claudedo/40272c0bb3b14562b59c022d09c382b6` (ExecutableResolver-Wiring in
+`ClaudeDo.Worker`) müssen erst gemerged werden — sie lagen bei dieser Abschluss-Session
+noch nicht auf `main`. Build/Test-Nachweis unten stammt aus einer lokalen Scratch-Integration
+beider Branches, nicht aus `main` selbst. Details → `installer-preflight` in
+`docs/explore-notes/README.md` und den neuen Abschnitt „Environment Checks" in
+`src/ClaudeDo.Installer/CLAUDE.md`.
+
+**Zusätzliche Lücke, unabhängig vom Merge:** die zwei Folge-Tasks „Claude Help Me"-Button
+und Diagnose-Sektion (Config-Modus/`SettingsWindow`) sind **nicht implementiert** — beide
+liefen ins selbe Merge-Problem und wurden ohne jede Code-Änderung als `Blocked` beendet. Die
+folgenden Punkte, die diese zwei Features beträfen, können also noch nicht geprüft werden und
+brauchen zuerst eine neue Umsetzungsrunde:
+
+- [ ] „Claude Help Me" öffnet ein Terminal mit laufender Claude-Session, und die Session hat
+      den Diagnose-Report tatsächlich gelesen — **nicht umsetzbar, Feature existiert nicht.**
+- [ ] Der Help-Me-Button ist korrekt deaktiviert, wenn `claude` nicht im PATH ist, mit
+      verständlichem Tooltip — **nicht umsetzbar, Feature existiert nicht.**
+- [ ] Diagnose-Sektion im Config-Modus zeigt die echten installierten Pfade/Ports, und der
+      laufende Worker auf 47821 gilt nicht als Konflikt — **nicht umsetzbar, Feature existiert
+      nicht.**
+
+Sobald die beiden Branches oben gemerged sind, sind folgende Punkte real prüfbar (gebaut +
+unit-getestet gegen die Scratch-Integration, aber **nicht visuell verifiziert**):
+
+- [ ] SystemCheckPage: Layout, Icon-/Farbwirkung der vier Status (Ok grün / Warnung orange /
+      Fehler rot / Unbekannt grau — `StatusGreenBrush`/`StatusOrangeBrush`/`StatusRedBrush`/
+      `StatusGrayBrush`), Lesbarkeit der Hint-Texte, DE und EN.
+- [ ] Weiter-Button gesperrt bei einem echten blockierenden Fehler (z. B. `claude` nicht im
+      PATH → `claude-cli` Error/Failed), und der Grund ist in der Zusammenfassungszeile
+      sichtbar (nennt den/die blockierenden Check(s) namentlich).
+- [ ] „Erneut prüfen" wechselt einen Status live (z. B. git-Identity setzen → Warnung
+      verschwindet), ohne dass ein zweiter paralleler Lauf startet, wenn währenddessen erneut
+      geklickt wird.
+- [ ] Update-Modus zeigt die SystemCheckPage **nicht** (Wizard bleibt Welcome + Install).
+- [ ] Auf einem Rechner mit npm-installiertem `claude.cmd`: `claude-cli`-Check findet es
+      (Detail-Text „Resolved via a shim…"), und ein Task läuft im Worker durch (bestätigt, dass
+      `ClaudeProcess`/`ClaudeCliPreflight` den Shim über `cmd.exe /c` tatsächlich startet, nicht
+      nur, dass der Check ihn findet).
+
 ---
 
 ## Bewusst verworfen (nicht erneut vorschlagen)