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