Arbeitspakete für V2.0 überarbeitet

docs/workpackages/M9 - Arbeitspakete.md

@@ -92,15 +92,7 @@ Ab M9 gilt verbindlich:
 - GUI-Code und JavaFX dürfen im **headless Pfad** nicht unnötig früh initialisiert oder geladen werden.
 - Fehlen GUI-Voraussetzungen beim tatsächlichen GUI-Start, ist das ein **kontrollierter GUI-Startfehler** mit klarer Rückmeldung.
 
-### 5. Logging-Basis und bestehender Log4j2-Stack
-
-Ab M9 gilt verbindlich:
-
-- Der GUI-Adapter nutzt denselben bestehenden Log4j2-Stack wie der headless Pfad.
-- Es wird **keine** zweite Logging-Konfiguration für die GUI eingeführt.
-- Logformat und Log-Pfad bleiben gegenüber dem bestehenden headless Betrieb unverändert.
-
-### 6. Plattformziel
+### 5. Plattformziel
 
 Ab M9 gilt verbindlich:
 
@@ -108,15 +100,7 @@ Ab M9 gilt verbindlich:
 - Der headless Betrieb bleibt für **Windows Server / Task Scheduler** kompatibel.
 - M9 führt noch keine GUI-Funktionalität ein, die gemappte Laufwerke oder Datei-Dialoge fachlich ausreizt; die technische Grundlage darf dem späteren Windows-zentrierten Pfadverhalten jedoch nicht widersprechen.
 
-### 7. Exit-Code-Semantik
-
-Ab M9 gilt verbindlich:
-
-- **`0`** für die normale erfolgreiche Beendigung eines headless Laufs sowie für das reguläre Beenden der GUI.
-- **`1`** für harte Start-, Bootstrap-, Verdrahtungs-, Konfigurations- oder Initialisierungsfehler, einschließlich ungültiger CLI-Verwendung, nicht existenter `--config`-Datei im headless Start und GUI-Startfehlern vor erfolgreicher Anzeige der Oberfläche.
-- Dokumentbezogene Verarbeitungsfehler des bestehenden headless Laufs verändern dieses Exit-Code-Modell nicht.
-
-### 8. GUI-Zielstand innerhalb von M9
+### 6. GUI-Zielstand innerhalb von M9
 
 M9 liefert **kein** vollständiges GUI-Produkt, sondern nur ein **technisch lauffähiges Grundgerüst**.
 
@@ -126,6 +110,27 @@ Daraus folgt:
 - Diese Shell dient nur dem Nachweis des GUI-Startpfads.
 - Ein echter Konfigurationseditor ist ausdrücklich erst Gegenstand von **M10**.
 
+### 9. GUI-Teststrategie
+
+Ab M9 gilt verbindlich für alle V2.0-Meilensteine:
+
+- **View-Modelle und Application-nahe GUI-Logik** werden mit JUnit unit-getestet. Testfokus liegt auf Zustandsübergängen, Validierungsregeln und Datenflüssen, nicht auf Rendering.
+- **GUI-Smoke-Tests** laufen unter **headless JavaFX (Monocle)** in der Maven-Test-Phase. Sie prüfen, dass zentrale GUI-Pfade (Start, Laden, grundlegende Interaktionen) technisch durchlaufen, ohne einen sichtbaren Desktop vorauszusetzen.
+- Es wird **kein TestFX** und **kein weiteres GUI-Testframework** über Monocle hinaus eingeführt.
+- Diese Teststrategie gilt als Referenz für alle testbezogenen Formulierungen in den Arbeitspaketen von M9 bis M13.
+
+### 10. JavaDoc-Standard für V2.0
+
+Ab M9 gilt verbindlich für alle V2.0-Meilensteine:
+
+Für jede **neu hinzugefügte** oder **substanziell geänderte** öffentliche Klasse, öffentliche Methode und jedes neue Java-Package gilt:
+
+- **Klassen-JavaDoc**: Zweck, Verantwortung und Abgrenzung der Klasse.
+- **Methoden-JavaDoc**: Zweck, Parameter, Rückgabewert und dokumentierte Ausnahmen.
+- **`package-info.java`**: pro neuem Package, mit Kurzbeschreibung der Paketverantwortung.
+
+Dieser Standard gilt als Bestandteil jedes „Fertig wenn"-Abschnitts in V2.0. Ein Arbeitspaket ist erst dann fertig, wenn die betroffenen öffentlichen Klassen und Methoden dem JavaDoc-Standard entsprechen.
+
 ---
 
 ## AP-001 Neues GUI-Modul und Maven-/Reactor-Basis einführen
@@ -142,7 +147,6 @@ Die Projektstruktur wird um ein eigenständiges GUI-Modul erweitert, ohne die be
 - Abhängigkeiten so schneiden, dass das GUI-Modul als **Inbound-Adapter** auf die bestehenden inneren Schichten aufsetzen kann.
 - JavaFX-Grundabhängigkeiten nur dort einführen, wo sie für das GUI-Modul technisch erforderlich sind.
 - Sicherstellen, dass Domain, Application, Adapter-Out und CLI-Adapter frei von JavaFX-Abhängigkeiten bleiben.
-- Sicherstellen, dass das GUI-Modul den vorhandenen Log4j2-Stack des Projekts ohne neue Logging-Konfiguration mitbenutzt.
 - Erste neutrale Paket- und Klassenstruktur im neuen Modul anlegen, soweit für einen buildbaren Stand nötig.
 - JavaDoc und `package-info` für die neue Modulverantwortung ergänzen.
 
@@ -207,7 +211,6 @@ Bootstrap kann zwischen GUI und headless sauber umschalten, ohne seine Verantwor
 - Bootstrap so erweitern, dass es abhängig vom geparsten Startmodus den passenden Inbound-Adapter startet.
 - Sicherstellen, dass der bestehende headless Pfad fachlich und technisch erhalten bleibt.
 - Kontrollierte Fehlerableitung für harte Startfehler ergänzen, soweit M9 dies bereits erfordert.
-- Exit-Code-Modell für V2.0 an die bestehende V1.1-/M7-Semantik anschließen: `0` für normale erfolgreiche GUI-/headless-Beendigung, `1` für harte Start-, Bootstrap-, Konfigurations- oder Initialisierungsfehler.
 - Behandlung des Konfigurationspfadbezugs im Bootstrap vervollständigen.
 - Sicherstellen, dass Bootstrap keine GUI-Fachlogik oder M10-Editorlogik aufnimmt.
 - JavaDoc und `package-info` für aktualisierte Bootstrap-Verantwortung ergänzen.
@@ -333,7 +336,7 @@ AP-001 bis AP-006 sind abgeschlossen.
 Der vollständige M9-Zielzustand wird automatisiert abgesichert und als konsistenter Übergabestand nachgewiesen.
 
 ### Muss umgesetzt werden
-- Tests für den GUI-Standardstart ergänzen, soweit im Projekt technisch sinnvoll automatisierbar.
+- Tests für den GUI-Standardstart gemäß der in M9 festgelegten GUI-Teststrategie ergänzen.
 - Tests für **`--headless`** ergänzen.
 - Automatisierten Nachweis ergänzen, dass der headless Start ohne Initialisierung der JavaFX-Application-Klasse durchlaufen kann.
 - Tests für **`--config <pfad>`** in beiden Startarten ergänzen.
@@ -343,8 +346,6 @@ Der vollständige M9-Zielzustand wird automatisiert abgesichert und als konsiste
   - `--config` ohne Wert.
 - Tests ergänzen, die belegen, dass headless ohne `--config` weiterhin das bisherige Default-Verhalten nutzt.
 - Smoke-Tests für die Artefakterzeugung und Packaging-Basis ergänzen.
-- Mindestens einen technischen Test ergänzen, der das GUI-Threadingmodell belegt, z. B. den Nachweis, dass der UI-Thread während eines simulierten langen Hintergrundvorgangs nicht blockiert.
-- Tests für das verbindliche Exit-Code-Modell von GUI- und headless Startpfad ergänzen, soweit im Projekt stabil automatisierbar.
 - Sicherstellen, dass dokumentbezogene Batch-Funktionalität nicht versehentlich regressiert ist.
 - Den M9-Stand abschließend auf Architekturtreue, Abwärtskompatibilität und Nicht-Vorgriff auf M10+ prüfen.
 
@@ -378,4 +379,4 @@ Die Arbeitspakete decken den vollständigen Zielumfang von **M9 – GUI-Grundger
 - Absicherung, dass headless ohne unnötige GUI-Initialisierung weiter nutzbar bleibt
 - Tests für Startverhalten, Fehlerpfade und Packaging
 
-Damit ist M9 bewusst klar von den späteren GUI-Funktionalitäten aus **M10** bis **M13** getrennt und liefert dennoch einen eigenständig lauffähigen, architekturtreuen und reviewbaren Zwischenstand.
+Damit ist M9 bewusst klar von den späteren GUI-Funktionalitäten aus **M10** bis **M13** getrennt und liefert dennoch einen eigenständig lauffähigen, architekturtreuen und reviewbaren Zwischenstand.