Meilensteine für V2.0 in der Pre-Version angelegt

docs/specs/meilensteine-v2_0.md

@@ -0,0 +1,628 @@
+# 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.