Doku #34: Dokumentation auf V2.9-Stand aktualisieren
- CLAUDE.md: Aktiver Implementierungsstand auf V2.9 aktualisiert; neue Klassen (PdfPreviewPane, FileNameEditorPane, ManualFileRenameUseCase, FilesystemTargetFileRenameAdapter, GuiManualFileRenamePort) und neuer Port (TargetFileRenamePort) dokumentiert; PDFBox-Direktrendering, Vollbild-Start und automatisches Laden der letzten Konfiguration beschrieben - README.md: Versionshinweis auf V2.9 aktualisiert; neue Features genannt - docs/betrieb.md: Startverhalten (Vollbild, letzte Konfiguration automatisch laden) ergaenzt; GUI-Tab-Beschreibung um PDF-Vorschau und Dateiname-Editor erweitert - docs/gui-bedienanleitung.md: Abschnitt 2.1 fuer automatisches Laden aktualisiert; neuer Abschnitt 13b fuer PDF-Vorschau und editierbaren Dateiname-Bereich - docs/befundliste.md: V2.9-Fixes (#27, #28, #29, #33) dokumentiert - docs/specs/technik-und-architektur.md: TargetFileRenamePort in Port-Liste ergaenzt; PDFBox-Direktrendering im Adapter-Out-Abschnitt erwaehnt - docs/specs/fachliche-anforderungen.md: Nicht-Ziele praezisiert; neuer Abschnitt 14a fuer manuelle Dateiname-Korrektur nach Verarbeitungslauf Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
This commit is contained in:
@@ -138,7 +138,32 @@ V1.1 ist vollständig umgesetzt, dokumentiert, getestet und freigegeben.
|
||||
|
||||
Der Basisstand V2.0 (JavaFX-GUI als Standardstart, Konfigurationseditor, technische Tests) ist abgeschlossen.
|
||||
|
||||
Der aktive Entwicklungsstand erweitert den Tab „Verarbeitungslauf" um eine integrierte PDF-Vorschau und einen editierbaren Dateiname-Bereich. Die fachliche Kernverarbeitung des PDF-Umbenenners bleibt unverändert.
|
||||
**V2.9 ist abgeschlossen.** Der Tab „Verarbeitungslauf" wurde erweitert um:
|
||||
|
||||
- **Integrierte PDF-Vorschau** (`PdfPreviewPane`) mit Lazy-Rendering, In-Memory-Cache und
|
||||
Seitennavigation. Das Rendering erfolgt direkt über PDFBox
|
||||
(`PDFRenderer.renderImageWithDPI` + `SwingFXUtils.toFXImage`); eine externe PDFViewFX-Abhängigkeit
|
||||
wird nicht mehr verwendet.
|
||||
- **Editierbarer Dateiname-Bereich** (`FileNameEditorPane`) mit Live-Validierung, Dirty-State-Dialog
|
||||
bei Zeilen-/Tabwechsel, Schließen und Laufstart sowie atomarer Dateisystem- und DB-Transaktion
|
||||
inkl. Rollback und Fingerprint-basierter Konfliktauflösung.
|
||||
|
||||
Neue Architekturkomponenten in V2.9:
|
||||
|
||||
- Outbound-Port `TargetFileRenamePort` (`pdf-umbenenner-application`)
|
||||
- Application-Use-Case `ManualFileRenameUseCase` / `DefaultManualFileRenameUseCase`
|
||||
- Adapter-Out `FilesystemTargetFileRenameAdapter` (`pdf-umbenenner-adapter-out`)
|
||||
- GUI-interner Port `GuiManualFileRenamePort` (`pdf-umbenenner-adapter-in-gui`)
|
||||
|
||||
Weitere Verhaltensänderungen:
|
||||
|
||||
- Die GUI startet **maximiert** (Vollbild); `stage.setMaximized(true)` in `PdfUmbenennerGuiApplication`.
|
||||
- Beim Start wird die **zuletzt geladene Konfigurationsdatei** automatisch geladen
|
||||
(gespeichert in `java.util.prefs.Preferences` unter Schlüssel `lastConfigPath`,
|
||||
umgesetzt in `GuiConfigurationEditorWorkspace.autoLoadLastConfiguration()`).
|
||||
Existiert die Datei nicht mehr, startet die GUI ohne Fehlermeldung mit dem Willkommenstext.
|
||||
|
||||
Die fachliche Kernverarbeitung des PDF-Umbenenners bleibt unverändert.
|
||||
|
||||
## Statussemantik
|
||||
|
||||
|
||||
@@ -4,9 +4,10 @@ Ein lokal gestartetes Java-Programm zur KI-gestützten Umbenennung bereits OCR-v
|
||||
|
||||
Die Anwendung liest PDF-Dateien aus einem konfigurierbaren Quellordner, extrahiert den Text, ermittelt daraus per KI einen normierten Dateinamen und legt **eine Kopie** im Zielordner ab. Die Quelldateien bleiben unverändert.
|
||||
|
||||
> **V2.0+:** Die Anwendung enthält ab V2.0 eine lokale JavaFX-Desktop-GUI als Standardstart.
|
||||
> Die GUI dient der Konfiguration, Validierung und technischen Diagnose.
|
||||
> Der aktuelle Ausbau erweitert den Tab „Verarbeitungslauf" um eine integrierte PDF-Vorschau und einen editierbaren Dateiname-Bereich.
|
||||
> **V2.9:** Die Anwendung enthält eine lokale JavaFX-Desktop-GUI als Standardstart.
|
||||
> Die GUI dient der Konfiguration, Validierung, technischen Diagnose und der Ausführung von Verarbeitungsläufen.
|
||||
> Der Tab „Verarbeitungslauf" enthält eine integrierte PDF-Vorschau und einen editierbaren Dateiname-Bereich.
|
||||
> Die GUI startet maximiert und lädt beim Start automatisch die zuletzt verwendete Konfigurationsdatei.
|
||||
> Der headless Batch-Betrieb bleibt über `--headless` vollständig erhalten.
|
||||
> Details zum Betrieb: [`docs/betrieb.md`](docs/betrieb.md)
|
||||
|
||||
|
||||
@@ -315,3 +315,36 @@ ausdrücklich für spätere Ausbaustufen vorgesehen:
|
||||
**Build:** ERFOLGREICH · 1.398 Tests · 0 Failures · 0 Errors · Laufzeit 01:18 min
|
||||
**Alle 20 Spezifikations-Prüfpunkte:** erfüllt
|
||||
**Dokumentation:** vollständig und konsistent
|
||||
|
||||
---
|
||||
|
||||
# V2.9-Fixes (Stand 2026-04-24)
|
||||
|
||||
Die folgenden Issues wurden nach dem V2.0-Abschluss behoben und sind im aktuellen Stand integriert.
|
||||
|
||||
| Issue | Titel | Status |
|
||||
|---|---|---|
|
||||
| #27 | Mausrad-Seitenwechsel und zuverlässiger Seitenanfang in PDF-Vorschau | **behoben** |
|
||||
| #28 | Anwendung standardmäßig im Vollbild starten | **behoben** |
|
||||
| #29 | Eigenes PDF-Rendering mit PDFBox statt PDFViewFX | **behoben** |
|
||||
| #33 | Letzte Konfigurationsdatei beim Neustart automatisch laden | **behoben** |
|
||||
|
||||
### Beschreibung der Fixes
|
||||
|
||||
**#27 / #29 – PDF-Vorschau-Stabilität und PDFBox-Migration:**
|
||||
Mehrere aufeinanderfolgende Fixes stabilisierten die PDF-Vorschau. Zunächst wurden
|
||||
Scroll-Schutz und zuverlässiger Seitenanfang per ImageView-Listener verbessert.
|
||||
Im letzten Schritt (#29) wurde die externe PDFViewFX-Abhängigkeit vollständig
|
||||
durch direktes Rendering via `PDFRenderer.renderImageWithDPI` (Apache PDFBox, 120 DPI)
|
||||
ersetzt. Lazy Rendering mit In-Memory-Cache und das „latest preview request wins"-Prinzip
|
||||
blieben erhalten.
|
||||
|
||||
**#28 – Vollbild-Start:**
|
||||
`stage.setMaximized(true)` in `PdfUmbenennerGuiApplication.start()` sorgt dafür, dass
|
||||
das Fenster beim Start automatisch maximiert wird.
|
||||
|
||||
**#33 – Letzte Konfiguration automatisch laden:**
|
||||
`GuiConfigurationEditorWorkspace` speichert den Pfad einer erfolgreich geladenen
|
||||
Konfigurationsdatei in `java.util.prefs.Preferences` (Schlüssel `lastConfigPath`).
|
||||
Beim nächsten Start wird diese Datei automatisch geladen, sofern sie noch existiert.
|
||||
Fehlt die Datei, startet die GUI ohne Fehlermeldung mit dem Willkommenstext.
|
||||
|
||||
+14
-6
@@ -54,6 +54,13 @@ Windows Server-Betrieb geeignet.
|
||||
Gemappte Netzlaufwerke wie `S:\` oder `H:\` werden ausdrücklich unterstützt. Eine Ablehnung
|
||||
solcher Pfade allein wegen eines dahinterliegenden UNC-Pfads ist unzulässig.
|
||||
|
||||
### Startverhalten der GUI
|
||||
|
||||
Die GUI startet **maximiert** (Vollbild). Beim Start wird die zuletzt geladene
|
||||
Konfigurationsdatei automatisch geladen. Der Pfad wird in den Windows-Benutzereinstellungen
|
||||
gespeichert (`java.util.prefs.Preferences`). Existiert die Datei beim nächsten Start nicht
|
||||
mehr, startet die GUI ohne Fehlermeldung mit dem Willkommenstext.
|
||||
|
||||
### Umfang der GUI
|
||||
|
||||
Die GUI enthält zwei Tabs:
|
||||
@@ -62,11 +69,12 @@ Die GUI enthält zwei Tabs:
|
||||
die `.properties`-Datei (Erreichbarkeit des Providers, Pfade, SQLite-Datei,
|
||||
Prompt-Datei).
|
||||
- **Tab „Verarbeitungslauf"** – Start eines Batch-Laufs aus der GUI mit
|
||||
Live-Fortschritt, Ergebnisliste und KI-Begründung je Dokument. Der Lauf verwendet den
|
||||
zuletzt gespeicherten Stand der `.properties`-Datei; ungespeicherte Änderungen im
|
||||
Editor fließen nicht in den Lauf ein. Ein **Soft-Stop** über den Abbrechen-Knopf
|
||||
beendet den Lauf nach Abschluss der gerade bearbeiteten Datei. Während eines
|
||||
laufenden Batches ist Tab 1 gesperrt; ein Hinweis weist darauf hin.
|
||||
Live-Fortschritt, Ergebnisliste und KI-Begründung je Dokument. Pro Zeile ist eine
|
||||
**integrierte PDF-Vorschau** der Quelldatei sowie ein **editierbarer Dateiname-Bereich**
|
||||
verfügbar. Der Lauf verwendet den zuletzt gespeicherten Stand der `.properties`-Datei;
|
||||
ungespeicherte Änderungen im Editor fließen nicht in den Lauf ein. Ein **Soft-Stop**
|
||||
über den Abbrechen-Knopf beendet den Lauf nach Abschluss der gerade bearbeiteten Datei.
|
||||
Während eines laufenden Batches ist Tab 1 gesperrt; ein Hinweis weist darauf hin.
|
||||
|
||||
Der headless Betrieb über den Windows Task Scheduler bleibt unverändert bestehen und
|
||||
kann weiterhin für automatisierte Läufe genutzt werden. Pro Anwendungsinstanz ist genau
|
||||
@@ -597,7 +605,7 @@ Die Bedienung der GUI ist in [`gui-bedienanleitung.md`](gui-bedienanleitung.md)
|
||||
- Nur OCR-verarbeitete, durchsuchbare PDF-Dateien werden verarbeitet
|
||||
- Keine eingebaute OCR-Funktion
|
||||
- Kein Web-UI, keine REST-API
|
||||
- Die GUI (V2.0) dient der Konfiguration, Validierung und technischen Diagnose – **kein** manueller Verarbeitungslauf aus der GUI
|
||||
- Die GUI ermöglicht Konfiguration, Validierung, technische Diagnose und die Ausführung von Verarbeitungsläufen mit integrierter PDF-Vorschau und editierbarem Dateiname
|
||||
- Kein interner Scheduler – der Batch-Betrieb wird extern angestoßen (z. B. Windows Task Scheduler, `--headless`)
|
||||
- Quelldateien werden nie überschrieben, verschoben oder gelöscht
|
||||
- Die Identifikation erfolgt über SHA-256-Fingerprint des Dateiinhalts, nicht über Dateinamen
|
||||
|
||||
@@ -27,12 +27,17 @@ PDF-Dateien automatisiert zu verarbeiten.
|
||||
|
||||
### 2.1 GUI-Standardstart
|
||||
|
||||
Wird die Anwendung ohne CLI-Argumente gestartet, öffnet sich die JavaFX-Desktop-GUI.
|
||||
Es wird keine Konfigurationsdatei automatisch geladen.
|
||||
Wird die Anwendung ohne CLI-Argumente gestartet, öffnet sich die JavaFX-Desktop-GUI
|
||||
**maximiert** (Vollbild).
|
||||
|
||||
Stattdessen zeigt die GUI einen deutschen Willkommenstext mit dem Hinweis, über
|
||||
„Neu" eine Standardvorlage zu erzeugen oder über „Öffnen" eine bestehende
|
||||
`.properties`-Datei zu laden.
|
||||
Wurde bei einem früheren Start eine Konfigurationsdatei geladen, wird diese automatisch
|
||||
erneut geladen. Der zuletzt verwendete Pfad wird systemseitig gespeichert
|
||||
(`java.util.prefs.Preferences`). Existiert die Datei nicht mehr, startet die GUI ohne
|
||||
Fehlermeldung mit dem Willkommenstext — es erscheint kein Dialog und kein Fehler.
|
||||
|
||||
Beim allerersten Start (oder wenn noch keine Datei geladen wurde) zeigt die GUI einen
|
||||
deutschen Willkommenstext mit dem Hinweis, über „Neu" eine Standardvorlage zu erzeugen
|
||||
oder über „Öffnen" eine bestehende `.properties`-Datei zu laden.
|
||||
|
||||
### 2.2 Start mit `--config <pfad>` (gültige Datei)
|
||||
|
||||
@@ -578,6 +583,52 @@ Behebung eines externen Fehlers oder planmäßig im nächsten regulären Lauf.
|
||||
|
||||
---
|
||||
|
||||
## 13b. PDF-Vorschau und editierbarer Dateiname im Verarbeitungslauf-Tab
|
||||
|
||||
Nach Abschluss eines Verarbeitungslaufs (oder während laufender Verarbeitung) zeigt
|
||||
ein Klick auf eine Zeile in der Ergebnisliste ein Detail-Panel auf der rechten Seite.
|
||||
Das Panel enthält drei Bereiche:
|
||||
|
||||
### PDF-Vorschau
|
||||
|
||||
- Zeigt die **Quelldatei** der gewählten Zeile als Vorschau an.
|
||||
- **Lazy Rendering:** Seite 1 wird sofort geladen; weitere Seiten werden erst bei
|
||||
Bedarf gerendert.
|
||||
- **In-Memory-Cache:** Bereits gerenderte Seiten werden pro Zeilenselektion
|
||||
zwischengespeichert. Bei einem Zeilenwechsel wird der Cache der vorherigen Auswahl
|
||||
verworfen.
|
||||
- **Seitennavigation:** Über die Schaltflächen **„◀"** und **„▶"** (oder das Mausrad)
|
||||
kann seitenweise geblättert werden. Die aktuelle Seitenzahl und Gesamtseitenzahl
|
||||
werden angezeigt.
|
||||
- **Fit-to-view:** Die Seite wird automatisch an die verfügbare Fläche angepasst
|
||||
(preserveRatio=true). Keine Scrollbalken, keine manuelle Zoom-Einstellung.
|
||||
- Das Rendering erfolgt direkt über Apache PDFBox bei 120 DPI.
|
||||
|
||||
### KI-Begründung
|
||||
|
||||
Der mittlere Bereich zeigt das KI-Reasoning des ausgewählten Eintrags. Liegt kein
|
||||
Reasoning vor (z. B. bei Übersprungen-Einträgen), erscheint der Hinweis
|
||||
„Für diesen Eintrag liegt kein KI-Reasoning vor.".
|
||||
|
||||
### Editierbarer Dateiname
|
||||
|
||||
- Unterhalb des Reasoning-Bereichs befindet sich ein **editierbares Textfeld** mit
|
||||
dem aktuellen Dateinamen des Eintrags.
|
||||
- Das Feld kann direkt bearbeitet werden. Die Eingabe wird **live validiert**
|
||||
(Formatprüfung `YYYY-MM-DD - Titel.pdf`, Titelzeichen, Länge).
|
||||
- Fehlerhafte Eingaben werden direkt unter dem Feld als rote Meldung angezeigt.
|
||||
- **Speichern:** Der Button **„Übernehmen"** führt die Umbenennung durch – atomare
|
||||
Dateisystem- und DB-Transaktion inkl. automatischer Rollback bei Fehler.
|
||||
Namenskonflikte im Zielordner werden über ein Dubletten-Suffix aufgelöst.
|
||||
- **Zurücksetzen:** Der Button **„Zurücksetzen"** verwirft die Änderungen und stellt
|
||||
den zuletzt persistierten Dateinamen wieder her.
|
||||
- Wird die Zeile gewechselt oder der Tab verlassen, während ungespeicherte Änderungen
|
||||
vorliegen, erscheint ein Schutzdialog mit den Optionen **„Speichern"**, **„Verwerfen"**
|
||||
und **„Abbrechen"**.
|
||||
- Während eines laufenden Verarbeitungslaufs ist das Dateiname-Feld **gesperrt**.
|
||||
|
||||
---
|
||||
|
||||
## 14. Bekannte Einschränkungen V2.x
|
||||
|
||||
| Einschränkung | Erläuterung |
|
||||
|
||||
@@ -201,12 +201,31 @@ Ein Ergebnis ist korrekt, wenn:
|
||||
|
||||
## 14. Nicht-Ziele
|
||||
|
||||
- keine manuelle Nachbearbeitung
|
||||
- keine Benutzerinteraktion
|
||||
- kein manueller Verarbeitungslauf durch den Benutzer (die KI-Verarbeitungskette
|
||||
läuft ausschließlich automatisiert)
|
||||
- keine Inhaltsänderung von Dokumenten
|
||||
|
||||
---
|
||||
|
||||
## 14a. Manuelle Korrektur des Dateinamens nach automatischer Verarbeitung
|
||||
|
||||
Nach Abschluss eines automatisierten Verarbeitungslaufs kann der Benutzer den von der
|
||||
KI vorgeschlagenen Dateinamen der Zieldatei **manuell korrigieren**.
|
||||
|
||||
Verbindliche Regeln:
|
||||
|
||||
- Die Korrektur ist **optional** und ersetzt keinen erneuten KI-Aufruf.
|
||||
- Der geänderte Dateiname muss denselben Formatregeln genügen wie ein automatisch
|
||||
erzeugter Name (`YYYY-MM-DD - Titel.pdf`, zulässige Sonderzeichen, Titellänge).
|
||||
- Namenskonflikte im Zielordner werden durch Dubletten-Suffix aufgelöst
|
||||
(analog zur automatischen Verarbeitung).
|
||||
- Die Umbenennung ist **atomar**: entweder Dateisystem und Datenbank werden
|
||||
konsistent aktualisiert, oder die Aktion wird vollständig zurückgerollt.
|
||||
- Die Quelldatei bleibt unverändert.
|
||||
- Ein manuell korrigierter Dateiname wird in der Versuchshistorie persistiert.
|
||||
|
||||
---
|
||||
|
||||
## 15. Qualitätsanforderungen
|
||||
|
||||
- deterministisches Verhalten
|
||||
|
||||
@@ -133,8 +133,8 @@ Beispiel:
|
||||
|
||||
#### Adapter Out
|
||||
Enthält technische Implementierungen der Outbound-Ports, insbesondere:
|
||||
- Dateisystem
|
||||
- PDFBox
|
||||
- Dateisystem (inkl. `FilesystemTargetFileRenameAdapter` für atomare Zieldatei-Umbenennung)
|
||||
- PDFBox (Textauslese sowie direktes Seitenrendering für die GUI-Vorschau via `PDFRenderer.renderImageWithDPI`)
|
||||
- SQLite
|
||||
- KI-HTTP-Clients (eine Implementierung je unterstütztem Provider, siehe Abschnitt 11)
|
||||
- Properties-/Umgebungs-Konfiguration
|
||||
@@ -204,12 +204,19 @@ Verbindlich zweckmäßige Outbound-Ports:
|
||||
- `FingerprintPort`
|
||||
- `ProcessedDocumentRepository`
|
||||
- `AiNamingPort`
|
||||
- `TargetFileRenamePort`
|
||||
- `ConfigurationPort`
|
||||
- `RunLockPort`
|
||||
- `ClockPort`
|
||||
|
||||
Der `AiNamingPort` bleibt **provider-neutral**. Er kennt weder OpenAI- noch Anthropic-spezifische Typen, Header, URLs oder Antwortformate. Provider-spezifische Details (Endpunkt, Authentifizierung, Request-/Response-Format) leben ausschließlich in den jeweiligen Adapter-Out-Implementierungen.
|
||||
|
||||
Der `TargetFileRenamePort` kapselt die atomare Umbenennung einer bereits kopierten Zieldatei.
|
||||
Er wird vom Use Case `ManualFileRenameUseCase` genutzt und ist durch
|
||||
`FilesystemTargetFileRenameAdapter` implementiert. Der Port-Vertrag enthält keine
|
||||
`Path`- oder NIO-Typen in öffentlichen Signaturen; er arbeitet ausschließlich mit
|
||||
Domain-Typen und String-basierten Dateinamen.
|
||||
|
||||
### 6.3 Logging
|
||||
Logging ist **kein fachlicher Port**. Logging ist technische Infrastruktur.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user