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