pdf-umbenenner/docs/workpackages/M8 - Arbeitspakete.md

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.