From 6d4654f482d548a71d2663d2db14c081ca8363a4 Mon Sep 17 00:00:00 2001 From: Marcus van Elst Date: Mon, 20 Apr 2026 13:09:16 +0200 Subject: [PATCH] =?UTF-8?q?Nicht=20zum=20Projekt=20dazugeh=C3=B6rige=20Dat?= =?UTF-8?q?eien=20entfernen?= 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 deletions(-) delete mode 100644 docs/prompts/M9-AP-001-review.md delete mode 100644 docs/prompts/M9-AP-001-umsetzen.md delete mode 100644 docs/prompts/M9-AP-002-review.md delete mode 100644 docs/prompts/M9-AP-002-umsetzen.md delete mode 100644 docs/prompts/M9-AP-003-review.md delete mode 100644 docs/prompts/M9-AP-003-umsetzen.md delete mode 100644 docs/prompts/M9-AP-004-review.md delete mode 100644 docs/prompts/M9-AP-004-umsetzen.md delete mode 100644 docs/prompts/M9-AP-005-review.md delete mode 100644 docs/prompts/M9-AP-005-umsetzen.md delete mode 100644 docs/prompts/M9-AP-006-review.md delete mode 100644 docs/prompts/M9-AP-006-umsetzen.md delete mode 100644 docs/prompts/M9-AP-007-review.md delete mode 100644 docs/prompts/M9-AP-007-umsetzen.md delete 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 deleted file mode 100644 index ca51a4c..0000000 --- a/docs/prompts/M9-AP-001-review.md +++ /dev/null @@ -1,20 +0,0 @@ -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 deleted file mode 100644 index 0005cbb..0000000 --- a/docs/prompts/M9-AP-001-umsetzen.md +++ /dev/null @@ -1,27 +0,0 @@ -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 deleted file mode 100644 index 8cc1630..0000000 --- a/docs/prompts/M9-AP-002-review.md +++ /dev/null @@ -1,22 +0,0 @@ -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 deleted file mode 100644 index ca04d44..0000000 --- a/docs/prompts/M9-AP-002-umsetzen.md +++ /dev/null @@ -1,27 +0,0 @@ -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 deleted file mode 100644 index a3b4a2e..0000000 --- a/docs/prompts/M9-AP-003-review.md +++ /dev/null @@ -1,22 +0,0 @@ -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 deleted file mode 100644 index ae482ef..0000000 --- a/docs/prompts/M9-AP-003-umsetzen.md +++ /dev/null @@ -1,26 +0,0 @@ -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 deleted file mode 100644 index bc373a8..0000000 --- a/docs/prompts/M9-AP-004-review.md +++ /dev/null @@ -1,23 +0,0 @@ -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 deleted file mode 100644 index e87826c..0000000 --- a/docs/prompts/M9-AP-004-umsetzen.md +++ /dev/null @@ -1,27 +0,0 @@ -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 deleted file mode 100644 index b4cf196..0000000 --- a/docs/prompts/M9-AP-005-review.md +++ /dev/null @@ -1,22 +0,0 @@ -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 deleted file mode 100644 index 8d9de14..0000000 --- a/docs/prompts/M9-AP-005-umsetzen.md +++ /dev/null @@ -1,27 +0,0 @@ -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 deleted file mode 100644 index 5612438..0000000 --- a/docs/prompts/M9-AP-006-review.md +++ /dev/null @@ -1,23 +0,0 @@ -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 deleted file mode 100644 index b050230..0000000 --- a/docs/prompts/M9-AP-006-umsetzen.md +++ /dev/null @@ -1,27 +0,0 @@ -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 deleted file mode 100644 index 63e0ece..0000000 --- a/docs/prompts/M9-AP-007-review.md +++ /dev/null @@ -1,24 +0,0 @@ -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 deleted file mode 100644 index 0675a74..0000000 --- a/docs/prompts/M9-AP-007-umsetzen.md +++ /dev/null @@ -1,31 +0,0 @@ -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 deleted file mode 100644 index ca9ac13..0000000 --- a/docs/prompts/M9-meilenstein-review-chatgpt.md +++ /dev/null @@ -1,87 +0,0 @@ -# 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.