pdf-umbenenner/docs/specs/meilensteine-v2_0.md

Meilensteine V2.0 – JavaFX-GUI, Konfigurationskomfort und technischer Ausbau

Zweck dieses Dokuments

Dieses Dokument beschreibt den geplanten Ausbau des Projekts ab dem final freigegebenen Stand V1.1 hin zu V2.0 sowie einen klar abgegrenzten Ausblick auf spätere Ausbaustufen.

Es ergänzt die bestehenden Spezifikationsdokumente und den dokumentierten Ist-Stand V1.1 um eine neue, bewusst größere Produktstufe. V2.0 erweitert die bisher reine Batch-Anwendung um eine lokale JavaFX-Desktop-GUI, ohne die bestehende Architektur, das Standalone-JAR-Betriebsmodell oder den headless Scheduler-Betrieb aufzugeben.

Das Dokument ist als Planungs- und Strukturierungsgrundlage gedacht. Es definiert keine Arbeitspakete, sondern die neuen Meilensteine, Abgrenzungen und Ausbaustufen für den nächsten Entwicklungsschritt.

---

Einordnung von V2.0

Ausgangsbasis

V1.1 ist der aktuelle, fertig implementierte und abgenommene Stand des Projekts.

Darauf aufbauend gilt:

• V1 ist fachlich und technisch vollständig umgesetzt.
• V1.1 erweitert V1 minimal-invasiv um native Claude-Unterstützung.
• Das bisherige Betriebsmodell bleibt ein lokal gestartetes Standalone-JAR.
• Der Batch-Betrieb über Windows Task Scheduler bleibt weiterhin erhalten.
• Die Anwendung arbeitet bisher ohne GUI, ohne Webserver, ohne App-Server.
• Die technische Konfiguration erfolgt weiterhin über .properties.
• Es gibt bereits mehrere Provider-Konfigurationen, aber immer genau einen aktiven Provider.

Warum V2.0 und nicht V1.x

Der geplante GUI-Ausbau ist kein kleiner Nachschlag zu V1.1, sondern eine neue Produktstufe.

V2.0 ist gerechtfertigt, weil gleichzeitig neu hinzukommen:

• neuer Standard-Startmodus über eine Desktop-GUI
• zusätzlicher Inbound-Adapter für JavaFX
• neuer Benutzerzugang zur Konfiguration
• technische Tests und Korrekturhilfen in der GUI
• neue CLI-Option --config <pfad> für beide Startarten
• Windows-zentrierte Desktop-Unterstützung mit gemappten Laufwerken

V2.0 bleibt jedoch architekturtreu und bewahrt das bisherige Kernziel der Anwendung:

PDFs automatisiert scannen, fachlich verarbeiten und korrekt benannte Zielkopien erzeugen.

---

Unveränderte Leitplanken auch in V2.0

Die folgenden Grundprinzipien bleiben in V2.0 ausdrücklich erhalten:

• Java 21
• Maven Multi-Module
• ausführbares Standalone-JAR
• kein Webserver
• kein Applikationsserver
• keine Dauerlauf-Anwendung
• kein interner Scheduler
• strikte hexagonale Architektur / Ports and Adapters
• Abhängigkeiten zeigen nach innen
• .properties bleibt die einzige Konfigurationswahrheit
• bestehender headless Batch-Betrieb bleibt erhalten
• genau ein aktiver Provider
• keine neue Persistenz-Wahrheit
• fachliche Kernlogik des PDF-Umbenenners bleibt unverändert

---

Zielbild von V2.0

V2.0 erweitert die Anwendung um eine lokale JavaFX-Desktop-GUI.

Start- und Betriebsmodell in V2.0

• Die Anwendung bleibt ein einziges ausführbares JAR.
• GUI ist der neue Standardstart.
• Über --headless startet weiterhin der bestehende Server-/Scheduler-Betrieb.
• Über --config <pfad> kann sowohl der GUI- als auch der headless Start auf eine konkrete Konfigurationsdatei zeigen.
• Bestehendes headless Standardverhalten ohne --config bleibt aus Abwärtskompatibilitätsgründen erhalten.
• Wenn --config <pfad> im headless Start auf eine nicht existente Datei zeigt, ist dies ein harter Startfehler; ein stiller Fallback auf das Default-Verhalten ist in diesem Fall unzulässig.
• Wenn --config <pfad> im GUI-Start auf eine nicht existente Datei zeigt:
  • erscheint eine Fehlermeldung,
  • danach verhält sich die GUI so, als wäre --config nicht angegeben worden.

Plattformziel

• V2.0-GUI wird offiziell nur unter Windows unterstützt.
• Der headless Betrieb bleibt für den Windows Server-Betrieb geeignet.
• Gemappte Laufwerke wie S:\ oder H:\ sind ausdrücklich zu unterstützen.
• Eine Ablehnung solcher Pfade allein wegen eines dahinterliegenden UNC-Backings ist unzulässig.

GUI-Threadingmodell

Jede potenziell blockierende Operation der GUI – insbesondere providerseitiger Modellabruf, providerseitige technische Tests, Pfad- und Dateisystemprüfungen, SQLite-Prüfungen sowie das Lesen und Schreiben der .properties-Datei – läuft auf einem Hintergrund-Worker-Thread. UI-Updates erfolgen ausschließlich über den JavaFX Application Thread (Platform.runLater). Die GUI darf während laufender Hintergrund-Operationen nicht einfrieren.

Packaging-Ziel

• JavaFX wird mit dem JAR ausgeliefert.
• Es gibt in V2.0 keine EXE.
• Es gibt in V2.0 keinen Installer.
• --headless darf logisch weiterhin ohne GUI-Pfadzweige funktionieren; GUI-Code darf den headless Ablauf nicht unnötig früh initialisieren.

Modulziel in V2.0

Die Modulstruktur wird um genau ein neues Modul erweitert:

• pdf-umbenenner-domain
• pdf-umbenenner-application
• pdf-umbenenner-adapter-in-cli
• pdf-umbenenner-adapter-in-gui
• pdf-umbenenner-adapter-out
• pdf-umbenenner-bootstrap

Die GUI wird nicht im Bootstrap-Modul vermischt, sondern als eigener Inbound-Adapter umgesetzt.

Logging in der GUI

Der GUI-Adapter nutzt denselben Log4j2-Stack wie der headless Pfad. Mindestens geloggt werden: Start- und Beendigungsereignisse der GUI, Modellabruf-Versuche (Provider, Erfolg/Misserfolg, ohne API-Key), Dateischreibvorgänge inkl. Zielpfad, Ergebnisse der Aktionen Validieren und Technische Tests ausführen, sowie alle schreibenden Korrekturen. Das Logformat und der Log-Pfad bleiben gegenüber dem headless Betrieb unverändert.

Exit-Codes

• 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 im headless Lauf ändern dieses Exit-Code-Modell nicht; sie bleiben Teil des fachlichen Laufresultats wie bereits in V1.1.

---

V2.0-Funktionsumfang

1. GUI als Konfigurations- und Diagnose-Frontend

V2.0 führt noch keinen manuellen Verarbeitungslauf in der GUI ein.

Die V2.0-GUI dient zunächst ausschließlich als:

• Editor für die bestehende .properties-Konfiguration
• technische Validierungsoberfläche
• technische Test- und Diagnoseoberfläche
• komfortable Dateiauswahl- und Speichermaske

2. Struktur der V2.0-GUI

V2.0 enthält genau einen Tab mit einer klaren, festen Gliederung.

Reihenfolge:

1. Header mit Konfigurationsdatei
2. Pfade
3. Provider
4. Verarbeitungslimits
5. Tests
6. Meldungen

Beim Start ohne geladene Konfiguration wird kein leerer Standardentwurf angezeigt. Stattdessen erscheint ein deutscher Willkommenstext mit Hinweis auf „Neu“ und „Öffnen“.

3. Dateiverhalten der GUI

• Es wird keine Konfiguration automatisch geladen.
• Die GUI kann bestehende .properties-Dateien öffnen.
• Die GUI kann neue Konfigurationen anlegen.
• Eine neue Konfiguration startet mit einer vollständigen Standardvorlage mit sinnvollen Standardwerten.
• Beide bekannten Provider-Blöcke sind in der Datei vorhanden.
• Standardmäßig ist der alphabetisch erste vorhandene Provider aktiv; im aktuellen Stand ist das Claude.
• Speichern ist immer erlaubt.
• Bei einer neuen, noch nie gespeicherten Konfiguration verhält sich „Speichern“ 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.
• Bei existierender Zieldatei erscheint die 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, …).
• Datei-Dialoge filtern auf *.properties.
• Ungespeicherte Änderungen werden im Fenstertitel und im Header markiert.
• Vor Neu, Öffnen oder Schließen erscheint bei ungespeicherten Änderungen ein Dialog mit:
  • Speichern
  • Verwerfen
  • Abbrechen

4. Umgang mit der bestehenden Konfigurationsdatei

• Die GUI liest, bearbeitet und schreibt dieselbe .properties-Datei wie der headless Betrieb.
• Wenn die GUI eine Datei in der Legacy-Form aus Vor-V1.1 öffnet, wendet sie dieselbe Migrationslogik wie der headless Pfad an: zuerst .bak-Sicherung der Originaldatei, dann Überführung in das neue Mehrprovider-Schema, dann Anzeige im Editor. Dem Benutzer wird die durchgeführte Migration sichtbar im zentralen Meldungsbereich gemeldet.
• Kommentare und Reihenfolge dürfen beim Speichern normalisiert werden.
• Die GUI darf alle aktuell bekannten Konfigurationswerte bearbeiten.
• Es wird kein neues Konfigurationsformat eingeführt.

5. Provider-Bereich in V2.0

• Es gibt eine Provider-ComboBox.
• Sichtbar ist immer nur der aktuell ausgewählte Provider-Bereich.
• Ein Provider-Wechsel löscht die Daten des anderen Providers nicht.
• Die GUI muss also mit der bestehenden Mehrprovider-Dateistruktur kompatibel bleiben.
• Sichtbare Providerbezeichnungen können zunächst pragmatisch sein, z. B.:
  • Claude
  • OpenAI-kompatibel

6. Modellwahl in V2.0

• Nach Providerwechsel startet der Modellabruf automatisch.
• Wenn eine Modellliste erfolgreich geladen werden kann:
  • erscheint eine nicht editierbare ComboBox,
  • die nie leer ist,
  • deren erstes Modell automatisch vorbelegt ist.
• Wenn keine Modellliste verfügbar ist:
  • erscheint statt der ComboBox ein leeres Texteingabefeld,
  • das Modell muss dann manuell eingetragen werden.
• Ein zuvor manuell eingetragener Modellname wird verworfen, wenn später eine echte Modellliste geladen wird und der Wert dort nicht vorkommt.

7. Felder, Picker und Pfadangaben

Für folgende Pfade gibt es jeweils:

• ein Texteingabefeld
• plus einen kleinen nativen Datei-/Ordnerdialog-Button

Dies gilt mindestens für:

• Quellordner
• Zielordner
• SQLite-Datei
• Prompt-Datei

8. API-Key in V2.0

• Der API-Key wird direkt in der .properties-Datei gespeichert und bearbeitet.
• Die GUI respektiert dabei die bestehende V1.1-Auflösungsreihenfolge:
  1. providerspezifische Umgebungsvariable,
  2. bei OpenAI-kompatibel zusätzlich die bestehende Legacy-Umgebungsvariable,
  3. Property-Wert aus der .properties-Datei.
• Die GUI macht diese Herkunft für den Benutzer sichtbar, insbesondere wenn aktuell eine Umgebungsvariable Vorrang vor dem in der Datei eingetragenen Wert hat.
• Das GUI-Feld ist bewusst als normales, unmaskiertes Textfeld vorgesehen; dies ist eine pragmatische V2.0-Entscheidung und keine Sicherheitsbehauptung.
• Ein leeres GUI-Feld darf einen bereits vorhandenen Property-Wert nicht stillschweigend löschen, wenn keine Umgebungsvariable greift. In diesem Fall bleibt der bestehende Property-Wert erhalten und es erscheint eine deutliche Warnung.

9. Meldungen und feldnahe Validierung

V2.0 enthält zwei Ebenen der Benutzerführung:

A. zentraler Meldungsbereich unten

Der Meldungsbereich ist:

• groß
• nicht editierbar
• dauerhaft sichtbar

Er nutzt vier feste Stufen:

• Info
• Hinweis
• Warnung
• Fehler

Dabei gilt:

• nur das Präfix („Info:“, „Hinweis:“, „Warnung:“, „Fehler:“) ist farbig
• der eigentliche Text derselben Zeile bleibt schwarz

B. feldnahe Validierung

Bei Eingabefehlern erscheint direkt unter dem betroffenen Feld:

• eine kleine
• rote
• deutschsprachige
• hilfreiche Fehlermeldung

10. Automatische Validierung beim Öffnen und während der Bearbeitung

• Automatische Validierung bezeichnet in V2.0 die im Hintergrund laufende Prüfung aus M11.
• Eine geladene Konfiguration wird sofort beim Öffnen geprüft.
• Es gibt Fehler, Warnungen und Hinweise.
• Auch unsinnige, aber formal gültige Einstellungen werden als Warnung bewertet.
• max.text.characters erhält in V2.0 bewusst wirtschaftliche Warnschwellen:
  • bis 1.000: unkritisch
  • 1.001–3.000: Warnung
  • ab 3.001: starke Warnung
• max.pages dient in V2.0 nur als Plausibilitäts-/Performance-Hinweis, nicht als primäre Kostenwarnung.
• Warnungen verhindern das Speichern nicht.
• Fehler markieren den Zustand als nicht lauffähig.
• Speichern bleibt trotzdem erlaubt.
• Vor dem Speichern eines als nicht lauffähig markierten Stands erscheint jedoch eine deutlich sichtbare Warnung im zentralen Meldungsbereich, die ausdrücklich auf mögliche Auswirkungen auf den nächsten headless Lauf hinweist.

11. Aktion „Validieren“ und technische Tests

• Aktion „Validieren“ bezeichnet in V2.0 die explizite M12-Bedienhandlung über den gleichnamigen Button.
• Diese Aktion nutzt denselben Kernregelrahmen wie die automatische Validierung, darf aber zusätzliche lokale Prüfpunkte zusammenführen und schreibt nichts auf die Platte.

V2.0 enthält mindestens diese Aktionen:

• Neu
• Öffnen
• Speichern
• Speichern unter
• Validieren
• Technische Tests ausführen
• Modelle neu laden

Für Aktion „Validieren“ und „Technische Tests ausführen“ gilt:

• sie arbeiten auf dem aktuellen GUI-Zustand
• also auch auf ungespeicherten Änderungen
• die Datei wird dabei nicht implizit gespeichert
• ein Hinweis auf ungespeicherte Prüfgrundlage ist zweckmäßig

12. Umfang der technischen Tests in V2.0

Die technischen Tests werden in V2.0 nur als Gesamttest angeboten.

• kein Einzeltasten-Test pro Prüfpunkts
• kein Abbruch beim ersten Fehler
• alle Prüfpunkte werden vollständig durchlaufen
• alle Befunde werden gesammelt ausgegeben

Zu prüfen sind mindestens:

• Properties-Datei validieren
• Provider-Konfiguration prüfen
• Base-URL/Endpoint erreichbar
• API-Key vorhanden, auch wenn der effektive Wert ausschließlich über eine passende Umgebungsvariable bereitgestellt wird
• API-Key technisch akzeptiert
• Modellliste abrufbar
• gewähltes Modell plausibel
• Prompt-Datei vorhanden/lesbar
• Quellordner vorhanden/lesbar
• Zielordner vorhanden oder anlegbar/schreibbar
• SQLite-Datei bzw. Pfad nutzbar

13. Korrigierende technische Tests

V2.0 erlaubt bei technischen Tests auch korrigierende Maßnahmen, soweit diese sicher und lokal sinnvoll sind.

Beispiele:

• Zielordner anlegen
• SQLite-Datei anlegen
• Prompt-Datei anlegen
• technische Kleinkorrekturen übernehmen

Dabei gilt:

• Es erfolgt kein stilles Schreiben im Hintergrund.
• Vor schreibenden Korrekturen erscheint ein gesammelter Bestätigungsdialog:
  • „Folgende Korrekturen werden durchgeführt … Fortfahren?“

Nicht automatisch korrigierbar bleiben insbesondere:

• falscher API-Key
• unerreichbare Base-URL
• nicht verfügbare Modellliste
• sonstige externe technische Fehler

14. Prompt-Datei in V2.0

• Wenn die konfigurierte Prompt-Datei fehlt, darf V2.0 automatisch eine sinnvolle Standard-Prompt-Datei erzeugen.
• Diese Standard-Prompt-Datei ist deutschsprachig.
• Standardmäßig liegt sie im selben Ordner wie die .properties-Datei.

---

Explizit nicht Bestandteil von V2.0

Die folgenden Themen wurden bewusst angesprochen, aber aus V2.0 ausdrücklich ausgegrenzt:

• manueller Verarbeitungslauf aus der GUI
• Start eines echten Batch-Laufs per GUI
• Visualisierung der SQLite-Datenbank in der GUI
• Anzeige der Historie in einem eigenen GUI-Tab
• Kosten-Tracking
• exakte Token-Schätzung
• echte Kostenprognose
• echter Mini-KI-Testaufruf mit fachlicher Antwortauswertung
• EXE-Datei
• Installer
• zusätzliche Provider über Claude und OpenAI-kompatibel hinaus
• automatischer Fallback zwischen Providern
• mehrere benannte Profile pro Provider
• plattformübergreifender offizieller GUI-Support
• neues Konfigurationsformat
• Änderung der fachlichen Kernverarbeitung des PDF-Umbenenners
• Änderung der bestehenden Status-, Retry- oder Persistenz-Wahrheit
• neuer Parameter zur gesonderten Steuerung der für die KI berücksichtigten Seiten

---

Neue Meilensteine für V2.0

Grundsätze für alle V2.0-Meilensteine

• Jeder Meilenstein liefert einen in sich geschlossenen, buildbaren Entwicklungsstand.
• Jeder Meilenstein bleibt architekturtreu.
• Die Erweiterung darf den bestehenden headless Betrieb nicht still brechen.
• GUI und headless greifen auf dieselbe .properties-Konfigurationswelt zu.
• V2.0 führt keine neue Persistenz-Wahrheit und keine neue Fachlogik für die PDF-Benennung ein.
• Der Fokus liegt auf Benutzerkomfort, Konfigurationssicherheit und Diagnosefähigkeit.

---

M9 – GUI-Grundgerüst, neues Betriebsmodell und Packaging-Basis

Ziel

Die Anwendung erhält das technische Grundgerüst für eine JavaFX-GUI, ohne den bestehenden headless Batch-Betrieb zu verlieren.

Inhalt

• neues Modul pdf-umbenenner-adapter-in-gui einführen
• Startumschaltung zwischen GUI-Standardstart und --headless umsetzen
• neue CLI-Option --config <pfad> für GUI und headless einführen
• bestehendes headless Default-Verhalten ohne --config erhalten
• Bootstrap so erweitern, dass GUI und headless sauber verdrahtet werden
• JavaFX in das ausführbare JAR integrieren
• sicherstellen, dass GUI-Code den headless Pfad nicht unnötig früh initialisiert
• Windows als offizielles GUI-Zielsystem festlegen

Lauffähiger Stand

• ein gemeinsames ausführbares JAR kann GUI oder headless starten
• --headless bleibt abwärtskompatibel nutzbar
• --config ist für beide Startarten funktionsfähig
• GUI-Start schlägt bei fehlender GUI-Voraussetzung kontrolliert mit klarer Fehlermeldung fehl

Tests

• Starttests für GUI-Standardstart
• Starttests für --headless
• Starttests für --config
• Negativtests für ungültige oder fehlende Konfigurationspfade
• Smoke-Tests für Packaging und Artefakterzeugung

---

M10 – GUI-Konfigurationseditor, Dateihandling und Benutzerführung

Ziel

Die GUI kann bestehende .properties-Dateien komfortabel öffnen, neue anlegen, bearbeiten und speichern.

Inhalt

• Header mit aktuell genutztem Konfigurationspfad implementieren
• Aktionen Neu, Öffnen, Speichern, Speichern unter einführen
• Startzustand ohne geladene Konfiguration mit Willkommenstext umsetzen
• vollständige Standardvorlage mit sinnvollen Defaults für neue Konfigurationen bereitstellen
• alle aktuell bekannten Konfigurationswerte in der GUI abbilden
• Texteingabefelder plus Datei-/Ordnerdialoge für relevante Pfade umsetzen
• ungespeicherte Änderungen in Fenstertitel und Header markieren
• Dialoglogik für Speichern/Verwerfen/Abbrechen bei offenen Änderungen einführen
• Speicherlogik mit Normalisierung der .properties umsetzen

Lauffähiger Stand

• neue und bestehende Konfigurationen können komfortabel bearbeitet werden
• neue Konfigurationen können unter config/application.properties relativ zum Arbeitsverzeichnis vorgeschlagen gespeichert werden
• bestehende Konfigurationen können sicher geöffnet und überschrieben werden
• die GUI arbeitet vollständig auf der bestehenden .properties-Wahrheit

Tests

• Tests für Öffnen/Speichern/Speichern unter
• Tests für neue Konfiguration mit Standardwerten
• Tests für Dialogverhalten bei ungespeicherten Änderungen
• Tests für Normalisierung und korrekten Schreibstand der .properties

---

M11 – Provider-Bedienung, Modellabruf und automatische Validierung

Ziel

Die GUI bildet die bestehende Mehrprovider-Konfiguration komfortabel ab und validiert den Editorstand sofort und benutzerfreundlich.

Inhalt

• Provider-ComboBox für Claude und OpenAI-kompatibel umsetzen
• nur den aktuell gewählten Provider-Bereich sichtbar machen
• Providerwechsel ohne Datenverlust des jeweils anderen Provider-Blocks umsetzen
• automatischen Modellabruf bei Providerwechsel einführen
• explizite Aktion „Modelle neu laden“ an denselben Modellabruf anbinden
• Umschaltung zwischen Modell-ComboBox und manuellem Modell-Textfeld umsetzen
• automatische Validierung beim Öffnen und während der Bearbeitung einführen
• zentralen Meldungsbereich mit vier Stufen implementieren
• feldnahe rote Fehlermeldungen unter problematischen Eingabefeldern ergänzen
• wirtschaftliche Warnlogik für max.text.characters ergänzen
• max.pages als Plausibilitäts-/Performance-Hinweis behandeln

Lauffähiger Stand

• Provider können komfortabel gewählt werden
• Modelllisten können automatisch geladen und dargestellt werden
• die GUI erkennt Fehler, Warnungen und Hinweise unmittelbar
• unvollständige oder riskante Konfigurationen werden benutzerfreundlich sichtbar gemacht

Tests

• Tests für Providerwechsel und Provider-spezifische Felder
• Tests für Modellabruf mit Liste und ohne Liste
• Tests für automatische Validierung beim Öffnen
• Tests für Meldungsstufen, Warnschwellen und feldnahe Fehleranzeige

---

M12 – Technische Tests, Korrekturhilfen und Windows-/Netzlaufwerksfähigkeit

Ziel

Die GUI kann den aktuellen Editorstand technisch prüfen, alle Befunde gesammelt anzeigen und sinnvolle technische Korrekturen nach Benutzerbestätigung durchführen.

Inhalt

• Aktion Validieren umsetzen
• Aktion Technische Tests ausführen als Gesamttest umsetzen
• alle definierten Prüfpunkte vollständig und gesammelt ausführen
• Prüfungen gegen den aktuellen GUI-Zustand ohne implizites Speichern ausführen
• korrigierende technische Maßnahmen mit gesammeltem Bestätigungsdialog einführen
• automatische Standard-Prompt-Erzeugung bei fehlender Prompt-Datei einführen
• Netzlaufwerke über gemappte Laufwerksbuchstaben ausdrücklich unterstützen
• Pfadprüfungen für Quellordner, Zielordner, SQLite-Datei und Prompt-Datei vervollständigen

Lauffähiger Stand

• technische Gesamtprüfung liefert vollständige, verständliche Diagnose
• lokale Korrekturen können kontrolliert durchgeführt werden
• gemappte Laufwerke wie S:\ werden im Windows-Kontext korrekt akzeptiert
• fehlende Prompt-Datei kann automatisch sinnvoll erzeugt werden

Tests

• Tests für Gesamttest ohne Frühabbruch
• Tests für Korrektur-Bestätigungsdialog
• Tests für technische Korrekturen (Ordner/Datei/Prompt)
• Tests für gemappte Laufwerke und Windows-Pfadannahmen
• Tests für Validierung und Tests mit ungespeicherten Änderungen

---

M13 – V2.0-Abschluss, Dokumentation und Qualitätsnachweis

Ziel

Der V2.0-Ausbau wird dokumentiert, stabilisiert und als freigabefähiger Gesamtstand abgesichert.

Inhalt

• technische und betriebliche Dokumentation auf GUI + headless erweitern
• neue Startoptionen (--headless, --config) dokumentieren
• Verhalten bei fehlender Konfiguration, ungültigen Pfaden und GUI-Fehlern dokumentieren
• Build- und Packaging-Dokumentation für das gemeinsame JAR ergänzen
• Regressionstests für headless Abwärtskompatibilität ergänzen
• GUI-nahe Tests für zentrale Bedienpfade und Fehlersituationen ergänzen
• Qualitäts- und Freigabenachweis für den V2.0-Gesamtstand erstellen

Lauffähiger Stand

• GUI und headless sind gemeinsam dokumentiert und belastbar testbar
• bestehender Serverbetrieb bleibt kompatibel
• der V2.0-Stand ist freigabefähig und nachvollziehbar beschrieben

Tests

• Reactor-Build des Gesamtprojekts
• GUI-/Headless-Smoke-Tests
• Regressionstests für bisherigen Batch-Betrieb
• Dokumentations- und Konfigurationsbeispielprüfung

---

Ausbaustufen und Ausblick jenseits von V2.0

V2.1 – erster funktionaler Ausbau der GUI

Naheliegende Themen für V2.1:

• manueller Verarbeitungslauf aus der GUI
• Start eines echten Batch-Laufs aus der GUI
• ggf. erste laufbezogene Statusanzeige während der Ausführung
• erster separater Zusatz-Tab für weitergehende GUI-Funktionalität

V2.x – Komfort- und Transparenzausbau

Naheliegende Themen für spätere V2.x-Stufen:

• Visualisierung der SQLite-Datenbank in einem separaten Tab
• Anzeige von Historie und Verarbeitungsergebnissen
• Kosten-Tracking
• spätere, bewusst getrennte Erweiterung technischer Testfunktionen
• ggf. echter Mini-KI-Testaufruf
• ggf. feinere technische Steuerung der an die KI gegebenen Eingabemenge

V3 – größerer Funktionsausbau

Naheliegende Themen für V3:

• weitere Provider über Claude und OpenAI-kompatibel hinaus
• mehrere Profile pro Provider
• automatischer Fallback zwischen Providern
• größere Packaging-/Distributionsausbauten wie EXE oder Installer
• optional späterer plattformübergreifender offizieller GUI-Support

---

Kompakte Entscheidungsliste für V2.0

Zur schnellen Einordnung gilt für V2.0:

• GUI ist Standardstart
• --headless bleibt erhalten
• --config <pfad> gilt für GUI und headless
• ein gemeinsames ausführbares JAR
• JavaFX integriert
• kein Installer, keine EXE
• neues Modul pdf-umbenenner-adapter-in-gui
• .properties bleibt die einzige Konfigurationswahrheit
• GUI dient in V2.0 nur Konfiguration, Validierung und technischen Tests
• kein manueller Lauf in V2.0
• kein DB-/Historien-Tab in V2.0
• kein Kosten-Tracking in V2.0
• Windows ist offizielles GUI-Zielsystem
• gemappte Laufwerke sind zwingend zu unterstützen
• Provider bleiben in V2.0 auf Claude und OpenAI-kompatibel begrenzt
• exakt ein aktiver Provider bleibt erhalten

---

Ergebnis

Mit diesem Zuschnitt bleibt V2.0:

• deutlich nützlicher für den Benutzer,
• architekturtreu zum bestehenden System,
• abwärtskompatibel für den headless Serverbetrieb,
• und gleichzeitig bewusst begrenzt, damit spätere GUI-Ausbaustufen nicht schon in V2.0 vorweggenommen werden.