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