Arbeitspakete für M8 erstellt

.gitignore

@@ -72,3 +72,4 @@ Desktop.ini
 hs_err_pid*
 replay_pid*
 /review-input.zip
+/run-milestone.ps1

CLAUDE.md

@@ -85,26 +85,30 @@ Wenn Dokumente fehlen, unklar sind oder sich widersprechen, nicht raten und kein
 
 ## Aktiver Implementierungsstand
 
-M1 bis M6 sind vollständig abgeschlossen. Der aktive Stand schließt die betriebliche
+M1 bis M7 sind vollständig abgeschlossen. Der aktive Stand ist der **Abschlussmeilenstein**:
-Lücke zwischen dem M6-Erfolgspfad und dem final robusten Endstand.
+Qualitätssicherung, Feinschliff und vollständige Entwicklungsfreigabe des Gesamtstands.
 
-### Baseline aus M6
+### Baseline aus M7
-- Technische Dateinamensbildung im Format `YYYY-MM-DD - Titel.pdf`
+- Vollständige laufübergreifende Retry-Logik (deterministisch + transient)
-- Dublettenbehandlung im Zielordner: `(1)`, `(2)`, …
+- Technischer Sofort-Wiederholversuch für Zielkopierfehler
-- Physische Zielkopie via temporäre Datei und finalem Move/Rename
+- Finalisierung ausgeschöpfter Retry-Rahmen zu `FAILED_FINAL`
-- Schemaevolution M5 → M6 (Zielpfad, Zieldateiname in Stammsatz und Versuchshistorie)
+- Vollständige Skip-Semantik (`SUCCESS`, `FAILED_FINAL`)
-- Statustransition `PROPOSAL_READY` → `SUCCESS`
+- Logging-Mindestumfang vollständig angebunden
-- Zusätzliche Historisierung für Enderfolg und technische Fehler
+- Sensibilitätsregel für KI-Inhalte im Logging
-- Startvalidierung für Zielordner-Konfiguration (`target.folder`)
+- Finale Exit-Code-Semantik und vervollständigte Startvalidierung
 
 ### Ziel des aktiven Stands
-- Vollständige laufübergreifende Retry-Logik für deterministische Inhaltsfehler und transiente technische Fehler
+M8 schließt **ausschließlich nachweisbare Restlücken** des aus M1–M7 entstandenen Gesamtstands:
-- Technischer Sofort-Wiederholversuch ausschließlich für Zielkopierfehler (genau ein zusätzlicher Versuch im selben Lauf)
+- Architekturgrenzen und code-nahe Dokumentation finalisieren
-- Finalisierung ausgeschöpfter Retry-Rahmen zu `FAILED_FINAL`
+- Status-, Persistenz- und Zielzustandskonsistenz bereinigen
-- Vollständige Skip-Semantik: `SUCCESS` und `FAILED_FINAL` werden historisiert übersprungen
+- Betreiberrelevante Logging-, Fehlertext- und Startvalidierungsrückmeldungen schärfen
-- Logging-Mindestumfang des Endstands vollständig angebunden
+- Konfigurationsbeispiele, Prompt-Bezug und Betriebsdokumentation konsolidieren
-- Sensibilitätsregel für KI-Inhalte im Logging
+- Deterministische End-to-End-Testbasis bereitstellen
-- Vervollständigte Startvalidierung und finale Exit-Code-Semantik
+- Regressionstests für Kernregeln vervollständigen
+- Kritische Coverage- und Mutationslücken schließen
+- Integrierte Gesamtprüfung mit Befundliste durchführen
+- Nachgewiesene Release-Blocker gezielt beheben
+- Finale Gesamtprüfung und Freigabedokumentation erstellen
 
 ## Statussemantik
 
@@ -275,6 +279,7 @@ Ein Arbeitspaket ist erst fertig, wenn:
 - Nach Änderungen den kleinsten sinnvollen Build-/Test-Umfang ausführen
 - Build-Validierung vom Parent-Root:
   `.\mvnw.cmd clean verify -pl pdf-umbenenner-domain,pdf-umbenenner-application,pdf-umbenenner-adapter-out,pdf-umbenenner-adapter-in-cli,pdf-umbenenner-bootstrap --also-make`
+- M8 hat 10 Arbeitspakete (AP-001 bis AP-010) – Start mit `-EndAp 10`
 - Schlägt der Build fehl: Fehler beheben, erneut bauen, erst dann weiter
 - Vor Abschluss sicherstellen, dass der relevante Maven-Reactor-Stand fehlerfrei ist
 - Fehler nicht kaschieren; Ursachen sauber beheben oder offen benennen
@@ -317,4 +322,20 @@ Verbindlich zweckmäßige Parameter:
 - kein Sofort-Wiederholversuch außerhalb des Zielkopierpfads
 - keine Reporting- oder Statistikfunktionen
 - keine neue dritte Persistenz-Wahrheitsquelle für Retry-Entscheidungen
-- kein M8-Gesamtfeinschliff oder großflächiges Refactoring
+- keine neue Fachfunktionalität jenseits des definierten Zielbilds
+- kein großflächiges Refactoring ohne nachweisbaren M8-Defektbezug
+- keine Metrik-Kosmetik (willkürliche Ausschlüsse, nicht belastbare Testumgehungen)
+- keine spekulativen Umbauten ohne konkreten Qualitäts- oder Konsistenzbezug
+- kein gleichzeitiger unbeschränkter Review und unbegrenzte Behebung in einem AP
+
+## M8-spezifische Arbeitsregeln
+
+**Review vor Behebung:** Gesamtprüfung (AP-008), Blockerbehebung (AP-009) und Freigabe (AP-010) sind getrennte Arbeitsschritte. Ein AP darf nicht gleichzeitig alles prüfen und alles beheben.
+
+**Nur nachweisbare Restlücken:** Änderungen müssen auf konkrete, belegbare Befunde aus dem realen Projektstand zurückführbar sein.
+
+**Rückwärtsverträglichkeit:** M4–M7-Datenbestände müssen weiterhin lesbar, fortschreibbar und korrekt interpretierbar bleiben.
+
+**Befunddatei im Repository:** AP-008 erzeugt eine im Repository verbleibende Befundliste mit Klassifizierung in Release-Blocker und nicht blockierende Punkte.
+
+**Freigabenachweis:** AP-010 erzeugt eine nachvollziehbare Entwicklungsfreigabe-Dokumentation im Repository, gestützt auf tatsächlich ausgeführte Prüfungen.

docs/workpackages/M8 - Arbeitspakete.md

@@ -0,0 +1,583 @@
+# M8 - Arbeitspakete
+
+## Geltungsbereich
+
+Dieses Dokument beschreibt ausschließlich die Arbeitspakete für den definierten Meilenstein **M8 – Abschlussmeilenstein: Qualitätssicherung, Feinschliff und vollständige Entwicklungsfreigabe**.
+
+Die Meilensteine **M1**, **M2**, **M3**, **M4**, **M5**, **M6** und **M7** werden als vollständig umgesetzt vorausgesetzt.
+
+Die Arbeitspakete sind bewusst so geschnitten, dass:
+
+- **KI 1** daraus je Arbeitspaket einen klaren Einzel-Prompt ableiten kann,
+- **KI 2** genau dieses eine Arbeitspaket in **einem Durchgang** vollständig umsetzen kann,
+- nach **jedem** Arbeitspaket wieder ein **fehlerfreier, buildbarer Stand** vorliegt.
+
+Die Reihenfolge der Arbeitspakete ist verbindlich.
+
+## Zusätzliche Schnittregeln für die KI-Bearbeitung
+
+- Pro Arbeitspaket nur die **minimal notwendigen Querschnitte** durch Domain, Application, Adapter, Bootstrap, Konfiguration, Dokumentation und Tests ändern.
+- Keine Annahmen treffen, die nicht durch die verbindlichen Spezifikationen oder den tatsächlich vorliegenden Code- und Teststand gedeckt sind.
+- Kein Vorgriff auf ein hypothetisches **M9** oder sonstige neue Produktfeatures.
+- Kein großflächiger Umbau bestehender M1–M7-Strukturen ohne nachweisbaren M8-Bezug.
+- M8 ist **review- und konsolidierungsgetrieben**: Es werden nur tatsächlich vorhandene Restlücken, Inkonsistenzen, Dokumentationsdefizite, Testlücken oder Qualitätsprobleme geschlossen.
+- M8 darf bestehende Implementierungen gezielt schärfen, vereinheitlichen oder bereinigen, aber nicht stillschweigend neue Fachregeln erfinden.
+- Jeder positive M8-Zwischenstand muss bereits einen **robusten, vollständig buildbaren und testbaren Endstand** liefern, auch wenn die vollständige Entwicklungsfreigabe erst mit späteren Arbeitspaketen nachgewiesen wird.
+- Ein Arbeitspaket darf nur dann auf neue Prüf-, Test- oder Repository-Fähigkeiten aufbauen, wenn diese bereits aus M1–M7 vorhanden sind oder im unmittelbar vorhergehenden Arbeitspaket explizit geschaffen wurden.
+- Ein M8-Arbeitspaket darf innerhalb seines benannten Themas zuerst **gezielt prüfen** und dann **nur die in genau diesem Thema nachweisbaren Befunde** beheben.
+- Unspezifische Sammelaufträge wie „alles prüfen und alles fixen“ sind **kein** zulässiger Zuschnitt für ein einzelnes Arbeitspaket.
+- Wo ein Arbeitspaket einen Prüfbericht oder Freigabenachweis verlangt, muss dieser **im Repository verbleiben** und auf den real ausgeführten Build-/Teststand bezogen sein.
+
+## Explizit nicht Bestandteil von M8
+
+- neue Fachfunktionalität jenseits des bereits definierten Zielbilds
+- neue Meilensteine, Folgeprodukte oder optionale Komfortfunktionen
+- Web-UI, REST-API, OCR, Benutzerinteraktion oder manuelle Nachbearbeitung
+- Reporting-, Monitoring- oder Statistikfunktionen ohne zwingenden M8-Bezug
+- großflächige Architektur-Neuerfindung statt gezielter Endstandskonsolidierung
+- kosmetische Änderungen ohne nachweisbaren Nutzen für Betrieb, Konsistenz, Verständlichkeit oder Qualität
+- Metrik-Tuning ohne fachlich oder technisch belastbare Begründung
+- pauschale „Aufräumarbeiten“, die nicht an einen konkreten, belegbaren M8-Befund gebunden sind
+
+## Verbindliche M8-Regeln für **alle** Arbeitspakete
+
+### 1. M8 schließt nur reale Restlücken des Endstands
+
+M8 ergänzt keine neue Produktvision, sondern bringt den aus M1–M7 entstandenen Gesamtstand auf einen vollständig konsistenten, dokumentierten und freigabefähigen Abschlusszustand.
+
+Daraus folgt:
+
+- Es werden nur **nachweisbare** Restlücken geschlossen.
+- Spekulative Umbauten ohne konkreten Defekt-, Qualitäts- oder Konsistenzbezug sind unzulässig.
+- Änderungen müssen sich auf die verbindlichen Spezifikationen und den realen Projektstand zurückführen lassen.
+
+### 2. Architekturtreue bleibt unverrückbar
+
+Auch in M8 gilt unverändert:
+
+- strikte hexagonale Architektur,
+- Abhängigkeiten zeigen nach innen,
+- keine Infrastrukturtypen in Domain oder Application,
+- keine direkte Adapter-zu-Adapter-Kopplung,
+- keine neue Parallelstruktur neben dem etablierten Modul- und Port-Modell.
+
+M8 darf bestehende Verstöße beseitigen, aber keine neuen einführen.
+
+### 3. Keine zweite Wahrheitsquelle für fachliche oder technische Kernzustände
+
+Die bereits etablierte Wahrheitsbasis bleibt auch in M8 verbindlich:
+
+- Dokument-Stammsatz für Gesamtstatus und Zähler,
+- Versuchshistorie für einzelne Versuche und Nachvollziehbarkeit,
+- führender `PROPOSAL_READY`-Versuch als Quelle des M5-Benennungsvorschlags,
+- Zielartefaktzustand gemäß M6/M7.
+
+M8 führt **keine** zusätzliche Parallelwahrheit für Status, Retry, Proposal, Zielname, Logging-Entscheidungen oder Ergebnisbewertung ein.
+
+### 4. Dokumentation und Implementierung müssen widerspruchsfrei sein
+
+Ab M8 gilt der Endstand nur dann als korrekt, wenn:
+
+- JavaDoc,
+- `package-info`,
+- Konfigurationsbeispiele,
+- Start- und Betriebsdokumentation,
+- Logging- und Fehlermeldungssemantik,
+- Prüf- und Freigabenachweise,
+- sowie Tests
+
+in ihrer Aussage mit dem tatsächlichen Verhalten des Codes übereinstimmen.
+
+### 5. Testfokus auf Kerninvarianten statt auf Metrik-Kosmetik
+
+M8 vervollständigt die Qualitätssicherung gezielt für die fachlich und technisch tragenden Regeln des Systems, insbesondere für:
+
+- Status- und Retry-Semantik,
+- Persistenzkonsistenz,
+- Dateinamensbildung,
+- Zielkopie,
+- Startvalidierung,
+- Logging-Sensibilität,
+- Mehrlaufverhalten,
+- End-to-End-Abläufe.
+
+Reine Zahlenoptimierung ohne belastbaren Risikobezug ist nicht Ziel von M8.
+
+### 6. Rückwärtsverträglichkeit bestehender Datenbestände bleibt erhalten
+
+M8 muss bestehende M4–M7-Datenbestände weiterhin:
+
+- lesen,
+- korrekt fortschreiben,
+- und konsistent interpretieren
+
+können, soweit dies innerhalb des bereits definierten Zielbilds erforderlich ist.
+
+### 7. Betreiberrelevante Rückmeldungen müssen klar, konsistent und belastbar sein
+
+M8 schärft operator-seitige Rückmeldungen so, dass Start-, Konfigurations-, Dokument- und Fehlerzustände ohne unnötige Interpretation nachvollziehbar sind.
+
+Daraus folgt:
+
+- Fehlermeldungen dürfen weder irreführend noch widersprüchlich sein.
+- Logging und Dokumentation müssen dieselben Kernbegriffe verwenden.
+- Sensible KI-Inhalte bleiben standardmäßig geschützt.
+
+### 8. Vollständige Entwicklungsfreigabe erfordert einen nachweisbaren Gesamtlauf
+
+Der M8-Endstand gilt erst dann als abgeschlossen, wenn nachgewiesen ist, dass mindestens folgende Ebenen zusammenpassen:
+
+- Maven-Reactor-Build,
+- relevante Test-Suiten,
+- Smoke- und Startverhalten,
+- End-to-End-Gesamtablauf,
+- Konfigurationsbeispiele,
+- Dokumentation,
+- Artefakterzeugung.
+
+### 9. M8 darf gezielt bereinigen, aber nicht unkontrolliert refaktorieren
+
+Zulässig sind nur solche Bereinigungen, die unmittelbar einem dieser Ziele dienen:
+
+- Architekturtreue,
+- Konsistenz,
+- Verständlichkeit,
+- Testbarkeit,
+- Stabilität,
+- Dokumentationsklarheit,
+- Freigabefähigkeit.
+
+Großflächige Strukturumbauten ohne unmittelbaren M8-Nutzen sind ausgeschlossen.
+
+### 10. Gesamtprüfung, Blockerbehebung und Abschlussfreigabe sind getrennte Arbeitsschritte
+
+Für die zweistufige KI-Bearbeitung gilt in M8 zusätzlich:
+
+- **integrierte Gesamtprüfung**, **gezielte Release-Blocker-Behebung** und **finale Freigabebestätigung** sind getrennte Arbeitspakete,
+- ein einzelnes Arbeitspaket darf nicht gleichzeitig einen unbeschränkten Gesamtreview durchführen **und** unbegrenzt alle dabei gefundenen Themen beheben,
+- Release-Blocker dürfen nur dann in einem späteren Arbeitspaket behoben werden, wenn sie im unmittelbar vorhergehenden Prüf-Arbeitspaket **konkret nachgewiesen und eingegrenzt** wurden.
+
+---
+
+## AP-001 Architekturgrenzen und code-nahe Endstandsdokumentation finalisieren
+
+### Voraussetzung
+Keine. Dieses Arbeitspaket ist der M8-Startpunkt.
+
+### Ziel
+Die Architekturgrenzen des Gesamtstands werden abschließend geschärft und in Code-naher Dokumentation so verankert, dass spätere M8-Arbeitspakete ohne Interpretationsspielraum auf einem konsolidierten Endstandsverständnis aufsetzen können.
+
+### Muss umgesetzt werden
+- Bestehende Modulgrenzen, Verantwortlichkeiten und Abhängigkeitsrichtungen gegen den realen Codebestand prüfen und **nur nachweisbare** M8-relevante Unschärfen oder Verstöße gezielt bereinigen.
+- JavaDoc und `package-info` dort vervollständigen oder schärfen, wo für den Endstand noch Lücken oder Widersprüche bestehen, insbesondere für:
+  - Domain-Verantwortung,
+  - Application-Orchestrierung,
+  - Port-Zwecke,
+  - Adapter-Verantwortung,
+  - Bootstrap-Aufgaben,
+  - Endstandsbegriffe wie Status, Retry, Proposal-Quelle, Zielerfolg und Nachvollziehbarkeit.
+- Sicherstellen, dass Architekturgrenzen in der Dokumentation dieselben Begriffe und dieselbe Semantik verwenden wie die implementierte Logik aus M1–M7.
+- Nachweisbare, code-seitig sichtbare Grenzverletzungen nur dort korrigieren, wo sie für M8-Freigabe, Wartbarkeit oder Spezifikationstreue relevant sind.
+- Änderungen in Produktionscode auf **architekturbezogene** Korrekturen begrenzen; keine operator-seitigen Meldungstexte, keine Persistenzbereinigung und keine Testkampagne dieses Arbeitspakets vorwegnehmen.
+- Die für den Endstand verbindlichen Architektur- und Begriffsinvarianten so dokumentieren, dass KI 1 daraus für nachfolgende Arbeitspakete einen präzisen Prompt ableiten kann.
+
+### Explizit nicht Teil
+- neue Fachfunktionalität
+- neue Persistenzmodelle oder neue Port-Landschaften ohne Defektbezug
+- großflächige Umstrukturierungen ohne nachweisbaren Architekturverstoß
+- operator-seitige Logging-/Fehlermeldungsüberarbeitung
+- vollständige Testergänzung oder Dokumentationskonsolidierung außerhalb der code-nahen Architekturgrundlage
+
+### Fertig wenn
+- die Architekturgrenzen des Endstands im Code und in der code-nahen Dokumentation klar, konsistent und belastbar beschrieben sind,
+- nachweisbare M8-relevante Architekturverstöße gezielt bereinigt sind,
+- spätere M8-Arbeitspakete ohne Grundsatzunklarheiten aufsetzen können,
+- der Build weiterhin fehlerfrei ist.
+
+---
+
+## AP-002 Status-, Persistenz-, Proposal- und Zielzustandskonsistenz des Endstands bereinigen
+
+### Voraussetzung
+AP-001 ist abgeschlossen.
+
+### Ziel
+Die letzte Konsistenzlücke zwischen Dokument-Stammsatz, Versuchshistorie, Proposal-Quelle, Zielartefaktzustand und Adapterverhalten wird geschlossen, ohne neue Wahrheitsquellen oder neue Fachregeln einzuführen.
+
+### Muss umgesetzt werden
+- Den realen Gesamtstand aus M4–M7 gezielt auf **nachweisbare** Inkonsistenzen prüfen, insbesondere zwischen:
+  - Gesamtstatus im Dokument-Stammsatz,
+  - Fehlerzählern,
+  - historisierten Versuchsdaten,
+  - führender `PROPOSAL_READY`-Quelle,
+  - persistierten Zielartefaktdaten,
+  - Adapter-Ergebnissen in Rand- und Fehlerfällen.
+- Tatsächlich vorhandene Inkonsistenzen im Endstand gezielt bereinigen, insbesondere wenn sie zu widersprüchlichem Mehrlaufverhalten, unstimmiger Persistenzfortschreibung oder fehleranfälliger M6/M7-Finalisierung führen können.
+- Sicherstellen, dass M4–M7-Datenbestände weiterhin lesbar und korrekt fortschreibbar bleiben.
+- Sicherstellen, dass keine redundante zweite Persistenzwahrheit für Proposal-, Retry-, Ziel- oder Fehlerzustände entsteht.
+- Nachweisbare Semantiklücken zwischen Repository-Verhalten und Use-Case-Entscheidungen nur soweit schließen, wie sie für den M8-Endstand kritisch sind.
+- Unmittelbar betroffene JavaDoc-, Mapping- und Teststellen mitziehen, aber keine operator-seitige Textschärfung oder allgemeine Testkampagne dieses Arbeitspakets vorwegnehmen.
+
+### Explizit nicht Teil
+- neue Fachregeln über M1–M7 hinaus
+- Reporting-, Statistik- oder Analysefunktionen
+- großflächige Schema-Neuerfindung ohne zwingenden M8-Bedarf
+- Logging-Feinschliff oder Dokumentationskonsolidierung außerhalb des Konsistenzbezugs
+- integrierte Gesamtprüfung des vollständigen Release-Kandidaten
+
+### Fertig wenn
+- nachweisbare Inkonsistenzen zwischen Statusmodell, Persistenz, Proposal-Quelle, Zielartefaktzustand und Adapterverhalten beseitigt sind,
+- Mehrlaufverhalten, Proposal-Quelle und Zielartefaktzustand konsistent zusammenwirken,
+- keine neue Parallelwahrheit eingeführt wurde,
+- der Stand weiterhin fehlerfrei buildbar ist.
+
+---
+
+## AP-003 Betreiberrelevante Logging-, Fehlertext- und Startvalidierungsrückmeldungen des Endstands schärfen
+
+### Voraussetzung
+AP-001 und AP-002 sind abgeschlossen.
+
+### Ziel
+Die nach außen sichtbaren Rückmeldungen des Systems werden sprachlich und inhaltlich so geschärft, dass Betrieb, Fehlersuche und Freigabe des Endstands ohne unnötige Mehrdeutigkeit möglich sind.
+
+### Muss umgesetzt werden
+- Bestehende Logging- und Fehlermeldungen für Start-, Konfigurations-, Dokument- und Laufzustände auf **nachweisbare** Unschärfen, Widersprüche, missverständliche Formulierungen oder inkonsistente Begriffsnutzung prüfen.
+- Betreiberrelevante Meldungen gezielt nachschärfen, insbesondere für:
+  - harte Start- und Konfigurationsfehler,
+  - dokumentbezogene Fehlerklassifikation,
+  - Retry-Entscheidungen,
+  - Skip-Fälle,
+  - Proposal- und Zielerfolgszustände,
+  - Laufstart und Laufende.
+- Sicherstellen, dass die M7-Sensibilitätsregel für KI-Inhalte sprachlich und technisch konsistent bleibt und nicht durch irreführende Logs oder Fehlermeldungen unterlaufen wird.
+- Startvalidierungsfehler so strukturieren, dass sie klare Betreiberhinweise liefern, ohne technische Interna oder falsche Ursachenketten zu suggerieren.
+- Terminologie zwischen Logging, Exception-Texten, Konfigurationsvalidierung und dokumentierter Semantik vereinheitlichen.
+- Falls dafür gezielte technische Verdrahtungs- oder Formatierungsanpassungen erforderlich sind, diese minimal und architekturtreu umsetzen.
+- Nur die für diese Rückmeldungen unmittelbar nötigen Tests ergänzen oder schärfen.
+
+### Explizit nicht Teil
+- neues Logging-Framework oder neue Telemetrieebenen
+- neue Betriebsfeatures ohne M8-Bezug
+- umfassende Dokumentationskonsolidierung außerhalb der operator-seitigen Rückmeldungen
+- vollständige End-to-End-Testergänzung
+- Coverage-/PIT-Kampagne
+
+### Fertig wenn
+- Logging- und Fehlerrückmeldungen des Endstands klar, konsistent und belastbar sind,
+- Betreiberrelevante Zustände ohne unnötige Interpretation nachvollziehbar bleiben,
+- die Sensibilitätsregel für KI-Inhalte weiterhin sauber greift,
+- der Stand fehlerfrei buildbar ist.
+
+---
+
+## AP-004 Konfigurationsbeispiele, Prompt-Bezug sowie Start- und Betriebsdokumentation konsolidieren
+
+### Voraussetzung
+AP-001 bis AP-003 sind abgeschlossen.
+
+### Ziel
+Der Repository-Stand enthält eine konsolidierte, mit dem echten Endverhalten abgestimmte Dokumentations- und Beispielbasis, mit der lokale Starts, Batch-Läufe und Betriebsverständnis ohne implizite Annahmen möglich sind.
+
+### Muss umgesetzt werden
+- Die vorhandenen Konfigurationsbeispiele gegen den realen Endstand prüfen und gezielt vervollständigen oder bereinigen, insbesondere für:
+  - Pflichtparameter,
+  - optionale Parameter,
+  - sinnvolle Beispielwerte,
+  - M7-relevante Logging- und Retry-Konfiguration,
+  - Priorität von Umgebungsvariable gegenüber Properties beim API-Key.
+- Den vorhandenen Prompt-Bezug im Repository konsistent dokumentieren.
+- Falls für einen reproduzierbaren lokalen Start ein Prompt-Beispiel oder ein nachvollziehbares Prompt-Skelett im Repository fehlt, dieses **minimal und endstandskonform** ergänzen.
+- Start-, Konfigurations- und Betriebsdokumentation so konsolidieren, dass mindestens nachvollziehbar beschrieben sind:
+  - benötigte Eingaben,
+  - Start des ausführbaren Artefakts,
+  - Quell- und Zielordnerbezug,
+  - SQLite-Nutzung,
+  - Retry- und Skip-Grundverhalten,
+  - Logging-Grundverhalten,
+  - Umgang mit sensiblen KI-Inhalten im Logging,
+  - Grenzen des Systems.
+- Veraltete, widersprüchliche oder nicht mehr zum Endstand passende Dokumentation gezielt bereinigen.
+- Sicherstellen, dass Konfigurationsnamen, Dateinamen, Beispielpfade und Dokumentationsaussagen mit dem tatsächlichen Code übereinstimmen.
+- Nur dann produktiven Code anfassen, wenn Dokumentation und Code an einem **eindeutig nachweisbaren** Benennungs- oder Konfigurationskonflikt auseinanderlaufen.
+
+### Explizit nicht Teil
+- externe Web-Dokumentation oder Handbücher außerhalb des Repositories
+- neue Fachfunktionalität
+- breit angelegte Code-Refactorings ohne Dokumentationsbezug
+- finale Testlückenschließung
+- integrierte Gesamtprüfung des Release-Kandidaten
+
+### Fertig wenn
+- der Endstand über die im Repository enthaltenen Beispiele und Dokumente nachvollziehbar start- und betreibbar beschrieben ist,
+- Konfigurations- und Prompt-Beispiele zum realen Code passen,
+- veraltete oder widersprüchliche Dokumentation bereinigt ist,
+- der Stand weiterhin fehlerfrei buildbar bleibt.
+
+---
+
+## AP-005 Deterministische End-to-End-Testbasis und wiederverwendbare Testdaten für den Gesamtprozess bereitstellen
+
+### Voraussetzung
+AP-001 bis AP-004 sind abgeschlossen.
+
+### Ziel
+Für den finalen Qualitätsnachweis steht eine robuste, deterministische und wiederverwendbare End-to-End-Testbasis bereit, die den vollständigen Batch-Prozess des Endstands ohne externe Unsicherheiten reproduzierbar abbilden kann.
+
+### Muss umgesetzt werden
+- Eine wiederverwendbare End-to-End-Testbasis für den Gesamtprozess bereitstellen, die mindestens kontrolliert kapselt:
+  - Quellordner,
+  - Zielordner,
+  - temporäre Artefakte,
+  - SQLite-Datei,
+  - Konfiguration,
+  - erforderliche Test-Doubles für externe Abhängigkeiten.
+- Deterministische Testdaten bzw. Testfixturen für zentrale Endstands-Szenarien bereitstellen, insbesondere für:
+  - Happy-Path bis `SUCCESS`,
+  - deterministischen Inhaltsfehler,
+  - transienten technischen Fehler,
+  - Skip nach `SUCCESS`,
+  - Skip nach `FAILED_FINAL`,
+  - vorhandenes `PROPOSAL_READY` mit späterer Finalisierung,
+  - Zielkopierfehler mit M7-Sofort-Wiederholversuch.
+- Sicherstellen, dass die End-to-End-Testbasis keine unkontrollierte Abhängigkeit von externen KI-Diensten, instabilen Dateisystemzuständen oder globalen Laufzeitumgebungen hat.
+- Testhilfen und Fixture-Strukturen so schneiden, dass spätere M8-Testarbeitspakete ohne erneut erfundene Testinfrastruktur darauf aufbauen können.
+- Dokumentieren, welche Endstands-Invarianten durch die End-to-End-Testbasis gezielt nachweisbar gemacht werden.
+
+### Explizit nicht Teil
+- vollständige Schließung aller Test- und Coverage-Lücken
+- willkürliche Testvermehrung ohne Endstandsbezug
+- neue Fachfunktionalität
+- Qualitätsmetriken-Tuning ohne konkreten Testfallbezug
+- globale Release-Freigabeentscheidung
+
+### Fertig wenn
+- eine stabile und deterministische End-to-End-Testbasis vorhanden ist,
+- die relevanten Endstands-Szenarien reproduzierbar vorbereitet werden können,
+- spätere M8-Testarbeitspakete ohne neue Testgrundstruktur anschließen können,
+- der Stand fehlerfrei buildbar ist.
+
+---
+
+## AP-006 Regressionstests für Kernregeln, Randfälle und Konsistenzinvarianten des Endstands vervollständigen
+
+### Voraussetzung
+AP-001 bis AP-005 sind abgeschlossen.
+
+### Ziel
+Die fachlich und technisch tragenden Regeln des Gesamtstands sind automatisiert so abgesichert, dass echte Regressionsrisiken des Produktiv-Endstands zuverlässig erkannt werden.
+
+### Muss umgesetzt werden
+- Gezielt Regressionstests für die tragenden Regeln aus M1–M7 ergänzen oder vervollständigen, insbesondere für:
+  - Status- und Retry-Semantik,
+  - Mehrlaufverhalten,
+  - Skip-Regeln,
+  - Proposal-Quelle,
+  - Dateinamensbildung,
+  - Windows-Kompatibilität,
+  - Dublettenauflösung,
+  - Zielkopie,
+  - Persistenzkonsistenz,
+  - Startvalidierung,
+  - Logging-Sensibilität,
+  - Exit-Code-Endverhalten.
+- Randfälle gezielt absichern, die für den Endstand regressionskritisch sind, insbesondere:
+  - inkonsistente historische Datenzustände im zulässigen M4–M7-Rahmen,
+  - Grenzfälle bei Fehlerzählern,
+  - fehlgeschlagene Persistenz nach technischer Zielkopie,
+  - erneute Läufe nach terminalen Zuständen,
+  - Proposal- und Finalisierungsübergänge.
+- Sicherstellen, dass die Tests reale Endstands-Invarianten prüfen und nicht bloß Implementierungsdetails einfrieren.
+- Bestehende Testlücken dort schließen, wo ohne diese Lücke eine belastbare Entwicklungsfreigabe nicht möglich wäre.
+- Die End-to-End-Testbasis aus AP-005 gezielt wiederverwenden und nicht parallel neu erfinden.
+
+### Explizit nicht Teil
+- rein kosmetische Testergänzungen ohne Risikobezug
+- neue Produktfeatures
+- breitflächige Qualitätsmetriken-Kampagnen ohne konkrete kritische Lücke
+- vollständige Freigabeprüfung des Gesamtprojekts
+
+### Fertig wenn
+- die regressionskritischen Kernregeln des Endstands automatisiert abgesichert sind,
+- Randfälle mit hoher Relevanz für Stabilität, Konsistenz und Mehrlaufverhalten belastbar getestet sind,
+- die Testbasis kohärent und wiederverwendbar bleibt,
+- der Stand fehlerfrei buildbar und testbar ist.
+
+---
+
+## AP-007 Kritische Coverage- und Mutationslücken des Endstands gezielt schließen
+
+### Voraussetzung
+AP-001 bis AP-006 sind abgeschlossen.
+
+### Ziel
+Die Qualitätsabsicherung des Endstands wird dort gezielt nachgehärtet, wo JaCoCo- oder PIT-Ergebnisse noch reale Risiken in den tragenden Entscheidungs- und Fehlerpfaden erkennen lassen.
+
+### Muss umgesetzt werden
+- Die vorhandenen Qualitätsauswertungen des Projekts gezielt auf **fachlich und technisch kritische** Lücken prüfen, insbesondere in Bereichen wie:
+  - Retry-Entscheidung,
+  - Statusfortschreibung,
+  - Persistenzkonsistenz,
+  - Dateinamensbildung,
+  - Zielkopierpfad,
+  - Startvalidierung,
+  - Logging-Sensibilitätsentscheidung.
+- Bedeutungsvolle Lücken oder überlebende Mutationen gezielt durch:
+  - zusätzliche Tests,
+  - kleinere, nachweisbar sinnvolle Implementierungsschärfungen,
+  - oder eng begründete Testfallpräzisierungen
+  schließen.
+- Vorhandene Qualitäts-Gates oder bestehende Qualitäts-Reports für den relevanten Projektstand stabil grün bekommen, soweit dies bereits Teil des Build-Setups ist.
+- Sicherstellen, dass keine Metrik-Kosmetik betrieben wird, etwa durch willkürliche Ausschlüsse oder nicht belastbare Testumgehungen.
+- Nur dann Build- oder Qualitätskonfiguration anfassen, wenn dies für einen korrekten, belastbaren M8-Endstand zwingend erforderlich ist und sachlich begründet werden kann.
+- Änderungen auf die **nachgewiesenen** Hochrisiko-Lücken begrenzen; kein blindes Nachhärten bereits unkritischer Bereiche.
+
+### Explizit nicht Teil
+- blindes Hochschrauben von Kennzahlen ohne Risikobezug
+- großflächige Qualitätsgate-Neuerfindung ohne bestehenden Projektbezug
+- neue Fachfunktionalität
+- Abschlussfreigabe des Gesamtprojekts ohne vorherigen Gesamtprüfnachweis
+
+### Fertig wenn
+- die kritischen Coverage- und Mutationslücken des Endstands gezielt geschlossen sind,
+- verbleibende Qualitätsauswertungen keine offensichtlichen Hochrisiko-Blindstellen mehr zeigen,
+- das Build- und Testsetup belastbar grün bleibt,
+- keine Metrik-Kosmetik eingeführt wurde.
+
+---
+
+## AP-008 Integrierte Gesamtprüfung des Endstands und belastbare Befundliste erstellen
+
+### Voraussetzung
+AP-001 bis AP-007 sind abgeschlossen.
+
+### Ziel
+Der zu diesem Zeitpunkt erreichte Endstand wird ganzheitlich geprüft, und es entsteht eine belastbare, im Repository verbleibende Befundliste, aus der KI 1 für ein mögliches Folge-Arbeitspaket ausschließlich die tatsächlich verbliebenen Release-Blocker ableiten kann.
+
+### Muss umgesetzt werden
+- Den vollständigen Projektstand ganzheitlich gegen die verbindlichen Spezifikationen sowie die Ergebnisse aus M1–M7 prüfen.
+- Den vollständigen Maven-Reactor-Build, relevante Test-Suiten, Smoke-Tests des ausführbaren Artefakts und die maßgeblichen End-to-End-Prüfungen des Endstands tatsächlich ausführen und auswerten.
+- Prüfen und schriftlich festhalten, dass insbesondere zusammenpassen oder wo noch Abweichungen bestehen:
+  - Architektur und Modulgrenzen,
+  - Fachregeln,
+  - Persistenz- und Retry-Semantik,
+  - Dateinamens- und Zielkopierverhalten,
+  - Startvalidierung und Exit-Code,
+  - Logging und Sensibilitätsregel,
+  - Konfigurationsbeispiele,
+  - Betriebs- und Startdokumentation,
+  - Build- und Testartefakte.
+- Eine knappe, im Repository verbleibende Befunddatei ergänzen oder aktualisieren, die:
+  - die tatsächlich ausgeführten Prüfungen benennt,
+  - grüne Bereiche von offenen Punkten trennt,
+  - offene Punkte nach **Release-Blocker** vs. **nicht blockierend** klassifiziert,
+  - pro Release-Blocker den betroffenen Themenbereich eindeutig eingrenzt.
+- Nur die minimal notwendigen Änderungen an Build-/Testhilfen oder Prüfskripten vornehmen, die erforderlich sind, um diese integrierte Gesamtprüfung reproduzierbar auszuführen.
+
+### Explizit nicht Teil
+- pauschale Behebung aller in diesem Gesamtreview entdeckten Themen in demselben Arbeitspaket
+- neue Produktfeatures oder neue Meilensteine
+- nachträgliche Großrefactorings ohne klaren Prüfbezug
+- finale Freigabeerklärung des Projekts
+
+### Fertig wenn
+- der vollständige Endstand ganzheitlich geprüft ist,
+- die tatsächlich ausgeführten Prüfungen belastbar dokumentiert sind,
+- eine klar eingegrenzte Befundliste im Repository vorliegt,
+- eventuelle Release-Blocker für ein Folge-Arbeitspaket präzise genug beschrieben sind,
+- der Stand weiterhin fehlerfrei buildbar ist.
+
+---
+
+## AP-009 Gezielte Release-Blocker aus der integrierten Gesamtprüfung beheben
+
+### Voraussetzung
+AP-008 ist abgeschlossen.
+
+### Ziel
+Nur die in AP-008 konkret nachgewiesenen und eingegrenzten Release-Blocker werden gezielt beseitigt, ohne den Scope des Abschlussmeilensteins erneut zu öffnen.
+
+### Muss umgesetzt werden
+- Ausschließlich die in der Befundliste aus AP-008 als **Release-Blocker** ausgewiesenen Punkte bearbeiten.
+- Die Behebung pro Blocker auf den dort klar benannten Themenbereich begrenzen.
+- Sicherstellen, dass keine nicht belegten Nebenbaustellen oder neuen Qualitätskampagnen in dieses Arbeitspaket hineingezogen werden.
+- Unmittelbar betroffene Tests, Dokumentationsstellen und Konfigurationsbeispiele mitziehen, soweit dies zur konsistenten Behebung des konkreten Blockers nötig ist.
+- Falls AP-008 **keine** Release-Blocker nachgewiesen hat, in diesem Arbeitspaket keine unnötigen Produktionsänderungen vornehmen, sondern die Blockerfreiheit nur konsistent im Repository nachvollziehbar machen.
+- Nach der Blockerbehebung mindestens den für die betroffenen Blocker notwendigen Build-/Testumfang erneut ausführen.
+
+### Explizit nicht Teil
+- Behebung bloß nicht blockierender Schönheitsmängel
+- neue Produktfeatures oder neue Meilensteine
+- erneute globale Gesamtprüfung des kompletten Endstands
+- breitflächige Nachschärfung von Bereichen, die in AP-008 nicht als Blocker eingegrenzt wurden
+
+### Fertig wenn
+- alle in AP-008 nachgewiesenen Release-Blocker gezielt beseitigt oder nachvollziehbar als nicht mehr vorhanden bestätigt sind,
+- keine unnötige Scope-Ausweitung stattgefunden hat,
+- die betroffenen Bereiche wieder fehlerfrei buildbar und testbar sind,
+- der Stand weiterhin übergabefähig ist.
+
+---
+
+## AP-010 Finale Gesamtprüfung, Freigabedokumentation und Abschluss des M8-Endstands durchführen
+
+### Voraussetzung
+AP-001 bis AP-009 sind abgeschlossen.
+
+### Ziel
+Der Gesamtstand wird abschließend als vollständig freigabefähiger Produktiv-Endstand innerhalb des definierten Projektumfangs nachgewiesen und die Entwicklungsfreigabe wird nachvollziehbar dokumentiert.
+
+### Muss umgesetzt werden
+- Den vollständigen Maven-Reactor-Build, die relevanten Test-Suiten, Smoke-Tests des ausführbaren Artefakts und die maßgeblichen End-to-End-Prüfungen des Endstands erneut tatsächlich ausführen und auswerten.
+- Prüfen und bestätigen, dass insbesondere zusammenpassen:
+  - Architektur und Modulgrenzen,
+  - Fachregeln,
+  - Persistenz- und Retry-Semantik,
+  - Dateinamens- und Zielkopierverhalten,
+  - Startvalidierung und Exit-Code,
+  - Logging und Sensibilitätsregel,
+  - Konfigurationsbeispiele,
+  - Betriebs- und Startdokumentation,
+  - Build- und Testartefakte.
+- Eine knappe, im Repository verbleibende Abschluss- bzw. Freigabedokumentation ergänzen oder aktualisieren, die mindestens festhält:
+  - welche Prüfungen tatsächlich ausgeführt wurden,
+  - dass keine bekannten, spezifikationsrelevanten Release-Blocker für den definierten Projektumfang offen sind,
+  - auf welche Artefakte, Tests oder Dokumente sich diese Aussage stützt.
+- Sicherstellen, dass nach diesem Arbeitspaket kein bekannter, spezifikationsrelevanter Blocker für den definierten Projektumfang offen bleibt.
+- Nur dann noch Änderungen am Produktionscode, an Tests oder an Dokumentation vornehmen, wenn im unmittelbaren Abschlussdurchlauf ein **konkret nachweisbarer** Freigabeblocker auftritt, der ohne Scope-Ausweitung minimal behoben werden kann.
+
+### Explizit nicht Teil
+- neue Produktfeatures oder neue Meilensteine
+- nachträgliche Großrefactorings ohne unmittelbaren Freigabeblocker-Bezug
+- beliebige Schönheitskorrekturen ohne Freigaberelevanz
+
+### Fertig wenn
+- der vollständige Endstand ganzheitlich geprüft und freigabefähig ist,
+- Build, Tests, Smoke-Verhalten und End-to-End-Abläufe belastbar grün sind,
+- keine bekannten, spezifikationsrelevanten Release-Blocker mehr offen sind,
+- Dokumentation, Konfiguration und Artefakterzeugung mit dem realen Endstand übereinstimmen,
+- ein fehlerfreier, übergabefähiger Abschlussstand vorliegt.
+
+---
+
+## Abschlussbewertung
+
+Die Arbeitspakete decken den vollständigen M8-Zielumfang aus den verbindlichen Spezifikationen ab und schneiden den Abschlussmeilenstein für die zweistufige KI-Bearbeitung präziser als zuvor:
+
+- abschließender Architektur- und Dokumentationsabgleich
+- gezielte Bereinigung realer Restinkonsistenzen im Endstand
+- Schärfung von Logging-, Fehler- und Betreiber-Rückmeldungen
+- Konsolidierung von Konfigurations-, Prompt- und Betriebsdokumentation
+- deterministische End-to-End-Testbasis
+- gezielte Regressionstests für Kernregeln und Randfälle
+- belastbare Schließung kritischer Coverage- und Mutationslücken
+- integrierte Gesamtprüfung mit dokumentierter Befundliste
+- gezielte, klar eingegrenzte Behebung nachgewiesener Release-Blocker
+- abschließende Gesamtprüfung mit nachvollziehbarer Entwicklungsfreigabe
+
+Gleichzeitig bleiben die Grenzen zu M1–M7 gewahrt:
+
+- M8 erfindet keine neue Produktfunktionalität,
+- M8 führt keine zweite Wahrheitsquelle ein,
+- M8 rollt M1/M2-Themen nicht pauschal neu auf, sondern schließt nur reale Restlücken des Endstands,
+- M8 trennt Gesamtprüfung, Blockerbehebung und Freigabe in eigenständige, für KI 1 und KI 2 präzise nutzbare Arbeitsschritte.

java-packages-inventory.txt

@@ -1,68 +0,0 @@
-pdf-umbenenner-adapter-in-cli/src/main/java/de/gecheckt/pdf/umbenenner/adapter/in/cli/package-info.java | de.gecheckt.pdf.umbenenner.adapter.in.cli |  | 
-pdf-umbenenner-adapter-in-cli/src/main/java/de/gecheckt/pdf/umbenenner/adapter/in/cli/SchedulerBatchCommand.java | de.gecheckt.pdf.umbenenner.adapter.in.cli | class | SchedulerBatchCommand
-pdf-umbenenner-adapter-in-cli/src/test/java/de/gecheckt/pdf/umbenenner/adapter/in/cli/SchedulerBatchCommandTest.java | de.gecheckt.pdf.umbenenner.adapter.in.cli | class | SchedulerBatchCommandTest
-pdf-umbenenner-adapter-out/src/main/java/de/gecheckt/pdf/umbenenner/adapter/out/configuration/package-info.java | de.gecheckt.pdf.umbenenner.adapter.out.configuration |  | 
-pdf-umbenenner-adapter-out/src/main/java/de/gecheckt/pdf/umbenenner/adapter/out/configuration/PropertiesConfigurationPortAdapter.java | de.gecheckt.pdf.umbenenner.adapter.out.configuration | class | PropertiesConfigurationPortAdapter
-pdf-umbenenner-adapter-out/src/main/java/de/gecheckt/pdf/umbenenner/adapter/out/lock/FilesystemRunLockPortAdapter.java | de.gecheckt.pdf.umbenenner.adapter.out.lock | class | FilesystemRunLockPortAdapter
-pdf-umbenenner-adapter-out/src/main/java/de/gecheckt/pdf/umbenenner/adapter/out/lock/package-info.java | de.gecheckt.pdf.umbenenner.adapter.out.lock |  | 
-pdf-umbenenner-adapter-out/src/main/java/de/gecheckt/pdf/umbenenner/adapter/out/package-info.java | de.gecheckt.pdf.umbenenner.adapter.out |  | 
-pdf-umbenenner-adapter-out/src/main/java/de/gecheckt/pdf/umbenenner/adapter/out/pdfextraction/package-info.java | de.gecheckt.pdf.umbenenner.adapter.out.pdfextraction |  | 
-pdf-umbenenner-adapter-out/src/main/java/de/gecheckt/pdf/umbenenner/adapter/out/pdfextraction/PdfTextExtractionPortAdapter.java | de.gecheckt.pdf.umbenenner.adapter.out.pdfextraction | class | PdfTextExtractionPortAdapter
-pdf-umbenenner-adapter-out/src/main/java/de/gecheckt/pdf/umbenenner/adapter/out/sourcedocument/package-info.java | de.gecheckt.pdf.umbenenner.adapter.out.sourcedocument |  | 
-pdf-umbenenner-adapter-out/src/main/java/de/gecheckt/pdf/umbenenner/adapter/out/sourcedocument/SourceDocumentCandidatesPortAdapter.java | de.gecheckt.pdf.umbenenner.adapter.out.sourcedocument | class | SourceDocumentCandidatesPortAdapter
-pdf-umbenenner-adapter-out/src/test/java/de/gecheckt/pdf/umbenenner/adapter/out/configuration/PropertiesConfigurationPortAdapterTest.java | de.gecheckt.pdf.umbenenner.adapter.out.configuration | class | PropertiesConfigurationPortAdapterTest
-pdf-umbenenner-adapter-out/src/test/java/de/gecheckt/pdf/umbenenner/adapter/out/lock/FilesystemRunLockPortAdapterTest.java | de.gecheckt.pdf.umbenenner.adapter.out.lock | class | FilesystemRunLockPortAdapterTest
-pdf-umbenenner-adapter-out/src/test/java/de/gecheckt/pdf/umbenenner/adapter/out/pdfextraction/PdfTextExtractionPortAdapterTest.java | de.gecheckt.pdf.umbenenner.adapter.out.pdfextraction | class | PdfTextExtractionPortAdapterTest
-pdf-umbenenner-adapter-out/src/test/java/de/gecheckt/pdf/umbenenner/adapter/out/sourcedocument/SourceDocumentCandidatesPortAdapterTest.java | de.gecheckt.pdf.umbenenner.adapter.out.sourcedocument | class | SourceDocumentCandidatesPortAdapterTest
-pdf-umbenenner-application/src/main/java/de/gecheckt/pdf/umbenenner/application/config/InvalidStartConfigurationException.java | de.gecheckt.pdf.umbenenner.application.config | class | InvalidStartConfigurationException
-pdf-umbenenner-application/src/main/java/de/gecheckt/pdf/umbenenner/application/config/package-info.java | de.gecheckt.pdf.umbenenner.application.config |  | 
-pdf-umbenenner-application/src/main/java/de/gecheckt/pdf/umbenenner/application/config/StartConfiguration.java | de.gecheckt.pdf.umbenenner.application.config | record | StartConfiguration
-pdf-umbenenner-application/src/main/java/de/gecheckt/pdf/umbenenner/application/config/StartConfigurationValidator.java | de.gecheckt.pdf.umbenenner.application.config | class | StartConfigurationValidator
-pdf-umbenenner-application/src/main/java/de/gecheckt/pdf/umbenenner/application/package-info.java | de.gecheckt.pdf.umbenenner.application |  | 
-pdf-umbenenner-application/src/main/java/de/gecheckt/pdf/umbenenner/application/port/in/BatchRunOutcome.java | de.gecheckt.pdf.umbenenner.application.port.in | enum | BatchRunOutcome
-pdf-umbenenner-application/src/main/java/de/gecheckt/pdf/umbenenner/application/port/in/package-info.java | de.gecheckt.pdf.umbenenner.application.port.in |  | 
-pdf-umbenenner-application/src/main/java/de/gecheckt/pdf/umbenenner/application/port/in/RunBatchProcessingUseCase.java | de.gecheckt.pdf.umbenenner.application.port.in | interface | RunBatchProcessingUseCase
-pdf-umbenenner-application/src/main/java/de/gecheckt/pdf/umbenenner/application/port/out/ClockPort.java | de.gecheckt.pdf.umbenenner.application.port.out | interface | ClockPort
-pdf-umbenenner-application/src/main/java/de/gecheckt/pdf/umbenenner/application/port/out/ConfigurationPort.java | de.gecheckt.pdf.umbenenner.application.port.out | interface | ConfigurationPort
-pdf-umbenenner-application/src/main/java/de/gecheckt/pdf/umbenenner/application/port/out/package-info.java | de.gecheckt.pdf.umbenenner.application.port.out |  | 
-pdf-umbenenner-application/src/main/java/de/gecheckt/pdf/umbenenner/application/port/out/PdfTextExtractionPort.java | de.gecheckt.pdf.umbenenner.application.port.out | interface | PdfTextExtractionPort
-pdf-umbenenner-application/src/main/java/de/gecheckt/pdf/umbenenner/application/port/out/RunLockPort.java | de.gecheckt.pdf.umbenenner.application.port.out | interface | RunLockPort
-pdf-umbenenner-application/src/main/java/de/gecheckt/pdf/umbenenner/application/port/out/RunLockUnavailableException.java | de.gecheckt.pdf.umbenenner.application.port.out | class | RunLockUnavailableException
-pdf-umbenenner-application/src/main/java/de/gecheckt/pdf/umbenenner/application/port/out/SourceDocumentAccessException.java | de.gecheckt.pdf.umbenenner.application.port.out |  | 
-pdf-umbenenner-application/src/main/java/de/gecheckt/pdf/umbenenner/application/port/out/SourceDocumentCandidatesPort.java | de.gecheckt.pdf.umbenenner.application.port.out | interface | SourceDocumentCandidatesPort
-pdf-umbenenner-application/src/main/java/de/gecheckt/pdf/umbenenner/application/service/DocumentProcessingService.java | de.gecheckt.pdf.umbenenner.application.service | class | DocumentProcessingService
-pdf-umbenenner-application/src/main/java/de/gecheckt/pdf/umbenenner/application/service/package-info.java | de.gecheckt.pdf.umbenenner.application.service |  | 
-pdf-umbenenner-application/src/main/java/de/gecheckt/pdf/umbenenner/application/service/PreCheckEvaluator.java | de.gecheckt.pdf.umbenenner.application.service | class | PreCheckEvaluator
-pdf-umbenenner-application/src/main/java/de/gecheckt/pdf/umbenenner/application/usecase/BatchRunProcessingUseCase.java | de.gecheckt.pdf.umbenenner.application.usecase | class | BatchRunProcessingUseCase
-pdf-umbenenner-application/src/main/java/de/gecheckt/pdf/umbenenner/application/usecase/package-info.java | de.gecheckt.pdf.umbenenner.application.usecase |  | 
-pdf-umbenenner-application/src/test/java/de/gecheckt/pdf/umbenenner/application/config/StartConfigurationValidatorTest.java | de.gecheckt.pdf.umbenenner.application.config | class | StartConfigurationValidatorTest
-pdf-umbenenner-application/src/test/java/de/gecheckt/pdf/umbenenner/application/service/DocumentProcessingServiceTest.java | de.gecheckt.pdf.umbenenner.application.service | class | DocumentProcessingServiceTest
-pdf-umbenenner-application/src/test/java/de/gecheckt/pdf/umbenenner/application/service/PreCheckEvaluatorTest.java | de.gecheckt.pdf.umbenenner.application.service | class | PreCheckEvaluatorTest
-pdf-umbenenner-application/src/test/java/de/gecheckt/pdf/umbenenner/application/usecase/BatchRunProcessingUseCaseTest.java | de.gecheckt.pdf.umbenenner.application.usecase | class | BatchRunProcessingUseCaseTest
-pdf-umbenenner-bootstrap/src/main/java/de/gecheckt/pdf/umbenenner/bootstrap/BootstrapRunner.java | de.gecheckt.pdf.umbenenner.bootstrap | class | BootstrapRunner
-pdf-umbenenner-bootstrap/src/main/java/de/gecheckt/pdf/umbenenner/bootstrap/package-info.java | de.gecheckt.pdf.umbenenner.bootstrap |  | 
-pdf-umbenenner-bootstrap/src/main/java/de/gecheckt/pdf/umbenenner/bootstrap/PdfUmbenennerApplication.java | de.gecheckt.pdf.umbenenner.bootstrap | class | PdfUmbenennerApplication
-pdf-umbenenner-bootstrap/src/test/java/de/gecheckt/pdf/umbenenner/bootstrap/BootstrapRunnerTest.java | de.gecheckt.pdf.umbenenner.bootstrap | class | BootstrapRunnerTest
-pdf-umbenenner-bootstrap/src/test/java/de/gecheckt/pdf/umbenenner/bootstrap/ExecutableJarSmokeTestIT.java | de.gecheckt.pdf.umbenenner.bootstrap | class | ExecutableJarSmokeTestIT
-pdf-umbenenner-domain/src/main/java/de/gecheckt/pdf/umbenenner/domain/model/BatchRunContext.java | de.gecheckt.pdf.umbenenner.domain.model |  | 
-pdf-umbenenner-domain/src/main/java/de/gecheckt/pdf/umbenenner/domain/model/DocumentProcessingOutcome.java | de.gecheckt.pdf.umbenenner.domain.model |  | 
-pdf-umbenenner-domain/src/main/java/de/gecheckt/pdf/umbenenner/domain/model/package-info.java | de.gecheckt.pdf.umbenenner.domain.model |  | 
-pdf-umbenenner-domain/src/main/java/de/gecheckt/pdf/umbenenner/domain/model/PdfExtractionContentError.java | de.gecheckt.pdf.umbenenner.domain.model | record | PdfExtractionContentError
-pdf-umbenenner-domain/src/main/java/de/gecheckt/pdf/umbenenner/domain/model/PdfExtractionResult.java | de.gecheckt.pdf.umbenenner.domain.model |  | 
-pdf-umbenenner-domain/src/main/java/de/gecheckt/pdf/umbenenner/domain/model/PdfExtractionSuccess.java | de.gecheckt.pdf.umbenenner.domain.model | record | PdfExtractionSuccess
-pdf-umbenenner-domain/src/main/java/de/gecheckt/pdf/umbenenner/domain/model/PdfExtractionTechnicalError.java | de.gecheckt.pdf.umbenenner.domain.model | record | PdfExtractionTechnicalError
-pdf-umbenenner-domain/src/main/java/de/gecheckt/pdf/umbenenner/domain/model/PdfPageCount.java | de.gecheckt.pdf.umbenenner.domain.model | record | PdfPageCount
-pdf-umbenenner-domain/src/main/java/de/gecheckt/pdf/umbenenner/domain/model/PreCheckFailed.java | de.gecheckt.pdf.umbenenner.domain.model | record | PreCheckFailed
-pdf-umbenenner-domain/src/main/java/de/gecheckt/pdf/umbenenner/domain/model/PreCheckFailureReason.java | de.gecheckt.pdf.umbenenner.domain.model | enum | PreCheckFailureReason
-pdf-umbenenner-domain/src/main/java/de/gecheckt/pdf/umbenenner/domain/model/PreCheckPassed.java | de.gecheckt.pdf.umbenenner.domain.model | record | PreCheckPassed
-pdf-umbenenner-domain/src/main/java/de/gecheckt/pdf/umbenenner/domain/model/ProcessingDecision.java | de.gecheckt.pdf.umbenenner.domain.model |  | 
-pdf-umbenenner-domain/src/main/java/de/gecheckt/pdf/umbenenner/domain/model/ProcessingStatus.java | de.gecheckt.pdf.umbenenner.domain.model | enum | ProcessingStatus
-pdf-umbenenner-domain/src/main/java/de/gecheckt/pdf/umbenenner/domain/model/RunId.java | de.gecheckt.pdf.umbenenner.domain.model |  | 
-pdf-umbenenner-domain/src/main/java/de/gecheckt/pdf/umbenenner/domain/model/SourceDocumentCandidate.java | de.gecheckt.pdf.umbenenner.domain.model | record | SourceDocumentCandidate
-pdf-umbenenner-domain/src/main/java/de/gecheckt/pdf/umbenenner/domain/model/SourceDocumentLocator.java | de.gecheckt.pdf.umbenenner.domain.model | record | SourceDocumentLocator
-pdf-umbenenner-domain/src/main/java/de/gecheckt/pdf/umbenenner/domain/model/TechnicalDocumentError.java | de.gecheckt.pdf.umbenenner.domain.model | record | TechnicalDocumentError
-pdf-umbenenner-domain/src/main/java/de/gecheckt/pdf/umbenenner/domain/package-info.java | de.gecheckt.pdf.umbenenner.domain |  | 
-pdf-umbenenner-domain/src/test/java/de/gecheckt/pdf/umbenenner/domain/model/BatchRunContextTest.java | de.gecheckt.pdf.umbenenner.domain.model | class | BatchRunContextTest
-pdf-umbenenner-domain/src/test/java/de/gecheckt/pdf/umbenenner/domain/model/DocumentProcessingOutcomeTest.java | de.gecheckt.pdf.umbenenner.domain.model | class | DocumentProcessingOutcomeTest
-pdf-umbenenner-domain/src/test/java/de/gecheckt/pdf/umbenenner/domain/model/ProcessingStatusTest.java | de.gecheckt.pdf.umbenenner.domain.model | class | ProcessingStatusTest
-pdf-umbenenner-domain/src/test/java/de/gecheckt/pdf/umbenenner/domain/model/RunIdTest.java | de.gecheckt.pdf.umbenenner.domain.model | class | RunIdTest