From f74e3d6d73cacda6b65051dd9f5501e86046016d Mon Sep 17 00:00:00 2001 From: Marcus van Elst Date: Mon, 13 Apr 2026 09:05:56 +0200 Subject: [PATCH] =?UTF-8?q?Arbeitspakete=20+=20Review=20f=C3=BCr=20M9=20an?= =?UTF-8?q?gelegt?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- docs/prompts/M9-AP-001-review.md | 20 +++++ docs/prompts/M9-AP-001-umsetzen.md | 27 ++++++ docs/prompts/M9-AP-002-review.md | 22 +++++ docs/prompts/M9-AP-002-umsetzen.md | 27 ++++++ docs/prompts/M9-AP-003-review.md | 22 +++++ docs/prompts/M9-AP-003-umsetzen.md | 26 ++++++ docs/prompts/M9-AP-004-review.md | 23 +++++ docs/prompts/M9-AP-004-umsetzen.md | 27 ++++++ docs/prompts/M9-AP-005-review.md | 22 +++++ docs/prompts/M9-AP-005-umsetzen.md | 27 ++++++ docs/prompts/M9-AP-006-review.md | 23 +++++ docs/prompts/M9-AP-006-umsetzen.md | 27 ++++++ docs/prompts/M9-AP-007-review.md | 24 +++++ docs/prompts/M9-AP-007-umsetzen.md | 31 +++++++ docs/prompts/M9-meilenstein-review-chatgpt.md | 87 +++++++++++++++++++ 15 files changed, 435 insertions(+) create mode 100644 docs/prompts/M9-AP-001-review.md create mode 100644 docs/prompts/M9-AP-001-umsetzen.md create mode 100644 docs/prompts/M9-AP-002-review.md create mode 100644 docs/prompts/M9-AP-002-umsetzen.md create mode 100644 docs/prompts/M9-AP-003-review.md create mode 100644 docs/prompts/M9-AP-003-umsetzen.md create mode 100644 docs/prompts/M9-AP-004-review.md create mode 100644 docs/prompts/M9-AP-004-umsetzen.md create mode 100644 docs/prompts/M9-AP-005-review.md create mode 100644 docs/prompts/M9-AP-005-umsetzen.md create mode 100644 docs/prompts/M9-AP-006-review.md create mode 100644 docs/prompts/M9-AP-006-umsetzen.md create mode 100644 docs/prompts/M9-AP-007-review.md create mode 100644 docs/prompts/M9-AP-007-umsetzen.md create mode 100644 docs/prompts/M9-meilenstein-review-chatgpt.md diff --git a/docs/prompts/M9-AP-001-review.md b/docs/prompts/M9-AP-001-review.md new file mode 100644 index 0000000..ca51a4c --- /dev/null +++ b/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. diff --git a/docs/prompts/M9-AP-001-umsetzen.md b/docs/prompts/M9-AP-001-umsetzen.md new file mode 100644 index 0000000..0005cbb --- /dev/null +++ b/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. diff --git a/docs/prompts/M9-AP-002-review.md b/docs/prompts/M9-AP-002-review.md new file mode 100644 index 0000000..8cc1630 --- /dev/null +++ b/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 ` 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. diff --git a/docs/prompts/M9-AP-002-umsetzen.md b/docs/prompts/M9-AP-002-umsetzen.md new file mode 100644 index 0000000..ca04d44 --- /dev/null +++ b/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 ` 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. diff --git a/docs/prompts/M9-AP-003-review.md b/docs/prompts/M9-AP-003-review.md new file mode 100644 index 0000000..a3b4a2e --- /dev/null +++ b/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. diff --git a/docs/prompts/M9-AP-003-umsetzen.md b/docs/prompts/M9-AP-003-umsetzen.md new file mode 100644 index 0000000..ae482ef --- /dev/null +++ b/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. diff --git a/docs/prompts/M9-AP-004-review.md b/docs/prompts/M9-AP-004-review.md new file mode 100644 index 0000000..bc373a8 --- /dev/null +++ b/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. diff --git a/docs/prompts/M9-AP-004-umsetzen.md b/docs/prompts/M9-AP-004-umsetzen.md new file mode 100644 index 0000000..e87826c --- /dev/null +++ b/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. diff --git a/docs/prompts/M9-AP-005-review.md b/docs/prompts/M9-AP-005-review.md new file mode 100644 index 0000000..b4cf196 --- /dev/null +++ b/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 ` 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 ` 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. diff --git a/docs/prompts/M9-AP-005-umsetzen.md b/docs/prompts/M9-AP-005-umsetzen.md new file mode 100644 index 0000000..8d9de14 --- /dev/null +++ b/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. diff --git a/docs/prompts/M9-AP-006-review.md b/docs/prompts/M9-AP-006-review.md new file mode 100644 index 0000000..5612438 --- /dev/null +++ b/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. diff --git a/docs/prompts/M9-AP-006-umsetzen.md b/docs/prompts/M9-AP-006-umsetzen.md new file mode 100644 index 0000000..b050230 --- /dev/null +++ b/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. diff --git a/docs/prompts/M9-AP-007-review.md b/docs/prompts/M9-AP-007-review.md new file mode 100644 index 0000000..63e0ece --- /dev/null +++ b/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 ` 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. diff --git a/docs/prompts/M9-AP-007-umsetzen.md b/docs/prompts/M9-AP-007-umsetzen.md new file mode 100644 index 0000000..0675a74 --- /dev/null +++ b/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 ` 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. diff --git a/docs/prompts/M9-meilenstein-review-chatgpt.md b/docs/prompts/M9-meilenstein-review-chatgpt.md new file mode 100644 index 0000000..ca9ac13 --- /dev/null +++ b/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 ` 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 ` 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.