Allow endpoint warnings during setup acceptance

docs/ACC-Endpoint-Reachability-Analyse-2026-08-10.md

@@ -139,7 +139,7 @@ Endpoint-/Namensfix bewusst nicht grüngefärbt.
 
 ## ACC-Abnahme nach Installation
 
-1. Setup 2.2.5 als Update ausführen; Umgebung `ACC` kann bestehen bleiben.
+1. Setup 2.2.6 als Update ausführen; Umgebung `ACC` kann bestehen bleiben.
    Beim Wechsel von der fehlerhaften 2.2.1-Ausgabe `BizTalk ACC ...` auf die
    stabilen Namen die Rename-/Discovery-Checkbox bewusst aktivieren.
 2. In der installierten Config bestätigen:

docs/EndpointCatalog.md

@@ -21,6 +21,13 @@ Installer akzeptiert den Release erst, wenn der neue Synchronisationszeitpunkt
 nach dem Start dieses Laufs liegt. Gültige manuelle Overrides werden dabei
 erhalten; der Katalog wird nicht blind gelöscht.
 
+Ab Setup 2.2.6 blockiert ein technisch gültiger Abnahmelauf nicht mehr allein
+deshalb, weil `BizTalk Endpoint Reachability` fachlich `UNKNOWN` meldet. Die
+Installation wird mit einer sichtbaren Warnung abgeschlossen; Status, Metriken
+und Detailtext bleiben im Snapshot erhalten. Ein fehlender, ungültiger oder
+nicht in diesem Abnahmelauf synchronisierter Katalog bleibt dagegen ein harter
+Installationsfehler.
+
 Unabhängig vom Wochenabgleich wird bei jedem Minutenlauf gegen den aktuellen
 BizTalk-Runtimezustand gefiltert:
 

docs/Installer-Runtime-Unknown-Analyse-2026-08-11.md

@@ -0,0 +1,67 @@
+# Analyse: Runtime-Abnahme mit Endpoint-Reachability `UNKNOWN`
+
+## Beobachtung
+
+Setup 2.2.5 schaltete die neue Version um, startete den Provider erfolgreich
+und validierte danach die Runtime-Artefakte. Die Abnahme endete trotzdem mit:
+
+```text
+Runtime validation failed: Snapshot enthaelt unzuverlaessige UNKNOWN-Zustaende
+in stabilen Services. UNKNOWN=[BizTalk Endpoint Reachability].
+```
+
+Anschließend stellte der Installer die vorherige Version samt Task und frischem
+Snapshot erfolgreich wieder her.
+
+## Einordnung
+
+`LastTaskResult=0` belegt, dass der Providerlauf technisch abgeschlossen und
+ein Snapshot geschrieben wurde. Zusätzlich waren Snapshot-Zeitpunkt,
+SHA-256, Maschine, Collector-Identität, alle neun Servicenamen und der im
+Abnahmelauf synchronisierte Endpoint-Katalog valide. Das verbleibende
+`UNKNOWN` war daher kein Installations- oder Transaktionsfehler, sondern der
+fachliche Zustand der Endpoint-Prüfung.
+
+Der Endpoint-Service verwendet `UNKNOWN`, wenn die Prüfabdeckung nicht
+vollständig verlässlich ist, zum Beispiel bei einer nicht sicher auf
+Host/Port reduzierbaren aktiven Adresse, einem Katalog-/Probehinweis oder
+fehlendem manuellem Override. Diesen Zustand auf `OK` zu ändern würde die
+Monitoringlücke verbergen.
+
+## Korrektur in Version 2.2.6
+
+- Snapshot, Erzeugungszeit, Integrität, Maschine und Collector-Identität
+  werden unverändert strikt geprüft.
+- Alle neun stabilen Services müssen eindeutig vorhanden sein.
+- Bei aktivierter Endpoint-Prüfung muss der Katalog weiterhin im gestarteten
+  Abnahmelauf erfolgreich synchronisiert worden sein.
+- `UNKNOWN` in einem Kernservice bleibt ein Abnahmefehler.
+- Ausschließlich `BizTalk Endpoint Reachability = UNKNOWN` wird als
+  nicht blockierende Betriebswarnung akzeptiert.
+- Die vollständige UNKNOWN-Zeile erscheint in Setup-Ausgabe und Setup-Log und
+  bleibt unverändert im Snapshot für Checkmk erhalten.
+
+Damit wird die Installation abgeschlossen, ohne einen ungeklärten
+Monitoringzustand grünzufärben. Der normale Minutentask läuft weiter und die
+Endpoint-Ursache kann anhand von `unresolved_endpoints`,
+`catalog_or_probe_error`, `biztalk_endpoints_unresolved`, Katalog und
+Provider-Log gezielt bearbeitet werden.
+
+## Weiteres Vorgehen in ACC
+
+1. Setup 2.2.6 als Update ausführen und die ausgegebene
+   `RUNTIME_VALIDATION_WARNING` sichern.
+2. Im Snapshot die vollständige Zeile `BizTalk Endpoint Reachability` prüfen.
+3. Bei `unresolved_endpoints` Adapter, Artefakt und Grund auswerten und nur
+   bei einem tatsächlich externen Ziel einen geheimnisfreien manuellen
+   Override in `endpoints.xml` ergänzen.
+4. Bei `catalog_or_probe_error` zuerst Provider-Log und Katalog-XML prüfen.
+5. Nach der Bereinigung zwei Minutenläufe und den Checkmk-Agent-Dump prüfen.
+
+## Regressionstests
+
+- Ein isoliertes Endpoint-Reachability-`UNKNOWN` wird als Warnung akzeptiert
+  und sein vollständiger Detailtext bleibt erhalten.
+- `BizTalk Platform = UNKNOWN` bleibt blockierend.
+- Fehlender Service, alter Snapshot, falsche Identität und alter Katalog
+  bleiben blockierend.

docs/Integration.md

@@ -56,7 +56,11 @@ Verbindlicher Agent-Dump:
 Das Setup ab 2.2.4 schließt erst erfolgreich ab, nachdem der erste Providerlauf
 unter dem echten Collector-Konto einen frischen Snapshot und – bei aktivierter
 Endpoint-Prüfung – einen frisch synchronisierten Katalog erzeugt hat. Die neun
-stabilen Services müssen vollständig und ohne `UNKNOWN` vorliegen. Diese lokale
+stabilen Services müssen vollständig vorliegen. `UNKNOWN` in einem Kernservice
+bleibt blockierend. Ab Version 2.2.6 wird ein isoliertes
+`BizTalk Endpoint Reachability = UNKNOWN` als fachliche Betriebswarnung
+akzeptiert, sofern Snapshot, Identität und frisch synchronisierter Katalog
+valide sind. Die UNKNOWN-Zeile bleibt in Checkmk sichtbar. Diese lokale
 Runtime-Abnahme ersetzt nicht die zentrale Checkmk Service Discovery.
 
 `EnvironmentName` kennzeichnet Snapshot und Katalog, ändert die neun