Arbeitspakete + Review für M9 angelegt

docs/prompts/M9-AP-001-review.md

@@ -0,0 +1,20 @@
+Lies zunächst vollständig folgende Dokumente:
+- @CLAUDE.md
+- @docs/workpackages/M9 - Arbeitspakete.md
+
+Führe ein vollständiges Review von **AP-001 – Neues GUI-Modul und Maven-/Reactor-Basis einführen** durch.
+
+Prüfe jeden Punkt einzeln und antworte je Punkt mit BESTANDEN oder NICHT BESTANDEN + kurzer Begründung:
+
+1. Ist das Modul `pdf-umbenenner-adapter-in-gui` im Reactor und in der Parent-POM vorhanden?
+2. Sind die Abhängigkeiten architekturtreu geschnitten (GUI-Modul als Inbound-Adapter, Abhängigkeiten zeigen nach innen)?
+3. Sind Domain, Application, Adapter-Out und CLI-Adapter nachweislich frei von JavaFX-Abhängigkeiten?
+4. Entsprechen alle neuen/geänderten öffentlichen Klassen und Methoden dem JavaDoc-Standard (inkl. package-info.java)?
+5. Wurde kein Vorgriff auf AP-002 oder spätere Arbeitspakete gemacht?
+6. Ist der headless Batch-Betrieb nachweislich nicht gebrochen?
+7. Ist der Build fehlerfrei?
+
+Führe den Build selbst aus, um Punkt 7 zu verifizieren.
+
+Abschließendes Gesamturteil: **BESTANDEN** / **NICHT BESTANDEN**
+Bei NICHT BESTANDEN: Liste konkret alle zu behebenden Punkte auf.

docs/prompts/M9-AP-001-umsetzen.md

@@ -0,0 +1,27 @@
+Lies zunächst vollständig folgende Dokumente:
+- @CLAUDE.md
+- @docs/specs/meilensteine-v2_0.md
+- @docs/workpackages/M9 - Arbeitspakete.md
+
+Setze jetzt ausschließlich **AP-001 – Neues GUI-Modul und Maven-/Reactor-Basis einführen** um.
+
+Scope:
+- Neues Modul `pdf-umbenenner-adapter-in-gui` anlegen und korrekt in Parent-POM und Reactor aufnehmen
+- Abhängigkeiten so schneiden, dass das GUI-Modul als Inbound-Adapter auf die inneren Schichten aufsetzen kann
+- JavaFX-Grundabhängigkeiten nur im GUI-Modul einführen
+- Sicherstellen, dass Domain, Application, Adapter-Out und CLI-Adapter frei von JavaFX-Abhängigkeiten bleiben
+- 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
+
+Nicht umsetzen:
+- Tatsächlicher GUI-Start
+- CLI-Parsing für neue Optionen
+- Bootstrap-Anpassungen
+- Packaging des gemeinsamen JARs
+- GUI-Inhalt jenseits einer neutralen Modulbasis
+- Jegliche Inhalte aus AP-002 oder später
+
+Halte dich strikt an die Architekturregeln und den JavaDoc-Standard aus CLAUDE.md.
+Führe am Ende einen fehlerfreien Build durch.
+
+Erstelle abschließend den Pflicht-Output gemäß CLAUDE.md.

docs/prompts/M9-AP-002-review.md

@@ -0,0 +1,22 @@
+Lies zunächst vollständig folgende Dokumente:
+- @CLAUDE.md
+- @docs/workpackages/M9 - Arbeitspakete.md
+
+Führe ein vollständiges Review von **AP-002 – Startmodus- und CLI-Optionsmodell für GUI, `--headless` und `--config` einführen** durch.
+
+Prüfe jeden Punkt einzeln und antworte je Punkt mit BESTANDEN oder NICHT BESTANDEN + kurzer Begründung:
+
+1. Sind GUI-Standardstart und `--headless`-Start technisch eindeutig modelliert?
+2. Ist `--config <pfad>` für beide Startarten eingeführt?
+3. Bleibt das bestehende headless Default-Verhalten ohne `--config` nachweislich erhalten?
+4. Werden fehlerhafte CLI-Verwendungen (`--config` ohne Wert, unbekannte Parameter) kontrolliert behandelt?
+5. Kann Bootstrap aus dem Rückgabemodell eindeutig GUI-Start, headless Start oder harten Startfehler ableiten?
+6. Entsprechen alle neuen/geänderten öffentlichen Klassen und Methoden dem JavaDoc-Standard (inkl. package-info.java)?
+7. Wurde kein Vorgriff auf AP-003 oder spätere Arbeitspakete gemacht?
+8. Ist der headless Batch-Betrieb nachweislich nicht gebrochen?
+9. Ist der Build fehlerfrei?
+
+Führe den Build selbst aus, um Punkt 9 zu verifizieren.
+
+Abschließendes Gesamturteil: **BESTANDEN** / **NICHT BESTANDEN**
+Bei NICHT BESTANDEN: Liste konkret alle zu behebenden Punkte auf.

docs/prompts/M9-AP-002-umsetzen.md

@@ -0,0 +1,27 @@
+Lies zunächst vollständig folgende Dokumente:
+- @CLAUDE.md
+- @docs/specs/meilensteine-v2_0.md
+- @docs/workpackages/M9 - Arbeitspakete.md
+
+AP-001 ist abgeschlossen. Setze jetzt ausschließlich **AP-002 – Startmodus- und CLI-Optionsmodell für GUI, `--headless` und `--config` einführen** um.
+
+Scope:
+- Technisches Modell für die Startmodi einführen: GUI-Standardstart und expliziter `--headless`-Start
+- Neue CLI-Option `--config <pfad>` für beide Startarten einführen
+- Parsing und Validierung der relevanten Optionen im Startpfad modellieren
+- Bestehendes Default-Verhalten für headless Starts ohne `--config` ausdrücklich erhalten
+- Klare Behandlung für fehlerhafte CLI-Verwendungen modellieren (`--config` ohne Wert, unbekannte/widersprüchliche Parameter)
+- Rückgabemodell so schneiden, dass Bootstrap daraus kontrolliert GUI-Start, headless Start oder harten Startfehler ableiten kann
+- JavaDoc für Startmodussemantik und Konfigurationspfadbezug ergänzen
+
+Nicht umsetzen:
+- Tatsächliches Laden einer GUI-Oberfläche
+- Konkrete Behandlung nicht existenter Konfigurationsdateien im fertigen Startfluss
+- Packaging
+- GUI-Benutzerführung
+- Jegliche Inhalte aus AP-003 oder später
+
+Halte dich strikt an die Architekturregeln und den JavaDoc-Standard aus CLAUDE.md.
+Führe am Ende einen fehlerfreien Build durch.
+
+Erstelle abschließend den Pflicht-Output gemäß CLAUDE.md.

docs/prompts/M9-AP-003-review.md

@@ -0,0 +1,22 @@
+Lies zunächst vollständig folgende Dokumente:
+- @CLAUDE.md
+- @docs/workpackages/M9 - Arbeitspakete.md
+
+Führe ein vollständiges Review von **AP-003 – Bootstrap-Verdrahtung für zwei Startpfade und kontrollierte Fehlerableitung erweitern** durch.
+
+Prüfe jeden Punkt einzeln und antworte je Punkt mit BESTANDEN oder NICHT BESTANDEN + kurzer Begründung:
+
+1. Schaltet Bootstrap korrekt zwischen GUI-Start und headless Start um?
+2. Ist der bestehende headless Pfad fachlich und technisch nachweislich erhalten?
+3. Werden harte Startfehler kontrolliert abgeleitet (Exit-Code 1)?
+4. Ist die Behandlung des Konfigurationspfadbezugs im Bootstrap vollständig?
+5. Enthält Bootstrap keine GUI-Fachlogik und keine M10-Editorlogik?
+6. Entsprechen alle neuen/geänderten öffentlichen Klassen und Methoden dem JavaDoc-Standard (inkl. package-info.java)?
+7. Wurde kein Vorgriff auf AP-004 oder spätere Arbeitspakete gemacht?
+8. Ist der headless Batch-Betrieb nachweislich nicht gebrochen?
+9. Ist der Build fehlerfrei?
+
+Führe den Build selbst aus, um Punkt 9 zu verifizieren.
+
+Abschließendes Gesamturteil: **BESTANDEN** / **NICHT BESTANDEN**
+Bei NICHT BESTANDEN: Liste konkret alle zu behebenden Punkte auf.

docs/prompts/M9-AP-003-umsetzen.md

@@ -0,0 +1,26 @@
+Lies zunächst vollständig folgende Dokumente:
+- @CLAUDE.md
+- @docs/specs/meilensteine-v2_0.md
+- @docs/workpackages/M9 - Arbeitspakete.md
+
+AP-001 und AP-002 sind abgeschlossen. Setze jetzt ausschließlich **AP-003 – Bootstrap-Verdrahtung für zwei Startpfade und kontrollierte Fehlerableitung erweitern** um.
+
+Scope:
+- Bootstrap so erweitern, dass es abhängig vom geparsten Startmodus den passenden Inbound-Adapter startet
+- Bestehenden headless Pfad fachlich und technisch erhalten
+- Kontrollierte Fehlerableitung für harte Startfehler ergänzen, soweit M9 dies bereits erfordert
+- Behandlung des Konfigurationspfadbezugs im Bootstrap vervollständigen
+- Sicherstellen, dass Bootstrap keine GUI-Fachlogik oder M10-Editorlogik aufnimmt
+- JavaDoc für aktualisierte Bootstrap-Verantwortung ergänzen
+
+Nicht umsetzen:
+- Minimale GUI-Shell selbst
+- JavaFX-Packaging
+- GUI-Benutzerführung
+- Dateieditor oder Validierungslogik
+- Jegliche Inhalte aus AP-004 oder später
+
+Halte dich strikt an die Architekturregeln und den JavaDoc-Standard aus CLAUDE.md.
+Führe am Ende einen fehlerfreien Build durch.
+
+Erstelle abschließend den Pflicht-Output gemäß CLAUDE.md.

docs/prompts/M9-AP-004-review.md

@@ -0,0 +1,23 @@
+Lies zunächst vollständig folgende Dokumente:
+- @CLAUDE.md
+- @docs/workpackages/M9 - Arbeitspakete.md
+
+Führe ein vollständiges Review von **AP-004 – Minimale JavaFX-GUI-Shell als Standardstartpfad bereitstellen** durch.
+
+Prüfe jeden Punkt einzeln und antworte je Punkt mit BESTANDEN oder NICHT BESTANDEN + kurzer Begründung:
+
+1. Startet die Anwendung im Standardstart in eine minimale JavaFX-GUI-Shell?
+2. Ist die GUI-Shell technisch sauber vom headless Pfad getrennt?
+3. Ist die GUI-Shell so geschnitten, dass sie ohne Architekturbruch zum Konfigurationseditor ausgebaut werden kann?
+4. Gibt es klare Rückmeldungen bei GUI-Startfehlern?
+5. Enthält die Shell keinerlei M10-Funktionalität (kein Editor, keine Dateioperationen, keine Validierung, keine Providerbedienung)?
+6. Ist das GUI-Threadingmodell korrekt umgesetzt (blockierende Operationen auf Worker-Thread, UI-Updates via Platform.runLater)?
+7. Entsprechen alle neuen/geänderten öffentlichen Klassen und Methoden dem JavaDoc-Standard (inkl. package-info.java)?
+8. Wurde kein Vorgriff auf AP-005 oder spätere Arbeitspakete gemacht?
+9. Ist der headless Batch-Betrieb nachweislich nicht gebrochen?
+10. Ist der Build fehlerfrei?
+
+Führe den Build selbst aus, um Punkt 10 zu verifizieren.
+
+Abschließendes Gesamturteil: **BESTANDEN** / **NICHT BESTANDEN**
+Bei NICHT BESTANDEN: Liste konkret alle zu behebenden Punkte auf.

docs/prompts/M9-AP-004-umsetzen.md

@@ -0,0 +1,27 @@
+Lies zunächst vollständig folgende Dokumente:
+- @CLAUDE.md
+- @docs/specs/meilensteine-v2_0.md
+- @docs/workpackages/M9 - Arbeitspakete.md
+
+AP-001 bis AP-003 sind abgeschlossen. Setze jetzt ausschließlich **AP-004 – Minimale JavaFX-GUI-Shell als Standardstartpfad bereitstellen** um.
+
+Scope:
+- Minimale JavaFX-Einstiegsklasse im GUI-Modul implementieren
+- Neutrale GUI-Shell bereitstellen, die den erfolgreichen GUI-Start technisch sichtbar macht
+- GUI-Shell so schneiden, dass sie später ohne Architekturbruch zum Konfigurationseditor ausgebaut werden kann
+- Klare Rückmeldungen für GUI-bezogene Startfehler sicherstellen
+- Sicherstellen, dass die GUI-Shell keine M10-Funktionalität vorwegnimmt (kein Konfigurationseditor, keine Dateioperationen, keine Validierung, keine Providerbedienung)
+- JavaDoc für Zweck und klare Nicht-Ziele der minimalen GUI-Shell ergänzen
+
+Nicht umsetzen:
+- Willkommenstext im finalen V2.0-Sinne
+- Bearbeitbare Eingabefelder
+- Buttons Neu, Öffnen, Speichern usw.
+- Meldungsbereich
+- Technische Tests
+- Jegliche Inhalte aus AP-005 oder später
+
+Halte dich strikt an die Architekturregeln, das GUI-Threadingmodell und den JavaDoc-Standard aus CLAUDE.md.
+Führe am Ende einen fehlerfreien Build durch.
+
+Erstelle abschließend den Pflicht-Output gemäß CLAUDE.md.

docs/prompts/M9-AP-005-review.md

@@ -0,0 +1,22 @@
+Lies zunächst vollständig folgende Dokumente:
+- @CLAUDE.md
+- @docs/workpackages/M9 - Arbeitspakete.md
+
+Führe ein vollständiges Review von **AP-005 – Konfigurationspfad-Semantik für GUI und headless vervollständigen** durch.
+
+Prüfe jeden Punkt einzeln und antworte je Punkt mit BESTANDEN oder NICHT BESTANDEN + kurzer Begründung:
+
+1. Funktioniert `--config <pfad>` mit einer existierenden Datei sowohl im GUI- als auch im headless Start korrekt?
+2. Zeigt die GUI bei nicht existenter `--config`-Datei eine Fehlermeldung und verhält sich danach wie ohne `--config`?
+3. Führt `--config <pfad>` mit nicht existenter Datei im headless Start zu einem harten Startfehler (Exit-Code 1) ohne stillen Fallback?
+4. Bleibt das bestehende headless Default-Verhalten ohne `--config` nachweislich unangetastet?
+5. Gibt es kontrollierte Rückmeldungen für problematische Konfigurationspfade?
+6. Entsprechen alle neuen/geänderten öffentlichen Klassen und Methoden dem JavaDoc-Standard (inkl. package-info.java)?
+7. Wurde kein Vorgriff auf AP-006 oder spätere Arbeitspakete gemacht (insbesondere keine Datei-Dialoge, keine inhaltliche Validierung)?
+8. Ist der headless Batch-Betrieb nachweislich nicht gebrochen?
+9. Ist der Build fehlerfrei?
+
+Führe den Build selbst aus, um Punkt 9 zu verifizieren.
+
+Abschließendes Gesamturteil: **BESTANDEN** / **NICHT BESTANDEN**
+Bei NICHT BESTANDEN: Liste konkret alle zu behebenden Punkte auf.

docs/prompts/M9-AP-005-umsetzen.md

@@ -0,0 +1,27 @@
+Lies zunächst vollständig folgende Dokumente:
+- @CLAUDE.md
+- @docs/specs/meilensteine-v2_0.md
+- @docs/workpackages/M9 - Arbeitspakete.md
+
+AP-001 bis AP-004 sind abgeschlossen. Setze jetzt ausschließlich **AP-005 – Konfigurationspfad-Semantik für GUI und headless vervollständigen** um.
+
+Scope:
+- Verhalten für existierende Konfigurationsdateien in GUI und headless vervollständigen
+- Verhalten für nicht existente Konfigurationsdateien explizit umsetzen:
+  - GUI: Fehlermeldung, danach GUI-Start wie ohne `--config`
+  - headless: harter Startfehler (Exit-Code 1), kein stiller Fallback
+- Sicherstellen, dass das bestehende Default-Verhalten für headless ohne `--config` unangetastet bleibt
+- Kontrollierte Rückmeldungen für problematische Konfigurationspfade ergänzen
+- JavaDoc für die endgültige M9-Semantik von `--config` ergänzen
+
+Nicht umsetzen:
+- Bearbeiten oder Speichern der Konfiguration in der GUI
+- Datei-Dialoge
+- Neue Konfigurationswerte
+- Inhaltliche Validierung der .properties
+- Jegliche Inhalte aus AP-006 oder später
+
+Halte dich strikt an die Architekturregeln und den JavaDoc-Standard aus CLAUDE.md.
+Führe am Ende einen fehlerfreien Build durch.
+
+Erstelle abschließend den Pflicht-Output gemäß CLAUDE.md.

docs/prompts/M9-AP-006-review.md

@@ -0,0 +1,23 @@
+Lies zunächst vollständig folgende Dokumente:
+- @CLAUDE.md
+- @docs/workpackages/M9 - Arbeitspakete.md
+
+Führe ein vollständiges Review von **AP-006 – Packaging-Basis für gemeinsames JAR mit integrierter JavaFX-Laufzeit herstellen** durch.
+
+Prüfe jeden Punkt einzeln und antworte je Punkt mit BESTANDEN oder NICHT BESTANDEN + kurzer Begründung:
+
+1. Wird weiterhin genau ein gemeinsames ausführbares JAR erzeugt?
+2. Ist die JavaFX-Laufzeit im JAR integriert und trägt das JAR den GUI-Start technisch?
+3. Kann der headless Startpfad nachweislich ohne Initialisierung der JavaFX-Application-Klasse durchlaufen?
+4. Erzwingt der headless Startpfad keine unnötig frühe JavaFX-Initialisierung?
+5. Wurden keine EXE und kein Installer eingeführt?
+6. Ist die bestehende Artefakterzeugung nicht still zerstört worden?
+7. Entsprechen alle neuen/geänderten öffentlichen Klassen und Methoden dem JavaDoc-Standard (inkl. package-info.java)?
+8. Wurde kein Vorgriff auf AP-007 oder spätere Arbeitspakete gemacht?
+9. Ist der headless Batch-Betrieb nachweislich nicht gebrochen?
+10. Ist der Build fehlerfrei und das JAR reproduzierbar erzeugbar?
+
+Führe den Build selbst aus, um Punkte 9 und 10 zu verifizieren.
+
+Abschließendes Gesamturteil: **BESTANDEN** / **NICHT BESTANDEN**
+Bei NICHT BESTANDEN: Liste konkret alle zu behebenden Punkte auf.

docs/prompts/M9-AP-006-umsetzen.md

@@ -0,0 +1,27 @@
+Lies zunächst vollständig folgende Dokumente:
+- @CLAUDE.md
+- @docs/specs/meilensteine-v2_0.md
+- @docs/workpackages/M9 - Arbeitspakete.md
+
+AP-001 bis AP-005 sind abgeschlossen. Setze jetzt ausschließlich **AP-006 – Packaging-Basis für gemeinsames JAR mit integrierter JavaFX-Laufzeit herstellen** um.
+
+Scope:
+- Build-/Packaging-Konfiguration so erweitern, dass weiterhin ein gemeinsames ausführbares JAR entsteht
+- JavaFX-Laufzeit und erforderliche GUI-Bestandteile in das Artefakt integrieren (für Windows-GUI-Start)
+- Sicherstellen, dass der headless Startpfad keine unnötig frühe JavaFX-Initialisierung erzwingt
+- Konkret absichern, dass der headless Startpfad ohne Initialisierung der JavaFX-Application-Klasse durchlaufen kann
+- Packaging so schneiden, dass keine EXE und kein Installer eingeführt werden
+- Bestehende Artefakterzeugung aus V1.1 nicht still zerstören
+- Dokumentierende Build-Hinweise ergänzen, soweit für M9 zwingend nötig
+
+Nicht umsetzen:
+- Vollständige Enddokumentation von V2.0
+- M10-GUI-Funktionalität
+- Plattformübergreifendes Packaging
+- EXE-/Installer-Bau
+- Jegliche Inhalte aus AP-007 oder später
+
+Halte dich strikt an die Architekturregeln und den JavaDoc-Standard aus CLAUDE.md.
+Führe am Ende einen fehlerfreien Build durch und stelle sicher, dass das JAR erzeugt wird.
+
+Erstelle abschließend den Pflicht-Output gemäß CLAUDE.md.

docs/prompts/M9-AP-007-review.md

@@ -0,0 +1,24 @@
+Lies zunächst vollständig folgende Dokumente:
+- @CLAUDE.md
+- @docs/workpackages/M9 - Arbeitspakete.md
+
+Führe ein vollständiges Review von **AP-007 – Start-, Fehler- und Packaging-Tests für den vollständigen M9-Zielstand vervollständigen** durch.
+
+Prüfe jeden Punkt einzeln und antworte je Punkt mit BESTANDEN oder NICHT BESTANDEN + kurzer Begründung:
+
+1. Gibt es Tests für den GUI-Standardstart (unter headless JavaFX/Monocle, kein TestFX)?
+2. Gibt es Tests für `--headless`?
+3. Gibt es einen automatisierten Nachweis, dass der headless Start ohne Initialisierung der JavaFX-Application-Klasse durchläuft?
+4. Gibt es Tests für `--config <pfad>` in beiden Startarten?
+5. Gibt es Negativtests für alle drei Fehlerpfade (GUI mit nicht existenter Datei, headless mit nicht existenter Datei, `--config` ohne Wert)?
+6. Gibt es Tests, die das bisherige headless Default-Verhalten ohne `--config` absichern?
+7. Gibt es Smoke-Tests für die Artefakterzeugung?
+8. Ist die bestehende Batch-Funktionalität gegen Regression abgesichert?
+9. Ist der gesamte M9-Stand architekturtreu, abwärtskompatibel und ohne Vorgriff auf M10+?
+10. Entsprechen alle neuen/geänderten öffentlichen Klassen und Methoden dem JavaDoc-Standard (inkl. package-info.java)?
+11. Ist der vollständige Build inkl. aller Tests fehlerfrei?
+
+Führe den vollständigen Build selbst aus (`.\mvnw.cmd clean verify`), um Punkt 11 zu verifizieren.
+
+Abschließendes Gesamturteil: **BESTANDEN** / **NICHT BESTANDEN**
+Bei NICHT BESTANDEN: Liste konkret alle zu behebenden Punkte auf.

docs/prompts/M9-AP-007-umsetzen.md

@@ -0,0 +1,31 @@
+Lies zunächst vollständig folgende Dokumente:
+- @CLAUDE.md
+- @docs/specs/meilensteine-v2_0.md
+- @docs/workpackages/M9 - Arbeitspakete.md
+
+AP-001 bis AP-006 sind abgeschlossen. Setze jetzt ausschließlich **AP-007 – Start-, Fehler- und Packaging-Tests für den vollständigen M9-Zielstand vervollständigen** um.
+
+Scope:
+- Tests für den GUI-Standardstart gemäß der in CLAUDE.md festgelegten GUI-Teststrategie (Monocle, kein TestFX)
+- Tests für `--headless`
+- Automatisierten Nachweis, dass der headless Start ohne Initialisierung der JavaFX-Application-Klasse durchlaufen kann
+- Tests für `--config <pfad>` in beiden Startarten
+- Negativtests für ungültige oder fehlende Konfigurationspfade:
+  - GUI mit nicht existenter Konfigurationsdatei
+  - headless mit nicht existenter Konfigurationsdatei
+  - `--config` ohne Wert
+- Tests, die belegen, dass headless ohne `--config` weiterhin das bisherige Default-Verhalten nutzt
+- Smoke-Tests für die Artefakterzeugung und Packaging-Basis
+- Sicherstellen, dass dokumentbezogene Batch-Funktionalität nicht versehentlich regressiert ist
+- Abschließende Prüfung des M9-Stands auf Architekturtreue, Abwärtskompatibilität und Nicht-Vorgriff auf M10+
+
+Nicht umsetzen:
+- GUI-Editor-Tests aus M10
+- Validierungs- und Modellabruf-Tests aus M11
+- Technische Test- und Korrekturhilfe-Tests aus M12
+- Abschlussdokumentation aus M13
+
+Halte dich strikt an die GUI-Teststrategie und den JavaDoc-Standard aus CLAUDE.md.
+Führe am Ende einen vollständigen fehlerfreien Build inkl. aller Tests durch.
+
+Erstelle abschließend den Pflicht-Output gemäß CLAUDE.md.

docs/prompts/M9-meilenstein-review-chatgpt.md

@@ -0,0 +1,87 @@
+# Meilenstein-Review M9 – GUI-Grundgerüst, neues Betriebsmodell und Packaging-Basis
+
+## Kontext
+
+Dieses Dokument enthält den vollständigen Umsetzungsstand von Meilenstein M9 des Projekts **PDF-Umbenenner V2.0** zur unabhängigen Bewertung.
+
+Das Projekt ist ein lokal gestarteter PDF-Umbenenner mit KI-Unterstützung. M9 erweitert die bisher reine Batch-Anwendung um das technische Grundgerüst einer JavaFX-Desktop-GUI, ohne den bestehenden headless Batch-Betrieb zu verlieren.
+
+---
+
+## Architekturprinzipien (verbindlich)
+
+- Strikte hexagonale Architektur / Ports and Adapters
+- Abhängigkeiten zeigen immer nach innen
+- Domain und Application sind frei von JavaFX-Typen
+- GUI ist ein eigenständiger Inbound-Adapter (`pdf-umbenenner-adapter-in-gui`)
+- Bootstrap ist verantwortlich für Startmoduswahl, Konfigurationsauflösung und Objektgraph
+- GUI-Code darf den headless Pfad nicht unnötig früh initialisieren
+- Jede potenziell blockierende GUI-Operation läuft auf einem Hintergrund-Worker-Thread; UI-Updates ausschließlich via Platform.runLater
+
+## Modulstruktur (ab M9)
+
+- `pdf-umbenenner-domain`
+- `pdf-umbenenner-application`
+- `pdf-umbenenner-adapter-in-cli`
+- `pdf-umbenenner-adapter-in-gui` ← NEU
+- `pdf-umbenenner-adapter-out`
+- `pdf-umbenenner-bootstrap`
+
+## M9-Zielumfang
+
+- Neues Modul `pdf-umbenenner-adapter-in-gui` als Inbound-Adapter
+- GUI als neuer Standardstart
+- `--headless` als erhaltener Batch-/Scheduler-Pfad
+- Neue CLI-Option `--config <pfad>` für beide Startarten
+- Kontrollierte, unterschiedliche Fehlersemantik für GUI und headless bei nicht existenter Konfigurationsdatei
+- Minimale JavaFX-GUI-Shell als technischer Nachweis des GUI-Starts
+- Ein gemeinsames ausführbares JAR mit integrierter JavaFX-Basis
+- Headless ohne unnötige GUI-Initialisierung
+- Tests für Startverhalten, Fehlerpfade und Packaging
+
+## Explizit NICHT Teil von M9
+
+- GUI-Konfigurationseditor (M10)
+- Provider-ComboBox, Modellabruf (M11)
+- Technische Tests und Korrekturhilfen (M12)
+- EXE, Installer
+- Änderungen an der fachlichen Kernverarbeitung
+
+---
+
+## Reports der Arbeitspakete AP-001 bis AP-007
+
+[HIER DIE REPORTS AUS DER M9-FORTSCHRITT.LOG EINFÜGEN]
+
+---
+
+## Bitte bewerte folgende Punkte
+
+Bewerte jeden Punkt mit: **BESTANDEN** / **NICHT BESTANDEN** / **UNKLAR** + Begründung
+
+### Architektur
+1. Ist die hexagonale Architektur in allen Modulen konsequent eingehalten?
+2. Sind Domain und Application nachweislich frei von JavaFX-Typen?
+3. Ist die GUI sauber als Inbound-Adapter umgesetzt und nicht in Bootstrap vermischt?
+4. Sind die Abhängigkeitsrichtungen korrekt (Adapter → Application → Domain)?
+
+### Betriebsmodell
+5. Ist GUI als Standardstart korrekt umgesetzt?
+6. Bleibt `--headless` vollständig abwärtskompatibel?
+7. Funktioniert `--config <pfad>` in beiden Startarten korrekt?
+8. Ist die unterschiedliche Fehlersemantik für GUI und headless bei nicht existenter Konfigurationsdatei korrekt umgesetzt?
+
+### Packaging
+9. Entsteht genau ein gemeinsames ausführbares JAR?
+10. Ist JavaFX im JAR integriert?
+11. Kann der headless Pfad das JAR ohne JavaFX-Application-Initialisierung durchlaufen?
+
+### Qualität
+12. Ist der JavaDoc-Standard für neue/geänderte Klassen und Methoden eingehalten?
+13. Sind die Tests vollständig und sinnvoll (GUI-Smoke unter Monocle, Negativtests, Regressionstests)?
+14. Wurde kein Vorgriff auf M10+ gemacht?
+
+### Gesamtbewertung
+15. Ist M9 als vollständiger, übergabefähiger Meilensteinstand freigabefähig?
+
+Falls NICHT BESTANDEN oder UNKLAR: Bitte konkrete Nachbesserungspunkte benennen.