628 lines
26 KiB
Markdown
628 lines
26 KiB
Markdown
# 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. |