# AI-Maintainer-Handoff

## Projekt und Sicherheitsziel

Das Repository enthält ein .NET-Framework-4.6.1-WinForms-Tool für kontrollierte BizTalk-2020-Wartungsoperationen. Änderungen müssen Dry-run, explizite Freigabe realer Aktionen, sichere Reihenfolgen und wiederherstellbare Installergrenzen erhalten. Die aktuelle Produktversion ist 2.2.2.

## Installerinvarianten

- Vor der ersten Mutation müssen Manifest, Länge, SHA-256 und Staging-Self-Test erfolgreich sein.
- Eine laufende installierte Anwendung blockiert Update und Deinstallation.
- Ein Update darf die aktive Vorversion erst nach erfolgreichem Staging verändern.
- Das Backup einer bestehenden Installation wird nur atomar per `Directory.Move` erzeugt. Bei dauerhaftem Fehler bleibt die Vorversion aktiv; es gibt keinen In-place-Kopierfallback.
- Nur eine Neuinstallation ohne bestehendes Ziel darf nach ausgeschöpften Move-Retries eine erneut SHA-256-geprüfte Kopie aktivieren.
- Nach jeder Aktivierungsart läuft der Self-Test erneut aus dem endgültigen Installationsziel.
- Sobald ein Zielverzeichnis teilweise angelegt sein kann, muss `activated=true` gesetzt sein, damit der Catch-Pfad es entfernt.
- Windows-Integration wird erst nach bestandenem Ziel-Self-Test verändert und bei Folgefehlern aus dem Snapshot restauriert.
- Diagnose-Logging darf das eigentliche Setup-Ergebnis nie ersetzen.

Die zentrale Implementierung liegt in `src/BizTalkPlatformManagementTool.Setup/InstallerEngine.cs`. Move-Retries sind auf acht Versuche und 19,75 Sekunden Wartezeit begrenzt. Die injizierbaren `directoryMover`- und `retryDelay`-Delegates existieren ausschließlich, damit Sperrpfade ohne echte Wartezeit portabel getestet werden können.

## Runtime- und Recovery-Invarianten

- Ein isolierter WMI-, Adapter- oder Servicefehler darf keine späteren unabhängigen Planschritte verhindern.
- Teilfehler werden vollständig pro Schritt persistiert; der Gesamtlauf bleibt sichtbar fehlgeschlagen und darf nicht als Erfolg ausgegeben werden.
- Vor jeder Mutation wird der aktuelle Zustand geprüft. Bereits erreichte Sollzustände werden ohne Methodenaufruf als `AlreadySatisfied` erfasst.
- Der Nachher-Snapshot wird unabhängig von Einzelfehlern versucht; sein Fehler gehört in denselben Ergebnisreport.
- Shutdown-Kategorien gelten global über alle Anwendungen: Receive Locations, Orchestrations, Send Ports, Host Instances.
- Restore-Kategorien gelten global über alle Anwendungen: Host Instances, Send Ports, Orchestrations, Receive Locations.
- Emergency Restore überschreibt niemals die Eingabe-`before.json`, erzeugt eine timestamp-basierte Kopie und stellt `ENTSSO` vor Host Instances sicher.
- Emergency Restore muss mit genau einer validen `before.json` funktionieren; Dateien eines vorherigen fehlgeschlagenen Laufs dürfen keine Voraussetzung sein.
- Ein älterer kompatibler Snapshot, insbesondere aus 2.1.3, darf nicht allein anhand seines `ToolVersion`-Werts abgelehnt werden.
- Der echte Emergency Restore erzeugt nach Möglichkeit automatisch einen timestamp-basierten Soll/Ist-Diff aus Recovery-Quelle und Nachher-Snapshot.
- Die zentrale best-effort Orchestrierung liegt in `OperationPlanExecutor`; die WMI-/Service-Zustandsprüfung bleibt im produktiven Runtime-Adapter.
- Datei-Logging und optionale GUI-Logweiterleitung sind Diagnosekanäle und dürfen niemals einen fachlichen Planschritt oder dessen Fehlerbehandlung unterbrechen.

## Versionierung

Bei einem Release sind mindestens diese Stellen konsistent zu ändern:

- `InstallerEngine.ProductVersion`
- Setup-Titel in `MainForm`
- beide `Properties/AssemblyInfo.cs`
- beide `app.manifest`
- `BizTalkOperationService.Version`
- `CHANGELOG.md`

## Verifikation

Portable Befehle:

```sh
msbuild BizTalkPlatformManagementTool.sln /t:Rebuild /p:Configuration=Release '/p:Platform=Any CPU' /m:1
mono tests/BizTalkPlatformManagementTool.Tests/bin/Release/BizTalkPlatformManagementTool.Tests.exe
mono src/BizTalkPlatformManagementTool/bin/Release/BizTalkPlatformManagementTool.exe --self-test
mono src/BizTalkPlatformManagementTool.Packager/bin/Release/BizTalkPlatformManagementTool.Packager.exe . Release
```

Nach der Paketierung müssen ZIP, Base64-TXT und SHA-256-Datei gegengeprüft werden. Die abschließende Freigabe braucht zusätzlich einen repräsentativen Windows-/ACC-Test von UAC, `Program Files`-ACL/EDR, Registry, Verknüpfungen, Update, Rollback und Deinstallation sowie BizTalk-Diagnose und Dry-run.