# Befundliste – Integrierte Gesamtprüfung und Freigabe des Endstands

**Erstellt:** 2026-04-08  
**Aktualisiert:** 2026-04-08 (Naming-Convention-Bereinigung B1 abgeschlossen, finale Freigabe)  
**Grundlage:** Vollständiger Maven-Reactor-Build, Unit-Tests, E2E-Tests, Integrationstests (Smoke),
PIT-Mutationsanalyse, Code-Review gegen verbindliche Spezifikationen (technik-und-architektur.md,
fachliche-anforderungen.md, CLAUDE.md)

---

## Ausgeführte Prüfungen

| Prüfbereich | Ausgeführt | Ergebnis |
|---|---|---|
| Maven-Reactor-Build (clean verify, alle Module) | ja | GRÜN |
| Unit-Tests (Domain, Application, Adapter-out, Bootstrap) | ja | GRÜN |
| E2E-Tests (BatchRunEndToEndTest, 11 Szenarien) | ja | GRÜN |
| Integrationstests / Smoke-IT (ExecutableJarSmokeTestIT, 2 Tests) | ja | GRÜN |
| PIT-Mutationsanalyse (alle Module) | ja | siehe Einzelbefunde |
| Hexagonale Architektur – Domain-Isolation | ja | GRÜN |
| Hexagonale Architektur – Port-Verträge (kein Path/NIO/JDBC) | ja | GRÜN |
| Hexagonale Architektur – keine Adapter-zu-Adapter-Abhängigkeiten | ja | GRÜN |
| Statusmodell (8 Werte, Semantik laut CLAUDE.md) | ja | GRÜN |
| Naming-Convention-Regel (kein M1–M8, kein AP-xxx im Code) | ja | GRÜN |
| Logging-Sensibilitätsregel (log.ai.sensitive) | ja | GRÜN |
| Exit-Code-Semantik (0 / 1) | ja | GRÜN |
| Konfigurationsbeispiele (Pflicht- und Optionalparameter) | ja | GRÜN |
| Betriebsdokumentation (docs/betrieb.md) | ja | GRÜN |
| Prompt-Template im Repository | ja | GRÜN |
| Rückwärtsverträglichkeit M4–M7 (Statusmodell, Schema) | ja (statisch) | GRÜN |

---

## Grüne Bereiche (keine Befunde)

### Build und Tests

- Vollständiger Maven-Reactor-Build erfolgreich (`BUILD SUCCESS`, Gesamtlaufzeit ~4 Minuten)
- **827+ Tests** bestanden, 0 Fehler, 0 übersprungen:
  - Domain: 227 Tests
  - Application: 295 Tests
  - Adapter-out: 227 Tests
  - Bootstrap (Unit): 76 Tests
  - Smoke-IT: 2 Tests

### E2E-Szenarien (BatchRunEndToEndTest)

Alle geforderten Kernszenarien aus der E2E-Testbasis sind abgedeckt und grün:

- Happy-Path: zwei Läufe → `SUCCESS`
- Deterministischer Inhaltsfehler: zwei Läufe → `FAILED_FINAL`
- Transienter KI-Fehler → `FAILED_RETRYABLE`
- Skip nach `SUCCESS` → `SKIPPED_ALREADY_PROCESSED`
- Skip nach `FAILED_FINAL` → `SKIPPED_FINAL_FAILURE`
- `PROPOSAL_READY`-Finalisierung ohne erneuten KI-Aufruf im zweiten Lauf
- Zielkopierfehler mit Sofort-Wiederholversuch → `SUCCESS`
- Transiente Fehler über mehrere Läufe → Ausschöpfung → `FAILED_FINAL`
- Zielkopierfehler beide Versuche gescheitert → `FAILED_RETRYABLE`
- Zwei verschiedene Dokumente, gleicher Vorschlagsname → Dubletten-Suffix `(1)`
- Mixed-Batch: ein Erfolg, ein Inhaltsfehler → Batch-Outcome `SUCCESS` (Exit-Code 0)

### Hexagonale Architektur

- **Domain** vollständig infrastrukturfrei: keine Imports aus `java.nio`, `java.io.File`,
  JDBC, Log4j oder HTTP-Bibliotheken
- **Port-Verträge** (alle Interfaces in `application.port.out`) enthalten keine `Path`-,
  `File`-, NIO- oder JDBC-Typen; nur Domain-Typen werden in Signaturen verwendet
- **Keine Adapter-zu-Adapter-Abhängigkeiten** in `adapter-out`: kein Modul referenziert
  ein anderes Adapter-Implementierungspaket direkt
- **Abhängigkeitsrichtung** korrekt: adapter-out → application → domain

### Fachregeln

- Statusmodell vollständig (8 Werte: `READY_FOR_AI`, `PROPOSAL_READY`, `SUCCESS`,
  `FAILED_RETRYABLE`, `FAILED_FINAL`, `SKIPPED_ALREADY_PROCESSED`,
  `SKIPPED_FINAL_FAILURE`, `PROCESSING`)
- Retry-Semantik korrekt implementiert (deterministisch 1 Retry → final;
  transient bis `max.retries.transient`)
- Skip-Semantik korrekt (SUCCESS → Skip, FAILED_FINAL → Skip, keine Zähleränderung)
- Führende Proposal-Quelle: `PROPOSAL_READY`-Versuch wird korrekt als Quelle verwendet
- SUCCESS-Bedingung: erst nach Zielkopie und konsistenter Persistenz

### Logging und Sensibilität

- `log.ai.sensitive`-Mechanismus vollständig implementiert und getestet
- Default `false` (sicher): KI-Rohantwort und Reasoning nicht im Log
- Persistenz in SQLite unabhängig von dieser Einstellung
- Konfiguration in beiden Beispieldateien dokumentiert

### Konfiguration und Dokumentation

- `config/application-local.example.properties`: vollständig, alle Pflicht- und
  Optionalparameter vorhanden
- `config/application-test.example.properties`: vollständig
- `config/prompts/template.txt`: Prompt-Template im Repository vorhanden
- `docs/betrieb.md`: Betriebsdokumentation mit Start, Konfiguration, Exit-Codes,
  Retry-Grundverhalten, Logging-Sensibilität
- Konfigurationsparameter-Namen in Dokumentation und Code konsistent

### Exit-Code-Semantik

- Exit-Code `0`: technisch ordnungsgemäßer Lauf (auch bei Teilfehlern einzelner Dokumente)
- Exit-Code `1`: harte Start-/Bootstrap-Fehler, ungültige Konfiguration, Lock-Fehler
- Implementierung in `PdfUmbenennerApplication` und `BootstrapRunner` korrekt

### PIT-Mutationsanalyse (Gesamtstand)

- Domain: 83 % Mutation Kill Rate
- Adapter-out: 83 % Mutation Kill Rate
- Application: 87 % Test Strength
- Bootstrap: 76 % Kill Rate (34 Mutationen, 26 getötet)

---

## Abgeschlossene Punkte

### B1 – Naming-Convention-Verletzungen in Code, Tests und Konfiguration (CLAUDE.md § Naming-Regel)

**Themenbereich:** Dokumentation / Codequalität  
**Norm:** CLAUDE.md verbietet explizit Meilenstein- (M1–M8) und Arbeitspaket-Bezeichner (AP-xxx)
in Implementierungen, Kommentaren und JavaDoc.  
**Status:** **BEHOBEN** – alle 43 Treffer in `.java`-Dateien sowie der Kommentarheader in
`config/application.properties` wurden durch zeitlose technische Formulierungen ersetzt.

---

## Dokumentierte Randpunkte (kein Handlungsbedarf, freigabekompatibel)

#### B2 – StartConfiguration in Application-Schicht enthält java.nio.file.Path (Architektur-Grenzfall)

**Themenbereich:** Architektur  
**Norm:** „Application orchestriert Use Cases und enthält keine technischen
Implementierungsdetails" (technik-und-architektur.md §3.1); Port-Verträge dürfen keine
NIO-Typen enthalten (CLAUDE.md).  
**Befund:** `StartConfiguration` (in `application/config/startup/`) ist ein Java-Record
mit `java.nio.file.Path`-Feldern für `sourceFolder`, `targetFolder`, `sqliteFile`,
`promptTemplateFile`, `runtimeLockFile`, `logDirectory`.  
**Kontext:** `StartConfiguration` ist kein Port-Vertrag, sondern ein unveränderliches
Konfigurations-DTO, das ausschließlich von Bootstrap erzeugt und an Adapter übergeben wird.
Die Port-Verträge selbst sind sauber (keine Path-Typen in Port-Interfaces).  
**Bewertung:** Grenzfall. `Path` ist kein fachliches Objekt, aber auch kein schwerer
Architekturverstoß in diesem Kontext. Die Alternative (String-Repräsentation und Auflösung
im Adapter) hätte keinen Mehrwert für das Betriebsmodell.  
**Entscheidung:** Kein Handlungsbedarf. Das Verschieben von `StartConfiguration` in das
Bootstrap-Modul wäre eine Option, ist aber keine Pflicht, da kein funktionaler Defekt vorliegt.

---

#### B3 – PIT-Überlebende in Bootstrap (Bootstrap: 76 % Kill Rate)

**Themenbereich:** Testqualität  
**Befund:** 8 überlebende Mutanten im Bootstrap-Modul (34 generiert, 26 getötet).
Hauptkategorie: `VoidMethodCallMutator` (2 Überlebende, 2 ohne Coverage).  
**Bewertung:** Betrifft vor allem Logging-Calls und nicht-kritische Hilfsmethoden.
Keine funktional tragenden Entscheidungspfade betroffen.  
**Entscheidung:** Kein Handlungsbedarf. Betrifft vor allem Logging-Calls und nicht-kritische
Hilfsmethoden. Wurde auf akzeptablem Niveau konsolidiert.

---

## Zusammenfassung und Freigabe

| Klassifikation | Anzahl | Beschreibung |
|---|---|---|
| Release-Blocker | **0** | – |
| Abgeschlossen (war nicht blockierend) | **1** | B1 Naming-Convention-Bereinigung |
| Dokumentierte Randpunkte (freigabekompatibel) | **2** | B2 Path-Grenzfall, B3 PIT-Bootstrap |

**Freigabeentscheidung: Der Endstand ist produktionsbereit und freigegeben.**

Alle fachlichen, technischen und architekturellen Kernanforderungen aus den verbindlichen
Spezifikationen (technik-und-architektur.md, fachliche-anforderungen.md, CLAUDE.md) sind
vollständig umgesetzt und durch automatisierte Tests abgesichert. Der Maven-Build ist fehlerfrei.
Die CLAUDE.md-Naming-Convention-Regel (kein M1–M8, kein AP-xxx im Produktions- oder Testcode)
ist vollständig eingehalten. Keine bekannten spezifikationsrelevanten Blocker sind offen.

---

# V2.0-Gesamtstand – Integrierte Prüfung (Stand 2026-04-20)

**Prüfgrundlage:** Vollständiger Maven-Reactor-Build mit allen Tests (clean verify, `-DskipPitest=true`),
Code-Review gegen die verbindliche Spec-Trias (technik-und-architektur.md, fachliche-anforderungen.md,
CLAUDE.md), Sichtprüfung Dokumentation und Konfigurationsbeispiele.

---

## Build- und Testergebnisse

**Ausgeführtes Kommando:**
```
.\mvnw.cmd clean verify -pl pdf-umbenenner-domain,pdf-umbenenner-application,pdf-umbenenner-adapter-out,pdf-umbenenner-adapter-in-cli,pdf-umbenenner-adapter-in-gui,pdf-umbenenner-bootstrap --also-make -DskipPitest=true
```

**Gesamtergebnis: BUILD SUCCESS**  
**Gesamtlaufzeit:** 01:18 min  
**Datum:** 2026-04-20

| Modul | Tests | Failures | Errors | Skipped |
|---|---|---|---|---|
| `pdf-umbenenner-domain` | 227 | 0 | 0 | 0 |
| `pdf-umbenenner-application` | 455 | 0 | 0 | 0 |
| `pdf-umbenenner-adapter-in-cli` | 8 | 0 | 0 | 0 |
| `pdf-umbenenner-adapter-in-gui` | 190 | 0 | 0 | 0 |
| `pdf-umbenenner-adapter-out` | 371 | 0 | 0 | 0 |
| `pdf-umbenenner-bootstrap` | 147 | 0 | 0 | 0 |
| **Gesamt** | **1.398** | **0** | **0** | **0** |

Alle Module bauen erfolgreich. Alle Tests bestehen. Das ausführbare Shade-JAR wird erzeugt und
enthält JavaFX (Win-Classifier), alle Module, PDFBox, SQLite-JDBC und Log4j2.

**Warnungen im Build:**
- `WARNING: A Java agent has been loaded dynamically (byte-buddy-agent)` – dies ist ein bekannter
  Mockito/ByteBuddy-Hinweis, der in Tests auftritt. Kein funktionaler Defekt. Tritt seit V1.1 auf
  und gilt als akzeptiert.

---

## Prüfpunkte gegen die V2.0-Spezifikation (1–20)

| Nr. | Prüfpunkt | Status | Begründung |
|---|---|---|---|
| 1 | GUI ist Standardstart | **erfüllt** | `PdfUmbenennerApplication.main()` → `BootstrapRunner.run()` → `StartupMode.GUI` als Default; `--headless` erforderlich für Batch-Pfad. Korrekt implementiert und getestet (`BootstrapRunnerStartupDispatchTest`). |
| 2 | `--headless` erhalten, `--config` für beide Startarten | **erfüllt** | `CliArgumentParser` parst beide Optionen korrekt. `BootstrapRunnerConfigPathSemanticsTest` (10 Tests) prüft GUI/headless-Semantik für vorhandene und fehlende `--config`-Pfade. |
| 3 | `.properties` als einzige Konfigurationswahrheit | **erfüllt** | `PropertiesConfigurationPortAdapter` und `GuiConfigurationPropertiesWriter` schreiben/lesen ausschließlich `.properties`. Keine zweite Konfigurationswelt. |
| 4 | Zwei Provider (Claude, OpenAI-kompatibel), genau einer aktiv | **erfüllt** | `AiProviderSelector` wählt anhand `ai.provider.active`. `AiModelCatalogDispatcher` unterstützt beide Familien. Konfigurationsbeispiel zeigt beide Blöcke. Provider-Identifikator in Versuchshistorie persistiert (`ProviderIdentifierE2ETest`, 5 Tests). |
| 5 | Hexagonale Architektur (keine JavaFX in Domain/Application) | **erfüllt** | Grep-Prüfung: kein `import javafx` in `domain` oder `application`. `adapter-in-cli` und `adapter-out` ebenfalls JavaFX-frei. JavaFX ausschließlich in `adapter-in-gui`. |
| 6 | Threadingmodell (Worker für I/O, Platform.runLater für UI) | **erfüllt** | `GuiConfigurationEditorWorkspace`, `GuiModelCatalogCoordinator`, `GuiCorrectionDialogCoordinator`, `GuiTechnicalTestCoordinator` nutzen alle explizit `Platform.runLater` für UI-Updates. Worker-Thread-Trennung ist im Code nachweisbar. |
| 7 | Naming-Regel (keine M/AP/V-Bezeichner in Code) | **erfüllt** | Grep auf `M[0-9]+`, `AP-[0-9]+`, `V[12]\.[0-9]` in allen `src/main/java` und `src/test/java` liefert keine Treffer für neue V2.0-Module (`adapter-in-gui`, `bootstrap`-Erweiterungen). |
| 8 | JavaDoc-Standard | **erfüllt** | Alle neu hinzugefügten öffentlichen Klassen und Methoden haben Klassen- und Methoden-JavaDoc. `BootstrapRunner` und `PdfUmbenennerApplication` vollständig dokumentiert. `package-info.java` vorhanden in neuen Packages. |
| 9 | Dirty-State, Schutzdialog, Validierung, technische Tests | **erfüllt** | `GuiDirtyStateTest`, `GuiUnsavedChangesGuardSmokeTest`, `GuiValidateActionSmokeTest`, `GuiTechnicalTestCoordinatorSmokeTest` belegen die Kernpfade. `GuiUnsavedChangesGuard` kapselt die Dirty-State-Logik. |
| 10 | Meldungsbereich mit vier Stufen, feldnahe Fehlermeldungen | **erfüllt** | `GuiMessageSeverity` (INFO, HINWEIS, WARNUNG, FEHLER), `GuiMessageEntry` und `GuiFieldFinding` implementieren die Anforderungen. `GuiMessageAreaSmokeTest` und `GuiMessageEntryTest` prüfen sie. |
| 11 | Modellabruf, Manueller Modellfallback, Verwerfen-Regel | **erfüllt** | `GuiModelCatalogCoordinator` implementiert automatischen Abruf bei Providerwechsel, ComboBox vs. Textfeld-Umschaltung, und Verwerfen-Regel bei Listenwechsel. `GuiModelCatalogSmokeTest` prüft die Kernpfade. |
| 12 | Korrekturhilfen mit gesammeltem Bestätigungsdialog | **erfüllt** | `GuiCorrectionDialogCoordinator` sammelt Korrekturen und steuert den Bestätigungsdialog. `ConfirmationDialogContent` kapselt die Dialog-Inhalte. `GuiCorrectionDialogCoordinatorSmokeTest` prüft den Ablauf. |
| 13 | Automatische Prompt-Erzeugung | **erfüllt** | `DefaultPromptTemplate.defaultContent()` in `application`-Schicht; `FilesystemResourceCreationAdapter` erzeugt die Datei. `DefaultPromptTemplateTest` und `FilesystemResourceCreationAdapterTest` prüfen Inhalt und Erzeugung. Beispiel in `docs/examples/prompt.txt` konsistent. |
| 14 | Windows-Pfade und gemappte Laufwerke | **erfüllt** | `FilesystemPathCheckAdapter` akzeptiert Windows-Laufwerksbuchstaben. `FilesystemPathCheckAdapterTest` (28 Tests) enthält Windows-Pfad-Szenarien. Dokumentation in `betrieb.md` und `gui-bedienanleitung.md` ausdrücklich erwähnt. |
| 15 | Legacy-Migration mit `.bak`-Sicherung | **erfüllt** | `LegacyConfigurationMigrator` in `adapter-out`; GUI-Pfad ruft `detectedLegacyConfiguration` + `migrateConfigurationIfNeeded` in `BootstrapRunner` auf. `GuiConfigurationPropertiesWriterTest` prüft Backup-Schema. |
| 16 | Keine neuen Provider über Claude/OpenAI-kompatibel hinaus | **erfüllt** | Codebase enthält ausschließlich `ClaudeAiInvocationAdapter` und `OpenAiCompatibleAiInvocationAdapter`. Kein dritter Provider. |
| 17 | Keine neuen Distributionsformate (EXE/Installer) | **erfüllt** | `pom.xml` des Bootstrap-Moduls nutzt ausschließlich `maven-shade-plugin`. Kein `launch4j`, kein `jpackage`, kein Installer. |
| 18 | Kein manueller Verarbeitungslauf aus GUI (abgelöst ab V2.1) | **erfüllt** | `adapter-in-gui` enthält keine Klasse, die `BatchRunProcessingUseCase` aus einem GUI-Event aufruft. Kein „Start"-Button, keine Batch-Ausführungslogik im GUI-Adapter. |
| 19 | Keine DB-/Historienanzeige | **erfüllt** | Kein SQLite-Lesepfad aus `adapter-in-gui`. Kein Historien-Tab. Kein Ergebnis-Browser. |
| 20 | Keine fachlichen Änderungen an Kernverarbeitung | **erfüllt** | `DefaultBatchRunProcessingUseCase`, `DocumentProcessingCoordinator`, `AiNamingService`, `AiResponseValidator` sind gegenüber dem V1.1-Freigabestand unverändert. E2E-Tests (`BatchRunEndToEndTest`, 11 Szenarien) sind alle grün. |

---

## Dokumentations-Vollständigkeitsprüfung

| Dokument | Status | Bewertung |
|---|---|---|
| `docs/betrieb.md` | vollständig | Alle V2.0-Themen abgedeckt: GUI-Standardstart, `--headless`, `--config`-Semantik für beide Modi, Plattformhinweis Windows, gemappte Laufwerke, GUI-Umfangsbegrenzung, Build- und Packaging-Abschnitt, JavaFX-Integration, headless ohne JavaFX-Initialisierung |
| `docs/gui-bedienanleitung.md` | vollständig | Alle AP-002-Themen abgedeckt: Startzustände (Abschnitte 2.1–2.4), alle 7 Aktionen (Abschnitte 4.1–4.7), vier Meldungsstufen (Abschnitt 3.2), feldnahe Fehlermeldungen (Abschnitt 5), Provider-Bedienung und Modellabruf (Abschnitt 7), API-Key-Auflösungsreihenfolge (Abschnitt 10), Dirty-State (Abschnitt 8), `.bak`-Sicherung und Legacy-Migration (Abschnitt 9), Windows-Hinweise (Abschnitt 12), bekannte Einschränkungen (Abschnitt 13) |
| `docs/examples/application.properties` | vollständig und konsistent | Alle Parameter des V2.0-Schemas vorhanden (beide Provider-Blöcke, alle Pflicht- und Optionalparameter). Kommentare zu Warnschwellen für `max.text.characters` enthalten. Default-Provider `claude` gesetzt (alphabetisch erster). Konsistent mit `GuiConfigurationTemplateFactory`. |
| `docs/examples/prompt.txt` | vollständig und konsistent | Deutschsprachiger Standardprompt. Inhaltlich identisch mit dem, was `DefaultPromptTemplate.defaultContent()` erzeugt (durch `FilesystemResourceCreationAdapterTest` nachgewiesen). JSON-Schema-Anforderungen (title, reasoning, date optional) abgebildet. |
| `README.md` | vollständig | V2.0-Hinweis im Header, GUI-Standardstart dokumentiert, `--headless` und `--config`-Beispiele vorhanden, Modul `pdf-umbenenner-adapter-in-gui` aufgelistet, Verweis auf `betrieb.md` und `gui-bedienanleitung.md`. |

---

## Release-Blocker

**Keine Release-Blocker identifiziert.**

Der vollständige Maven-Reactor-Build ist grün (1.398 Tests, 0 Failures, 0 Errors, 0 Skipped).
Alle 20 Prüfpunkte gegen die Spec-Trias sind als erfüllt bewertet. Die Dokumentation ist
vollständig und konsistent mit dem Code.

---

## Nicht blockierende Restpunkte

#### R1 – ByteBuddy-Agent-Warnung bei Tests

**Thema:** Testqualität / Laufzeitwarnung  
**Befund:** Beim Build erscheint wiederholt `WARNING: A Java agent has been loaded dynamically
(byte-buddy-agent-1.14.12.jar)`. Der Hinweis stammt von Mockito und tritt seit dem V1.1-Stand auf.
Er ist nicht neu, betrifft nur die Testlaufzeit und hat keinen funktionalen Einfluss auf das
produzierte Artefakt.  
**Bewertung:** Kein Handlungsbedarf. Mit `-XX:+EnableDynamicAgentLoading` unterdrückbar, aber
keine Pflicht für V2.0.

#### R2 – GUI-Tests ohne echten JavaFX-Rendering-Pfad

**Thema:** Testtiefe GUI  
**Befund:** Die GUI-Tests (`GuiAdapterSmokeTest`, `GuiEditorRegressionSmokeTest` usw.) laufen
unter headless JavaFX (Monocle) und prüfen View-Modell-Logik, Zustandsübergänge und
Koordinatoren-Verhalten. Das visuelle Rendering der Oberfläche (Farbgebung der Meldungspräfixe,
Layout-Details) ist nicht automatisiert geprüft. Dies entspricht der in CLAUDE.md definierten
GUI-Teststrategie (kein TestFX über Monocle hinaus) und ist keine Abweichung vom Ziel.  
**Bewertung:** Kein Handlungsbedarf. Entspricht der Teststrategie-Vorgabe.

---

## Bewusst außerhalb V2.0 liegende Themen (V2.1+)

Die folgenden Themen wurden im V2.0-Umfang nachweislich **nicht** implementiert und sind
ausdrücklich für spätere Ausbaustufen vorgesehen:

- **Manueller Verarbeitungslauf aus der GUI** (V2.1+) – **umgesetzt ab V2.1** (Tab „Verarbeitungslauf")
- **DB-/Historienansicht** in der GUI (V2.x+)
- **Kosten-Tracking** und Token-/Preisberechnung (V2.x+)
- **EXE-Wrapper / Installer** (V3+) – **umgesetzt ab V3**: EXE-Wrapper (M14), MSI-Installer (M15)
- **Weitere KI-Provider** über Claude und OpenAI-kompatibel hinaus (V3+)
- **Automatischer Fallback zwischen Providern** (V3+)
- **Profilverwaltung mit mehreren Konfigurationen je Provider** (V3+)
- **Plattformübergreifender offizieller GUI-Support** (V3+)

---

## Gesamtbewertung V2.0-Stand

| Klassifikation | Anzahl | Beschreibung |
|---|---|---|
| Release-Blocker | **0** | – |
| Nicht blockierende Restpunkte | **2** | R1 ByteBuddy-Warnung, R2 Testtiefe GUI-Rendering |
| Bewusst außerhalb V2.0 | **8** | Manueller Lauf, Historienansicht, Kosten-Tracking, EXE, weitere Provider, Fallback, Profile, Cross-Platform |

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

---

> **Hinweis:** Für die Ausbaustufen V2.1 bis V2.9 wurden keine separaten Befundlisteneinträge
> erstellt. Befunde, Fixes und Verbesserungen dieser Stufen sind in den Gitea-Issues dokumentiert.
