refactor: decompose DepartureNotificationHandler into specialized helper methods and update project documentation with process diagrams

04_Dokumentation/DOKUMENTATIONS GERUEST.md

@@ -33,10 +33,32 @@ Das Ziel des Projekts ist die Optimierung und Stabilisierung der Auftragsverarbe
 
 ## 3. Analyse & Konzept (Bewertung: Ausgangssituation)
 ### 3.1 Ist-Analyse
-*Detaillierte technische Beschreibung des aktuellen Problems (Race Condition zwischen OrdersHost und ConveyorDispo).*
+Die technische Ist-Analyse der Quellcode-Basis von GEBHARDT StoreWare identifizierte zwei Haupttypen von Race Conditions, die durch die dezentrale Logik-Hoheit verursacht werden:
+
+#### A. Technische Race Condition (Status-Konflikt bei Neuanlage)
+Trifft eine `DepartureNotification` für eine unbekannte Ladeeinheit (LE) ein, erzeugt der `DepartureNotificationHandler` im Prozess `HostBooking` einen neuen `OrdersHost`-Eintrag im Status `Initial`.
+* **Fehlerablauf:** Noch während der Handler-Durchlauf aktiv ist, sendet er ein Start-Telegramm an die SPS. Parallel dazu identifiziert der zyklische Worker `StartInitialOrdersHost` (Teil des Prozesses `ConveyorDispo`) den neuen `Initial`-Eintrag und initiiert seinerseits einen Startvorgang.
+* **Folge:** 
+  - **Telegramm-Kollision:** Die SPS erhält zeitnah zwei Start-Befehle für dieselbe LE, was zu Fehlsteuerungen führt.
+  - **Datenbank-Inkonsistenz:** Beide Prozesse versuchen simultan den Datensatz zu aktualisieren, was zu `DbUpdateConcurrencyExceptions` führt. Der Auftrag verbleibt oft in einem inkonsistenten Status ("Auftragsleiche").
+
+#### B. Architektonische Race Condition (Umgehung der Ressourcenprüfung)
+Befindet sich ein Behälter im Status `InDestinationZone` (kurz vor dem Ziel), greift eine Sonderlogik für Sequencer-Anbindungen.
+* **Fehlerablauf:** Der Handler im `HostBooking` ändert eigenmächtig das Ziel auf den `ConnectedSequencer` und erzwingt mittels `ForceSetStatusInProgress` den physischen Start.
+* **Folge:** 
+  - **Kapazitäts-Blindheit:** Da dieser Start am zentralen `ConveyorDispo` vorbeigeschleust wird, findet keine Prüfung der Sequencer-Auslastung (Throttling) statt. Die physische Kapazität des Sequencers wird überschritten, was zu Anlagenstaus und Deadlocks im Materialfluss führt.
 
 ### 3.2 Soll-Konzept
-*Definition der funktionalen und nicht-funktionalen Anforderungen.*
+Das Ziel des Soll-Konzepts ist die Überführung der dezentrale Start-Logik in eine monolithische Architektur innerhalb des `ConveyorDispo`.
+
+**Funktionale Anforderungen:**
+- **Exklusivität:** Nur der Prozess `ConveyorDispo` darf den Status eines `OrdersHost`-Auftrags von `Initial` (oder einem neuen Zwischenstatus wie `ReadyToStart`) auf `InProgress` ändern und das entsprechende Start-Telegramm senden.
+- **Entkopplung:** Der `DepartureNotificationHandler` wird zum reinen "Event-Melder" refactored. Er aktualisiert den physischen Ort der LE und setzt den Auftragsstatus lediglich auf `Initial`, um den Startwunsch für den `ConveyorDispo` zu signalisieren.
+- **Zentralisierung:** Alle Start-Entscheidungen (inkl. Sequencer-Anbindung und Ressourcenprüfung) werden im `OrderManager` des `ConveyorDispo` konsolidiert.
+
+**Nicht-funktionale Anforderungen:**
+- **Datenintegrität:** Eliminierung von `ConcurrencyExceptions` durch klare Zuständigkeitstrennung.
+- **Wartbarkeit:** Reduzierung von redundantem Code (DRY) und Beseitigung von "Sonderlocken" in den Handlern.
 
 ### 3.3 Wirtschaftlichkeitsbetrachtung
 *ROI-Analyse: Wie viel kostet der Fehler aktuell? Wie schnell amortisiert sich die Entwicklung?*