diff --git a/.gitignore b/.gitignore index dd207db..cb1404e 100644 --- a/.gitignore +++ b/.gitignore @@ -72,3 +72,4 @@ Desktop.ini hs_err_pid* replay_pid* /review-input.zip +/run-milestone.ps1 diff --git a/CLAUDE.md b/CLAUDE.md index 5a034ca..2e967f7 100644 --- a/CLAUDE.md +++ b/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 -Lücke zwischen dem M6-Erfolgspfad und dem final robusten Endstand. +M1 bis M7 sind vollständig abgeschlossen. Der aktive Stand ist der **Abschlussmeilenstein**: +Qualitätssicherung, Feinschliff und vollständige Entwicklungsfreigabe des Gesamtstands. -### Baseline aus M6 -- Technische Dateinamensbildung im Format `YYYY-MM-DD - Titel.pdf` -- Dublettenbehandlung im Zielordner: `(1)`, `(2)`, … -- Physische Zielkopie via temporäre Datei und finalem Move/Rename -- Schemaevolution M5 → M6 (Zielpfad, Zieldateiname in Stammsatz und Versuchshistorie) -- Statustransition `PROPOSAL_READY` → `SUCCESS` -- Zusätzliche Historisierung für Enderfolg und technische Fehler -- Startvalidierung für Zielordner-Konfiguration (`target.folder`) +### Baseline aus M7 +- Vollständige laufübergreifende Retry-Logik (deterministisch + transient) +- Technischer Sofort-Wiederholversuch für Zielkopierfehler +- Finalisierung ausgeschöpfter Retry-Rahmen zu `FAILED_FINAL` +- Vollständige Skip-Semantik (`SUCCESS`, `FAILED_FINAL`) +- Logging-Mindestumfang vollständig angebunden +- Sensibilitätsregel für KI-Inhalte im Logging +- 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 -- Technischer Sofort-Wiederholversuch ausschließlich für Zielkopierfehler (genau ein zusätzlicher Versuch im selben Lauf) -- Finalisierung ausgeschöpfter Retry-Rahmen zu `FAILED_FINAL` -- Vollständige Skip-Semantik: `SUCCESS` und `FAILED_FINAL` werden historisiert übersprungen -- Logging-Mindestumfang des Endstands vollständig angebunden -- Sensibilitätsregel für KI-Inhalte im Logging -- Vervollständigte Startvalidierung und finale Exit-Code-Semantik +M8 schließt **ausschließlich nachweisbare Restlücken** des aus M1–M7 entstandenen Gesamtstands: +- Architekturgrenzen und code-nahe Dokumentation finalisieren +- Status-, Persistenz- und Zielzustandskonsistenz bereinigen +- Betreiberrelevante Logging-, Fehlertext- und Startvalidierungsrückmeldungen schärfen +- Konfigurationsbeispiele, Prompt-Bezug und Betriebsdokumentation konsolidieren +- Deterministische End-to-End-Testbasis bereitstellen +- 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. diff --git a/docs/workpackages/M8 - Arbeitspakete.md b/docs/workpackages/M8 - Arbeitspakete.md new file mode 100644 index 0000000..d2fbb6e --- /dev/null +++ b/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. diff --git a/java-packages-inventory.txt b/java-packages-inventory.txt deleted file mode 100644 index 7dcef15..0000000 --- a/java-packages-inventory.txt +++ /dev/null @@ -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