Arbeitspakete für V2.0 überarbeitet

2026-04-13 07:20:43 +02:00
parent dc2d3e8cd2
commit f0538fa247
5 changed files with 89 additions and 64 deletions
--- a/docs/workpackages/M10
+++ b/docs/workpackages/M10
@@ -27,7 +27,7 @@ Die Reihenfolge der Arbeitspakete ist verbindlich.
 ## Explizit nicht Bestandteil von M10
- sofortige Validierung beim Öffnen oder während der Eingabe
+- automatische Validierung beim Öffnen oder während der Eingabe
 - zentraler Meldungsbereich mit Info/Hinweis/Warnung/Fehler
 - feldnahe rote Fehlermeldungen unter Eingabefeldern
 - Provider-ComboBox
@@ -81,9 +81,8 @@ Ab M10 gilt verbindlich:
 - **„Öffnen“** und **„Speichern unter“** filtern auf **`*.properties`**.
 - **„Speichern“** verhält sich bei einer neuen, noch nie gespeicherten Konfiguration wie **„Speichern unter“**.
- **„Speichern unter“** schlägt standardmäßig denselben Standardpfad vor, den der bestehende headless Betrieb in V1.1 verwendet, also **`config/application.properties`** relativ zum Arbeitsverzeichnis. Dadurch ist die in der GUI gespeicherte Datei ohne weitere Schritte für den nächsten headless Scheduler-Lauf nutzbar.
+- **„Speichern unter“** schlägt standardmäßig **`pdf-umbenenner.properties`** vor.
 - Beim Speichern auf eine bereits existierende Datei erscheint eine klare Rückfrage **„Datei überschreiben?“**.
 - Vor dem Überschreiben einer bestehenden `.properties`-Datei legt die GUI eine `.bak`-Sicherung im selben Schema wie der bestehende V1.1-Migrationspfad an (**`<dateiname>.bak`**, bei Kollision **`.bak.1`**, **`.bak.2`**, …).
 ### 5. Editorzustand und ungespeicherte Änderungen
@@ -226,7 +225,7 @@ Bestehende Konfigurationsdateien können über den GUI-Dateidialog geladen und i
 ### Muss umgesetzt werden
 - Native Dateiauswahl für **„Öffnen“** mit Filter auf **`*.properties`** implementieren.
 - Bestehende `.properties`-Datei technisch laden und in den Editorzustand überführen.
- Beim Öffnen einer erkannten Legacy-Konfiguration aus Vor-V1.1 die bestehende Migrationslogik des headless Pfads wiederverwenden; die GUI führt keinen zweiten, separaten Migrationspfad ein.
+- Die durchgeführte Legacy-Migration im Editorzustand als ausstehende Migrationsmeldung festhalten, sodass der in M11 eingeführte zentrale Meldungsbereich diese Meldung beim Anbinden automatisch anzeigen kann. In M10 selbst erscheint noch kein sichtbarer Migrationshinweis.
 - Sicherstellen, dass die Dateiübernahme mit dem aus M9 bereits vorhandenen GUI-Start über gültiges `--config <pfad>` zusammenarbeiten kann.
 - Header-Anzeige nach erfolgreichem Laden auf den vollständigen Pfad aktualisieren.
 - Fehlersituationen beim Laden kontrolliert behandeln, soweit für M10 nötig.
@@ -260,10 +259,9 @@ Der Editor kann neue und bestehende Konfigurationen zuverlässig, normalisiert u
 - Schreiblogik für bestehende und neue Konfigurationen implementieren.
 - **„Speichern“** für bereits bekannte Dateipfade umsetzen.
 - **„Speichern“** für neue, noch nie gespeicherte Konfigurationen wie **„Speichern unter“** behandeln.
- **„Speichern unter“** mit Vorschlag desselben Standardpfads implementieren, den der bestehende headless Betrieb in V1.1 verwendet, also **`config/application.properties`** relativ zum Arbeitsverzeichnis.
+- **„Speichern unter“** mit Vorschlag **`pdf-umbenenner.properties`** implementieren.
 - Dialogfilter auf **`*.properties`** anwenden.
 - Rückfrage **„Datei überschreiben?“** bei existierender Zieldatei umsetzen.
 - Vor dem Überschreiben einer bestehenden `.properties`-Datei eine `.bak`-Sicherung im selben Schema wie der bestehende V1.1-Migrationspfad anlegen (**`<dateiname>.bak`**, bei Kollision **`.bak.1`**, **`.bak.2`**, …); diese Sicherung ist verbindlicher Teil der Speicherlogik.
 - Speicherung als normalisierte `.properties` sicherstellen.
 - Für API-Key-Felder sicherstellen, dass ein leeres GUI-Feld einen bereits vorhandenen Property-Wert nicht stillschweigend entfernt; stattdessen muss ein kontrolliertes Ergebnis für die spätere Warnanzeige aus M11/M12 bereitstehen.
 - Header-Pfad nach erfolgreichem Erstspeichern bzw. Speichern unter korrekt fortschreiben.
@@ -371,10 +369,8 @@ Der vollständige M10-Datei- und Editorfluss wird integriert abgesichert, einsch
  - GUI-Start ohne geladene Konfiguration,
  - **Neu** mit Standardvorlage,
  - **Öffnen** bestehender `.properties`,
  - Wiederverwendung der bestehenden headless Migrationslogik beim Öffnen einer Legacy-Konfiguration,
  - **Speichern** und **Speichern unter**,
  - Überschreibdialog,
  - `.bak`-Sicherung beim Überschreiben einer bestehenden `.properties`-Datei,
  - Dirty-State-Markierung,
  - Schutzdialog bei offenen Änderungen,
  - gültigen GUI-Start mit `--config`.
@@ -398,4 +394,4 @@ Der vollständige M10-Datei- und Editorfluss wird integriert abgesichert, einsch
 ## Abschlussbewertung
-Die Arbeitspakete sind inhaltlich konsistent, widerspruchsfrei und sauber auf den Meilenstein **M10 – GUI-Konfigurationseditor, Dateihandling und Benutzerführung** zugeschnitten. Sie liefern einen echten, benutzerfreundlichen Konfigurationseditor auf Basis der bestehenden `.properties`-Wahrheit, ohne bereits Provider-Komfortlogik, sofortige Validierung oder technische Test-/Korrekturfunktionen aus **M11/M12** vorwegzunehmen.
+Die Arbeitspakete sind inhaltlich konsistent, widerspruchsfrei und sauber auf den Meilenstein **M10 – GUI-Konfigurationseditor, Dateihandling und Benutzerführung** zugeschnitten. Sie liefern einen echten, benutzerfreundlichen Konfigurationseditor auf Basis der bestehenden `.properties`-Wahrheit, ohne bereits Provider-Komfortlogik, sofortige Validierung oder technische Test-/Korrekturfunktionen aus **M11/M12** vorwegzunehmen.
--- a/docs/workpackages/M11
+++ b/docs/workpackages/M11
@@ -31,7 +31,7 @@ Die Reihenfolge der Arbeitspakete ist verbindlich.
 - Aktion **„Validieren“**
 - Aktion **„Technische Tests ausführen“**
- Aktion **„Modelle neu laden“** als vollständige Bedienlogik, soweit dafür M12-spezifische Gesamtprüfung oder Korrekturhilfen nötig wären
+- M12-spezifische Gesamtprüfungs- und Korrekturpfade rund um die Aktion **„Modelle neu laden“** (die Aktion selbst gehört zu M11 als manueller Wieder-Auslöser des bereits vorhandenen Modellabrufs)
 - technische Gesamtprüfung aller Konfigurations- und Laufzeitvoraussetzungen
 - schreibende Korrekturhilfen oder Sammel-Bestätigungsdialoge
 - automatische Erzeugung fehlender Prompt-Dateien
@@ -232,8 +232,6 @@ Für den aktuell ausgewählten Provider kann eine Modellliste technisch geladen
  - Provider liefert keine nutzbare Modellliste,
  - sonstige technische Kommunikationsfehler.
 - Sicherstellen, dass diese Fälle als benutzerfreundliche Befunde weitergegeben werden können und die GUI nicht abbrechen lassen.
 - Modellabruf läuft asynchron auf einem Worker-Thread; das Ergebnis wird über den JavaFX Application Thread in die GUI zurückgespielt.
 - Versuche und Ergebnisse des Modellabrufs werden im bestehenden Log4j2-Log nachvollziehbar protokolliert.
 - Bootstrap-Verdrahtung nur im minimal erforderlichen Umfang ergänzen.
 - JavaDoc für Modellabruf, Providergrenzen und Nicht-Ziele von M11 ergänzen.
@@ -272,8 +270,6 @@ Die GUI reagiert auf Providerwechsel sofort mit Modellabruf, bietet zusätzlich
  - Benutzer zur manuellen Eingabe befähigen.
 - Sicherstellen, dass ein früherer manueller Modellwert verworfen wird, wenn später eine echte Liste geladen wird und der Wert dort nicht vorkommt.
 - Die Modellwert-Übernahme so schneiden, dass die `.properties`-Struktur später korrekt geschrieben werden kann.
 - Modellabruf läuft asynchron auf einem Worker-Thread; das Ergebnis wird über den JavaFX Application Thread in die GUI zurückgespielt.
 - Erfolgreiche Listenladung, manueller Fallback und technische Fehlschläge werden im bestehenden Log4j2-Log nachvollziehbar protokolliert.
 - Benötigte Meldungen für erfolgreichen Modellabruf bzw. Fallback vorbereiten.
 - JavaDoc/Kommentare für die Modellfeldsemantik ergänzen.
@@ -316,7 +312,6 @@ Der aktuelle GUI-Zustand wird beim Öffnen und während der Bearbeitung sofort a
 - Sicherstellen, dass die Validierung mit dem aktuellen GUI-Zustand arbeitet und kein implizites Speichern auslöst.
 - Sichtbar machen können, wenn aktuell eine Umgebungsvariable den Property-Wert übersteuert.
 - Sicherstellen, dass ein leeres API-Key-Feld einen bereits vorhandenen Property-Wert nicht stillschweigend entfernt; stattdessen ist ein deutlicher Befund für den zentralen Meldungsbereich vorzubereiten.
 - Wesentliche Ergebnisse der automatischen Validierung werden im bestehenden Log4j2-Log nachvollziehbar protokolliert.
 - Validierungsmodell so schneiden, dass es später sowohl zentrale Meldungen als auch feldnahe Befunde speisen kann.
 - JavaDoc für Validierungsgrenzen, API-Key-Vorrangregel und Nicht-Ziele von M11 ergänzen.
@@ -353,6 +348,7 @@ Die GUI zeigt automatische Modellabruf- und Validierungsbefunde sowohl zentral a
 - Feldnahe rote, kleine, deutschsprachige Fehlermeldungen direkt unter problematischen Eingabefeldern anbinden.
 - Sicherstellen, dass zentrale und feldnahe Befunde konsistent aus demselben Validierungs-/Meldungsmodell gespeist werden.
 - Modellabruf-Ergebnisse in den Meldungsbereich integrieren, z. B. erfolgreiche Listenladung oder manueller Fallback.
 - API-Key-Herkunftsanzeige (Umgebungsvariable vs. Property-Wert) in den zentralen Meldungsbereich und, soweit feldnah sinnvoll, unter das API-Key-Feld anbinden.
 - Die GUI so schneiden, dass M12 später zusätzliche Meldungen aus expliziten Gesamtprüfungen anschließen kann, ohne M11 neu zu zerlegen.
 - JavaDoc/Kommentare für Meldungssemantik und Renderinggrenzen ergänzen.
@@ -397,11 +393,11 @@ Der vollständige M11-Zielzustand wird automatisiert abgesichert und als stabile
 ### Fertig wenn
 - der definierte M11-Zielzustand automatisiert abgesichert ist,
- Provider-Bedienung, Modellabruf und sofortige Validierung stabil nachgewiesen sind,
+- Provider-Bedienung, Modellabruf und automatische Validierung stabil nachgewiesen sind,
 - der Stand fehlerfrei buildbar und übergabefähig ist.
 ---
 ## Abschlussbewertung
-Die Arbeitspakete sind inhaltlich konsistent, widerspruchsfrei und sauber auf den Meilenstein **M11 – Provider-Bedienung, Modellabruf und automatische Validierung** zugeschnitten. Sie decken den geplanten M11-Umfang vollständig ab, ohne technische Gesamttests, Korrekturhilfen oder andere V2.0-Bausteine späterer Meilensteine vorwegzunehmen.
+Die Arbeitspakete sind inhaltlich konsistent, widerspruchsfrei und sauber auf den Meilenstein **M11 – Provider-Bedienung, Modellabruf und automatische Validierung** zugeschnitten. Sie decken den geplanten M11-Umfang vollständig ab, ohne technische Gesamttests, Korrekturhilfen oder andere V2.0-Bausteine späterer Meilensteine vorwegzunehmen.
--- a/docs/workpackages/M12
+++ b/docs/workpackages/M12
@@ -184,7 +184,6 @@ Die GUI bietet eine explizite Validierungsaktion, die den aktuellen Editorzustan
 - Alle lokalen Befunde gesammelt erzeugen und dem vorhandenen Meldungsmodell zuführen.
 - Relevante feldnahe Fehlermeldungen ergänzen oder schärfen.
 - Eindeutige deutsche Meldungen für Fehler, Warnungen, Hinweise und Infos verwenden.
 - Ausführung und Ergebnis der Aktion **„Validieren“** werden im bestehenden Log4j2-Log nachvollziehbar protokolliert.
 - JavaDoc/Kommentare für die Abgrenzung zur M12-Gesamttestaktion ergänzen.
 ### Explizit nicht Teil
@@ -226,8 +225,7 @@ Die für V2.0 geforderten providerbezogenen technischen Prüfpunkte können kont
  - Authentifizierungsproblem,
  - nicht verfügbarer Modellliste,
  - unplausibler Modellauswahl.
- Provider-nahe technische Prüfungen und Dateisystem-/SQLite-Prüfungen laufen asynchron; die Ergebnisrückführung in die GUI erfolgt über den JavaFX Application Thread.
+- Provider-nahe technische Prüfungen laufen asynchron auf einem Worker-Thread; die Ergebnisrückführung in die GUI erfolgt über den JavaFX Application Thread.
 - Ausführung und Ergebnis der providernahen technischen Prüfpunkte werden im bestehenden Log4j2-Log nachvollziehbar protokolliert.
 - Keine impliziten Korrekturen durchführen.
 - JavaDoc/Kommentare für technische Prüfpunkte und Nicht-Ziele ergänzen.
@@ -266,6 +264,8 @@ Die GUI und ihre Prüflogik behandeln Windows-Pfade einschließlich gemappter La
  - nicht schreibbar,
  - ungültig,
  - anlegbar.
 - Pfadprüfungen laufen asynchron auf einem Worker-Thread; die Ergebnisrückführung in die GUI erfolgt über den JavaFX Application Thread.
 - Ausführung und Ergebnis der Pfadprüfungen werden im bestehenden Log4j2-Log nachvollziehbar protokolliert.
 - JavaDoc/Kommentare für Windows-/Netzlaufwerksfähigkeit und technische Grenzen ergänzen.
 ### Explizit nicht Teil
@@ -305,10 +305,8 @@ Die GUI kann einen vollständigen technischen Gesamttest des aktuellen Editorzus
  - Zielordner vorhanden oder anlegbar sowie schreibbar,
  - SQLite-Datei bzw. SQLite-Pfad technisch nutzbar.
 - Sicherstellen, dass der Gesamttest **nicht** beim ersten Fehler abbricht.
 - Provider-nahe technische Prüfungen und Dateisystem-/SQLite-Prüfungen laufen asynchron; die Ergebnisrückführung in die GUI erfolgt über den JavaFX Application Thread.
 - Alle Befunde gesammelt und verständlich im zentralen Meldungsbereich ausgeben.
 - Deutlich kenntlich machen, dass sich das Ergebnis auf den aktuellen Editorzustand bezieht.
 - Ausführung, Teilresultate und Gesamtergebnis der Aktion **„Technische Tests ausführen“** werden im bestehenden Log4j2-Log nachvollziehbar protokolliert.
 - JavaDoc/Kommentare zur Gesamttest-Semantik ergänzen.
 ### Explizit nicht Teil
@@ -339,7 +337,6 @@ Die GUI kann sichere technische Korrekturen gesammelt vorschlagen und nach einma
 - Nur sichere technische Korrekturen zulassen, insbesondere dort, wo Ressourcen fehlend, aber technisch anlegbar sind.
 - Sicherstellen, dass ohne Bestätigung keine schreibenden Änderungen ausgeführt werden.
 - Nach Durchführung die Ergebnisse erneut verständlich in den Meldungsbereich zurückführen.
 - Schreibende Korrekturen, Bestätigung und Ergebnisrückmeldung werden im bestehenden Log4j2-Log nachvollziehbar protokolliert.
 - Keine stillen Auto-Korrekturen im Hintergrund zulassen.
 - JavaDoc/Kommentare für die Korrekturgrenzen ergänzen.
@@ -376,7 +373,6 @@ Fehlende, technisch anlegbare Ressourcen können im Rahmen der Korrekturhilfen s
  - SQLite-Datei bzw. nutzbaren SQLite-Pfad vorbereiten,
  - Prompt-Datei anlegen.
 - Verständliche deutsche Meldungen für Erfolg, Teilfehler und Nichtdurchführbarkeit bereitstellen.
 - Prompt-Erzeugung, Ressourcenkorrekturen und deren Ergebnisse werden im bestehenden Log4j2-Log nachvollziehbar protokolliert.
 - JavaDoc/Kommentare für Prompt-Generierung und Ressourcenkorrektur ergänzen.
 ### Explizit nicht Teil
@@ -426,4 +422,4 @@ Der vollständige M12-Zielzustand wird automatisiert abgesichert und als konsist
 ## Abschlussbewertung
-Die Arbeitspakete sind inhaltlich konsistent, widerspruchsfrei und sauber auf den Meilenstein **M12 – Technische Tests, Korrekturhilfen und Windows-/Netzlaufwerksfähigkeit** zugeschnitten. Sie decken den vollständigen Zielumfang dieses Meilensteins ab, ohne spätere Ausbaustufen vorwegzunehmen.
+Die Arbeitspakete sind inhaltlich konsistent, widerspruchsfrei und sauber auf den Meilenstein **M12 – Technische Tests, Korrekturhilfen und Windows-/Netzlaufwerksfähigkeit** zugeschnitten. Sie decken den vollständigen Zielumfang dieses Meilensteins ab, ohne spätere Ausbaustufen vorwegzunehmen.
--- a/docs/workpackages/M13
+++ b/docs/workpackages/M13
@@ -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.
--- a/docs/workpackages/M9
+++ b/docs/workpackages/M9
@@ -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
+### 5. Plattformziel
 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
 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
+### 6. GUI-Zielstand innerhalb von M9
 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
 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.