marcus/pdf-umbenenner
1
0
Fork 0
Code Activity
Files
f74e3d6d73cacda6b65051dd9f5501e86046016d
pdf-umbenenner/docs/prompts/M9-meilenstein-review-chatgpt.md

3.5 KiB
Raw Blame History

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

  1. Ist GUI als Standardstart korrekt umgesetzt?
  2. Bleibt --headless vollständig abwärtskompatibel?
  3. Funktioniert --config <pfad> in beiden Startarten korrekt?
  4. Ist die unterschiedliche Fehlersemantik für GUI und headless bei nicht existenter Konfigurationsdatei korrekt umgesetzt?

Packaging

  1. Entsteht genau ein gemeinsames ausführbares JAR?
  2. Ist JavaFX im JAR integriert?
  3. Kann der headless Pfad das JAR ohne JavaFX-Application-Initialisierung durchlaufen?

Qualität

  1. Ist der JavaDoc-Standard für neue/geänderte Klassen und Methoden eingehalten?
  2. Sind die Tests vollständig und sinnvoll (GUI-Smoke unter Monocle, Negativtests, Regressionstests)?
  3. Wurde kein Vorgriff auf M10+ gemacht?

Gesamtbewertung

  1. Ist M9 als vollständiger, übergabefähiger Meilensteinstand freigabefähig?

Falls NICHT BESTANDEN oder UNKLAR: Bitte konkrete Nachbesserungspunkte benennen.

View Git Blame Copy Permalink