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>

docs/specs/fachliche-anforderungen.md

@@ -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

docs/specs/technik-und-architektur.md

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