Arbeitspakete für V2.0 überarbeitet

docs/workpackages/M13 - Arbeitspakete.md

@@ -115,13 +115,12 @@ Keine. Dieses Arbeitspaket ist der M13-Startpunkt.
 Der V2.0-Betrieb wird für Benutzer und Betreiber klar, widerspruchsfrei und vollständig beschrieben.
 
 ### Muss umgesetzt werden
-- README bzw. vorhandene Start-/Betriebsdokumentation gezielt auf den V2.0-Stand erweitern.
+- Die bestehende Betriebsdokumentation **`betrieb.md`** sowie ggf. vorhandene README-Dateien gezielt auf den V2.0-Stand erweitern.
 - Mindestens folgende Punkte klar und konsistent dokumentieren:
   - gemeinsames ausführbares JAR,
   - GUI als Standardstart,
   - `--headless`,
   - `--config <pfad>`,
-  - Exit-Code-Modell von V2.0 mit `0` für normale erfolgreiche GUI-/headless-Beendigung und `1` für harte Start-, Bootstrap-, Konfigurations- oder Initialisierungsfehler,
   - Verhalten bei fehlender oder ungültiger Konfiguration,
   - Verhalten bei GUI-Startfehlern,
   - Windows-Bezug und gemappte Laufwerke.
@@ -143,7 +142,46 @@ Der V2.0-Betrieb wird für Benutzer und Betreiber klar, widerspruchsfrei und vol
 
 ---
 
-## AP-002 Konfigurationsbeispiele, Standardvorlage und Prompt-Bezug für den V2.0-Endstand konsolidieren
+## AP-002 Endbenutzer-Bedienanleitung der V2.0-GUI erstellen
+
+### Voraussetzung
+AP-001 bis AP-006 sind abgeschlossen.
+
+### Ziel
+Die V2.0-GUI erhält eine eigenständige, deskriptive Bedienanleitung, die dem Endbenutzer alle GUI-Funktionen, Zustände und Verhaltensweisen verständlich erklärt.
+
+### Muss umgesetzt werden
+- Eine neue Datei **`gui-bedienanleitung.md`** neben `betrieb.md` anlegen.
+- Der Inhalt ist **deskriptiv** (beschreibend), nicht als Schritt-für-Schritt-Tutorial.
+- Mindestens folgende Themen abdecken:
+  - Startzustände (GUI-Standardstart, Willkommenstext, Start mit `--config`),
+  - Aktionen: **Neu**, **Öffnen**, **Speichern**, **Speichern unter**, **Validieren**, **Technische Tests ausführen**, **Modelle neu laden**,
+  - Bedeutung der vier Meldungsstufen (Info, Hinweis, Warnung, Fehler),
+  - feldnahe Fehlermeldungen,
+  - Provider-Bedienung und Modellabruf,
+  - API-Key-Auflösungsreihenfolge mit Vorrang der Umgebungsvariable,
+  - Dirty-State und Schutzdialoge,
+  - `.bak`-Sicherung beim Überschreiben und Legacy-Migration,
+  - Windows-Hinweise zu gemappten Laufwerken,
+  - bekannte Einschränkungen: kein manueller Verarbeitungslauf in V2.0, keine Erkennung externer Änderungen an der `.properties`-Datei, keine Koordination mit parallelen headless Läufen.
+- Die Anleitung so schneiden, dass sie zum realen V2.0-Verhalten der GUI passt.
+- Terminologie zwischen Bedienanleitung, `betrieb.md`, GUI-Texten und Meilensteinbeschreibungen vereinheitlichen.
+
+### Explizit nicht Teil
+- Betriebsdokumentation (bleibt in `betrieb.md`)
+- technische Entwicklerdokumentation
+- Release-Befundliste
+- Freigabedokument
+
+### Fertig wenn
+- `gui-bedienanleitung.md` im Repository vorliegt,
+- alle definierten Themen deskriptiv abgedeckt sind,
+- die Terminologie mit `betrieb.md` und den GUI-Texten konsistent ist,
+- der Build weiterhin fehlerfrei ist.
+
+---
+
+## AP-003 Konfigurationsbeispiele, Standardvorlage und Prompt-Bezug für den V2.0-Endstand konsolidieren
 
 ### Voraussetzung
 AP-001 ist abgeschlossen.
@@ -161,8 +199,6 @@ Die im Repository enthaltenen Konfigurations- und Prompt-Beispiele passen konsis
   - konservative Default-Werte,
   - V2.0-relevante Grenz- und Warnparameter.
 - Die Standardvorlage für **„Neue Konfiguration“** und die dokumentierten Konfigurationsbeispiele semantisch aufeinander abstimmen.
-- Sicherstellen, dass die Dokumentation den gemeinsamen Standardpfad `config/application.properties` relativ zum Arbeitsverzeichnis konsistent beschreibt, wo dies für GUI-Speichervorschläge und headless Standardverhalten relevant ist.
-- Den Umgang mit `.bak`-Sicherungen beim Überschreiben bestehender `.properties`-Dateien konsistent dokumentieren.
 - Den Umgang mit automatisch erzeugbarer deutscher Standard-Prompt-Datei dokumentieren.
 - Sicherstellen, dass Dateinamen, Pfadbeispiele und Properties-Namen zum tatsächlichen Code passen.
 
@@ -180,7 +216,7 @@ Die im Repository enthaltenen Konfigurations- und Prompt-Beispiele passen konsis
 
 ---
 
-## AP-003 Regressionstests für headless Abwärtskompatibilität, Startoptionen und Konfigurationspfade ergänzen
+## AP-004 Regressionstests für headless Abwärtskompatibilität, Startoptionen und Konfigurationspfade ergänzen
 
 ### Voraussetzung
 AP-001 und AP-002 sind abgeschlossen.
@@ -195,7 +231,6 @@ Die kritischen V2.0-Risiken im bisherigen Server-/Scheduler-Betrieb werden autom
   - headless Start mit ungültigem bzw. nicht vorhandenem `--config` als harter Startfehler,
   - keine unzulässige Abhängigkeit von separater JavaFX-Installation im headless Pfad.
 - Tests für Parsing und Semantik von `--headless` und `--config` ergänzen.
-- Tests für das verbindliche Exit-Code-Modell im headless Pfad ergänzen, soweit dies stabil automatisierbar ist.
 - Sicherstellen, dass bestehender Batch-/Scheduler-Betrieb durch V2.0 nicht still verändert wird.
 - Relevante Start- und Fehlermeldungssemantik mit absichern, soweit dies stabil automatisierbar ist.
 
@@ -212,7 +247,7 @@ Die kritischen V2.0-Risiken im bisherigen Server-/Scheduler-Betrieb werden autom
 
 ---
 
-## AP-004 GUI-Smoke- und Interaktionstests für den V2.0-Kernumfang vervollständigen
+## AP-005 GUI-Smoke- und Interaktionstests für den V2.0-Kernumfang vervollständigen
 
 ### Voraussetzung
 AP-001 bis AP-003 sind abgeschlossen.
@@ -245,7 +280,7 @@ Die zentralen V2.0-GUI-Pfade sind automatisiert so abgesichert, dass Bedienung,
 
 ---
 
-## AP-005 Build-, Packaging- und Artefaktdokumentation für das gemeinsame V2.0-JAR vervollständigen
+## AP-006 Build-, Packaging- und Artefaktdokumentation für das gemeinsame V2.0-JAR vervollständigen
 
 ### Voraussetzung
 AP-001 bis AP-004 sind abgeschlossen.
@@ -278,7 +313,7 @@ Das gemeinsame ausführbare JAR für GUI und headless ist nachvollziehbar beschr
 
 ---
 
-## AP-006 Integrierte Gesamtprüfung des V2.0-Stands und belastbare Befundliste erstellen
+## AP-007 Integrierte Gesamtprüfung des V2.0-Stands und belastbare Befundliste erstellen
 
 ### Voraussetzung
 AP-001 bis AP-005 sind abgeschlossen.
@@ -294,7 +329,7 @@ Der V2.0-Gesamtstand wird ganzheitlich geprüft, und es entsteht eine belastbare
   - headless Smoke-/Regressionstests,
   - GUI-nahe Smoke-/Interaktionstests, soweit im Projekt vorhanden,
   - Prüfung der Konfigurations- und Dokumentationsbeispiele.
-- Die Ergebnisse in einer im Repository verbleibenden **Befundliste** dokumentieren.
+- Die Ergebnisse als neuen V2.0-Abschnitt in der bestehenden **`befundliste.md`** dokumentieren.
 - Befunde klar klassifizieren, insbesondere in:
   - Release-Blocker,
   - nicht blockierende Restpunkte,
@@ -314,10 +349,10 @@ Der V2.0-Gesamtstand wird ganzheitlich geprüft, und es entsteht eine belastbare
 
 ---
 
-## AP-007 Nachgewiesene V2.0-Release-Blocker gezielt beheben
+## AP-008 Nachgewiesene V2.0-Release-Blocker gezielt beheben
 
 ### Voraussetzung
-AP-006 ist abgeschlossen.
+AP-008 ist abgeschlossen.
 
 ### Ziel
 Die im vorherigen Arbeitspaket konkret dokumentierten Release-Blocker werden gezielt und ohne Scope-Ausweitung beseitigt.
@@ -342,7 +377,7 @@ Die im vorherigen Arbeitspaket konkret dokumentierten Release-Blocker werden gez
 
 ---
 
-## AP-008 Finale V2.0-Gesamtprüfung und Freigabedokumentation erstellen
+## AP-009 Finale V2.0-Gesamtprüfung und Freigabedokumentation erstellen
 
 ### Voraussetzung
 AP-007 ist abgeschlossen.
@@ -358,6 +393,7 @@ Der V2.0-Gesamtstand wird abschließend geprüft und als freigabefähiger Stand
   - headless Smoke-/Regressionstests,
   - GUI-nahe Smoke-/Interaktionstests,
   - Konfigurations- und Dokumentationsbeispielprüfung.
+- Endbenutzer-Bedienanleitung (`gui-bedienanleitung.md`) auf Vollständigkeit, Konsistenz mit `betrieb.md` und Übereinstimmung mit dem realen GUI-Verhalten prüfen.
 - Eine im Repository verbleibende **Freigabedokumentation** erstellen, die mindestens festhält:
   - geprüften Stand,
   - ausgeführte Prüfungen,
@@ -381,4 +417,4 @@ Der V2.0-Gesamtstand wird abschließend geprüft und als freigabefähiger Stand
 
 ## Abschlussbewertung
 
-Die Arbeitspakete sind inhaltlich konsistent, widerspruchsfrei und sauber auf den Meilenstein **M13 – V2.0-Abschluss, Dokumentation und Qualitätsnachweis** zugeschnitten. Sie decken den vollständigen Zielumfang dieses Abschlussmeilensteins ab, ohne spätere Ausbaustufen vorwegzunehmen.
+Die Arbeitspakete sind inhaltlich konsistent, widerspruchsfrei und sauber auf den Meilenstein **M13 – V2.0-Abschluss, Dokumentation und Qualitätsnachweis** zugeschnitten. Sie decken den vollständigen Zielumfang dieses Abschlussmeilensteins ab, ohne spätere Ausbaustufen vorwegzunehmen.