Fix legacy installer updates and diagnostics

README.md

@@ -84,6 +84,10 @@ Der Datenaustausch ist bewusst defensiv:
   `UNKNOWN`-Snapshot und einen ungleich null lautenden Task-Exitcode.
 - Provider und Consumer protokollieren in tägliche Dateien; die Aufbewahrung
   ist standardmäßig 30 Tage.
+- Jeder Installations-/Updatelauf schreibt zusätzlich ein eigenes
+  `setup-*.log` mit Phase, Binary-Version, Self-Test-Ausgabe,
+  Task-Scheduler-Status, Exception-Kette und Rollback-Ergebnis. Kennwörter
+  werden nicht an das Logging übergeben.
 - Snapshotgröße, WMI-/SQL-Timeouts, Log-Retention und Stale-Grenze sind
   begrenzt und konfigurierbar.
 
@@ -263,19 +267,23 @@ als `UNKNOWN`.
 Ein gMSA kann über die Checkbox ohne Kennworteingabe installiert werden; die
 produktive Standardbeschreibung geht vom normalen Servicekonto aus.
 
-Der Installer:
+Der Installer (ab Version 2.2.5):
 
-1. prüft Paket und neun Self-Test-Zeilen, bevor der bestehende Task angehalten
-   wird,
+1. prüft Paket und Staging zwingend auf neun Self-Test-Zeilen, bevor der
+   bestehende Task angehalten wird. Der Servicevertrag der installierten
+   Legacy-Version darf weniger gültige Zeilen enthalten,
 2. baut die neue Version in einem Staging-Verzeichnis auf und übernimmt
    vorhandene AppSettings; neue Keys erhalten ihre neuen Defaults. Die alten
    unveränderten Endpoint-Defaults `12`/`500` werden auf `16`/`100` migriert,
-3. vergleicht installierten und neuen Checkmk-Servicevertrag; ein
-   unbestätigter Rename stoppt vor jeder Umschaltung,
+3. vergleicht installierten und neuen Checkmk-Servicevertrag. Rein additive
+   Services werden zugelassen und als Discovery-Hinweis gemeldet; entfernte
+   oder umbenannte Services stoppen ohne ausdrückliche Bestätigung vor jeder
+   Umschaltung,
 4. schaltet die Programmdateien per Verzeichniswechsel um,
 5. startet einen triggerlosen Provider-Abnahmelauf unter dem echten
    Collector-Konto und erzwingt einen vollständigen Endpoint-Katalogabgleich,
-6. wartet höchstens vier Minuten auf `LastTaskResult=0` und validiert danach
+6. wartet höchstens vier Minuten auf `LastTaskResult=0`, bricht bei einem
+   bereits abgeschlossenen Fehlerlauf sofort mit Dezimal-/Hexcode ab und validiert danach
    mit der Produkt-EXE einen erst nach Installationsbeginn erzeugten Snapshot,
    die Collector-Identität, alle neun eindeutigen Services ohne `UNKNOWN`
    sowie den frischen, maschinen- und umgebungsgebundenen Endpoint-Katalog,
@@ -283,7 +291,8 @@ Der Installer:
    werden vorherige Version, Wrapper und Task samt frischem Altsnapshot
    wiederhergestellt,
 8. behält `%ProgramData%\BizTalkCheckmkPulse` mit Endpoint-Katalog, Snapshot
-   und Logs bei,
+   und Logs bei. Das laufbezogene Setup-Log enthält auch die vollständige
+   Self-Test-Ausgabe sowie bei Abnahmefehlern die letzten Provider-Logzeilen,
 9. installiert EXE und Config nach `%ProgramFiles%\BizTalkCheckmkPulse`, setzt
    explizite ACLs für Administratoren, Provider und `LocalSystem` und
    installiert nur den kleinen `.cmd`-Consumer unter
@@ -306,8 +315,14 @@ Provider-Log:
 ```cmd
 dir /o-d "%ProgramData%\BizTalkCheckmkPulse\logs"
 type "%ProgramData%\BizTalkCheckmkPulse\logs\biztalk-checkmk-pulse-*.log"
+type "%ProgramData%\BizTalkCheckmkPulse\logs\setup-*.log"
 ```
 
+Die Analyse des in Version 2.2.4 beobachteten Abbruchs mit
+`Exitcode=0, Zeilen=8` ist in
+[docs/Installer-Self-Test-Analyse-2026-08-11.md](docs/Installer-Self-Test-Analyse-2026-08-11.md)
+dokumentiert.
+
 Snapshot und Consumer:
 
 ```cmd