# 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 ` 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 ` 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 ` 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 ` 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 (`.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 ` 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 ` 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.