# M13 - Arbeitspakete ## Geltungsbereich Dieses Dokument beschreibt ausschließlich die Arbeitspakete für den definierten Meilenstein **M13 – V2.0-Abschluss, Dokumentation und Qualitätsnachweis**. Die Meilensteine **M1** bis **M12** sowie der dokumentierte Ist-Stand **V1.1** werden als vollständig umgesetzt und freigegeben 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 Dokumentation, Build, Bootstrap, GUI, CLI, Konfigurationsbeispiele und Tests ändern. - Keine Annahmen treffen, die nicht durch die bestehenden Spezifikationen, den dokumentierten V1.1-Ist-Stand, `meilensteine-v2_0.md` oder dieses Dokument gedeckt sind. - Kein Vorgriff auf spätere Ausbaustufen **jenseits von V2.0**. - Kein Umbau bestehender M1–M12-Strukturen ohne direkten M13-Bezug. - M13 ergänzt **keine neue Produktfunktionalität**, sondern dokumentiert, stabilisiert und belegt den bereits definierten V2.0-Gesamtstand. - GUI und headless bleiben **ein gemeinsames ausführbares JAR**; M13 erfindet keine neue Distributionsform. - Der bestehende **headless Server-/Scheduler-Betrieb** darf weder technisch noch dokumentarisch still gebrochen werden. - Änderungen klein, fokussiert und architekturtreu halten. - Ein Arbeitspaket darf nur dann einen Release-Blocker beheben, wenn dieser im unmittelbar vorhergehenden Prüf-Arbeitspaket **konkret nachgewiesen und eingegrenzt** wurde. ## Explizit nicht Bestandteil von M13 - DB-/Historienanzeige - manueller Verarbeitungslauf aus der GUI - EXE - Installer - neues Konfigurationsformat - neue Provider über Claude und OpenAI-kompatibel hinaus - Cost-Tracking oder Token-/Preisberechnung - neue Tabs oder größere GUI-Ausbaustufen jenseits des vorhandenen V2.0-Umfangs - neue fachliche Regeln für Dateinamensbildung, Retry, Persistenz oder Laufverhalten - plattformübergreifender offizieller GUI-Support außerhalb des definierten Windows-Ziels ## Verbindliche M13-Regeln für **alle** Arbeitspakete ### 1. M13 ist ein Abschluss- und Nachweismeilenstein Ab M13 gilt verbindlich: - Der funktionale V2.0-Umfang wird **nicht erweitert**, sondern für Betrieb, Übergabe und Freigabe abgesichert. - Änderungen in Produktionscode sind nur zulässig, wenn sie für: - dokumentierte Start-/Betriebssemantik, - belastbare Tests, - Packaging-Stabilität, - oder konkret nachgewiesene Release-Blocker zwingend erforderlich sind. ### 2. GUI und headless müssen gemeinsam und widerspruchsfrei beschrieben sein Ab M13 gilt verbindlich: - Die Dokumentation beschreibt den gemeinsamen Betrieb eines **einzigen ausführbaren JARs**. - **GUI ist Standardstart**. - **`--headless`** aktiviert den bisherigen Batch-/Scheduler-Betrieb. - **`--config `** gilt für GUI und headless. - Verhalten bei ungültigem oder nicht vorhandenem `--config` muss für beide Startarten klar dokumentiert und testbar belegt sein. ### 3. `.properties` bleibt die einzige Konfigurationswahrheit Ab M13 gilt verbindlich: - Dokumentation, Konfigurationsbeispiele, GUI-Verhalten und headless Betrieb verwenden weiterhin dieselbe `.properties`-Struktur. - M13 führt keine zweite Konfigurationswelt für GUI oder headless ein. - Prompt-Datei und Properties-Datei bleiben getrennte Artefakte; die Prompt-Datei bleibt externe Datei. ### 4. Headless-Abwärtskompatibilität ist release-kritisch Ab M13 gilt verbindlich: - Bestehender headless Betrieb ohne GUI-Einsatz bleibt lauffähig. - Headless darf keine separate JavaFX-Installation voraussetzen. - Bestehendes Default-Verhalten für headless Starts **ohne `--config`** bleibt erhalten. - Regressionen im bisherigen Server-/Scheduler-Betrieb gelten in M13 als **Release-Blocker**. ### 5. Windows-zentrierte GUI-Dokumentation Ab M13 gilt verbindlich: - Die GUI wird für **Windows** dokumentiert. - Windows-spezifische Pfade und gemappte Laufwerke bleiben Teil des Zielbilds. - Dokumentation und Beispiele dürfen diese Pfadrealität nicht still relativieren oder auf UNC-only reduzieren. ### 6. Qualitätsnachweis basiert auf real ausgeführten Prüfungen Ab M13 gilt verbindlich: - Ein V2.0-Freigabestand wird nur auf Basis **real ausgeführter Builds und Tests** beschrieben. - Prüf- und Freigabedokumente müssen den tatsächlich ausgeführten Stand wiedergeben. - Reine Absichtserklärungen ohne realen Nachweis sind für M13 unzureichend. ### 7. Release-Blocker und finale Freigabe sind getrennte Schritte Ab M13 gilt verbindlich: - Zuerst wird eine **Befundliste** mit konkret eingegrenzten Restthemen erstellt. - Danach dürfen nur die dokumentierten Release-Blocker gezielt behoben werden. - Erst danach erfolgt eine finale Gesamtprüfung und Freigabedokumentation. --- ## AP-001 V2.0-Betriebs- und Startdokumentation für GUI und headless konsolidieren ### Voraussetzung Keine. Dieses Arbeitspaket ist der M13-Startpunkt. ### Ziel Der V2.0-Betrieb wird für Benutzer und Betreiber klar, widerspruchsfrei und vollständig beschrieben. ### Muss umgesetzt werden - README bzw. vorhandene Start-/Betriebsdokumentation gezielt auf den V2.0-Stand erweitern. - Mindestens folgende Punkte klar und konsistent dokumentieren: - gemeinsames ausführbares JAR, - GUI als Standardstart, - `--headless`, - `--config `, - Exit-Code-Modell von V2.0 mit `0` für normale erfolgreiche GUI-/headless-Beendigung und `1` für harte Start-, Bootstrap-, Konfigurations- oder Initialisierungsfehler, - Verhalten bei fehlender oder ungültiger Konfiguration, - Verhalten bei GUI-Startfehlern, - Windows-Bezug und gemappte Laufwerke. - Dokumentieren, dass V2.0 **keinen** manuellen Verarbeitungslauf aus der GUI enthält. - Dokumentieren, dass die GUI in V2.0 der Konfiguration, Validierung und technischen Prüfung dient. - Terminologie zwischen README, JavaDoc, GUI-Texten und Startsemantik vereinheitlichen. ### Explizit nicht Teil - neue Produktfunktionalität - vollständige Testergänzung - Release-Blocker-Befundliste - Freigabedokument ### Fertig wenn - der V2.0-Betrieb für GUI und headless klar dokumentiert ist, - die Startoptionen widerspruchsfrei beschrieben sind, - die Dokumentation zum realen Verhalten des aktuellen Codes passt, - der Build weiterhin fehlerfrei ist. --- ## AP-002 Konfigurationsbeispiele, Standardvorlage und Prompt-Bezug für den V2.0-Endstand konsolidieren ### Voraussetzung AP-001 ist abgeschlossen. ### Ziel Die im Repository enthaltenen Konfigurations- und Prompt-Beispiele passen konsistent zum realen V2.0-Verhalten der GUI und des headless Betriebs. ### Muss umgesetzt werden - Vorhandene Konfigurationsbeispiele prüfen und auf den V2.0-Stand bringen. - Sicherstellen, dass mindestens nachvollziehbar und konsistent abgebildet sind: - mehrere Provider-Konfigurationen in einer Datei, - genau ein aktiver Provider, - GUI-relevante und headless-relevante Konfigurationswerte, - `prompt.template.file`, - konservative Default-Werte, - V2.0-relevante Grenz- und Warnparameter. - Die Standardvorlage für **„Neue Konfiguration“** und die dokumentierten Konfigurationsbeispiele semantisch aufeinander abstimmen. - Sicherstellen, dass die Dokumentation den gemeinsamen Standardpfad `config/application.properties` relativ zum Arbeitsverzeichnis konsistent beschreibt, wo dies für GUI-Speichervorschläge und headless Standardverhalten relevant ist. - Den Umgang mit `.bak`-Sicherungen beim Überschreiben bestehender `.properties`-Dateien konsistent dokumentieren. - Den Umgang mit automatisch erzeugbarer deutscher Standard-Prompt-Datei dokumentieren. - Sicherstellen, dass Dateinamen, Pfadbeispiele und Properties-Namen zum tatsächlichen Code passen. ### Explizit nicht Teil - neue GUI-Funktionalität - größere Prompt-Überarbeitung jenseits des dokumentierten Standardfalls - Release-Befundliste - Freigabedokument ### Fertig wenn - Konfigurationsbeispiele und Standardvorlage konsistent zum V2.0-Stand sind, - Prompt-Bezug und automatische Prompt-Erzeugung nachvollziehbar beschrieben sind, - Properties-Namen und Beispielwerte zum realen Code passen, - der Build weiterhin fehlerfrei ist. --- ## AP-003 Regressionstests für headless Abwärtskompatibilität, Startoptionen und Konfigurationspfade ergänzen ### Voraussetzung AP-001 und AP-002 sind abgeschlossen. ### Ziel Die kritischen V2.0-Risiken im bisherigen Server-/Scheduler-Betrieb werden automatisiert abgesichert. ### Muss umgesetzt werden - Regressionstests für den headless Betrieb ergänzen oder vervollständigen, insbesondere für: - headless Start ohne `--config` mit bestehendem Default-Verhalten, - headless Start mit gültigem `--config`, - headless Start mit ungültigem bzw. nicht vorhandenem `--config` als harter Startfehler, - keine unzulässige Abhängigkeit von separater JavaFX-Installation im headless Pfad. - Tests für Parsing und Semantik von `--headless` und `--config` ergänzen. - Tests für das verbindliche Exit-Code-Modell im headless Pfad ergänzen, soweit dies stabil automatisierbar ist. - Sicherstellen, dass bestehender Batch-/Scheduler-Betrieb durch V2.0 nicht still verändert wird. - Relevante Start- und Fehlermeldungssemantik mit absichern, soweit dies stabil automatisierbar ist. ### Explizit nicht Teil - GUI-interaktive Bedienpfade - Release-Befundliste - Freigabedokument - neue Produktfunktionalität ### Fertig wenn - die headless Abwärtskompatibilität belastbar automatisiert abgesichert ist, - Startoptionen und Konfigurationspfade regressionssicher geprüft werden, - der Build weiterhin fehlerfrei ist. --- ## AP-004 GUI-Smoke- und Interaktionstests für den V2.0-Kernumfang vervollständigen ### Voraussetzung AP-001 bis AP-003 sind abgeschlossen. ### Ziel Die zentralen V2.0-GUI-Pfade sind automatisiert so abgesichert, dass Bedienung, Startzustände und wichtige Fehlersituationen regressionssicher werden. ### Muss umgesetzt werden - GUI-nahe Tests für die zentralen V2.0-Bedienpfade ergänzen oder vervollständigen, insbesondere für: - leerer GUI-Start ohne geladene Konfiguration, - Willkommenstext und sichtbare Grundaktionen, - `--config` im GUI-Start mit gültiger Datei, - `--config` im GUI-Start mit nicht vorhandener Datei inklusive Fehlermeldung und Fallback auf leeren GUI-Zustand, - Dirty-State-Kennzeichnung, - Schutzdialoge bei ungespeicherten Änderungen, - Arbeiten von **„Validieren“** und **„Technische Tests ausführen“** auf dem aktuellen Editorzustand. - Soweit stabil automatisierbar, auch zentrale Meldungs- und Validierungsflüsse mit absichern. - Sicherstellen, dass die Tests den echten V2.0-Kernumfang prüfen und keine späteren GUI-Ausbaustufen vorwegnehmen. ### Explizit nicht Teil - DB-/Historienansicht - manueller Verarbeitungslauf - Release-Befundliste - Freigabedokument ### Fertig wenn - die zentralen V2.0-GUI-Pfade automatisiert abgesichert sind, - GUI-Start, Fallback-Verhalten und Schutzdialoge regressionssicher geprüft werden, - der Build weiterhin fehlerfrei ist. --- ## AP-005 Build-, Packaging- und Artefaktdokumentation für das gemeinsame V2.0-JAR vervollständigen ### Voraussetzung AP-001 bis AP-004 sind abgeschlossen. ### Ziel Das gemeinsame ausführbare JAR für GUI und headless ist nachvollziehbar beschrieben und sein Build-/Packaging-Verhalten ist für die Übergabe ausreichend dokumentiert. ### Muss umgesetzt werden - Dokumentation für Build und Packaging des gemeinsamen V2.0-JAR ergänzen oder schärfen. - Mindestens folgende Punkte nachvollziehbar beschreiben: - gemeinsames ausführbares JAR, - integrierte JavaFX-Laufzeit im GUI-Fall, - keine EXE und kein Installer in V2.0, - headless Start ohne separate JavaFX-Installation, - relevante Build-Kommandos, - Artefakterzeugung und Startbeispiele. - Prüfen, ob bestehende Packaging-/Build-Hinweise oder Konfigurationsbeispiele widersprüchlich oder veraltet sind, und diese gezielt bereinigen. - Nur dann produktiven Build-Code anfassen, wenn für eine korrekte V2.0-Dokumentation ein nachweisbarer Widerspruch zum realen Packaging-Verhalten besteht. ### Explizit nicht Teil - neue Distributionsformate - EXE oder Installer - Release-Befundliste - Freigabedokument ### Fertig wenn - Build- und Packaging-Verhalten des gemeinsamen JAR nachvollziehbar dokumentiert ist, - veraltete oder widersprüchliche Angaben bereinigt sind, - der Build weiterhin fehlerfrei ist. --- ## AP-006 Integrierte Gesamtprüfung des V2.0-Stands und belastbare Befundliste erstellen ### Voraussetzung AP-001 bis AP-005 sind abgeschlossen. ### Ziel Der V2.0-Gesamtstand wird ganzheitlich geprüft, und es entsteht eine belastbare Befundliste, aus der ausschließlich reale Release-Blocker ableitbar sind. ### Muss umgesetzt werden - Den vollständigen V2.0-Projektstand ganzheitlich gegen die bestehenden Spezifikationen, den V1.1-Ist-Stand und `meilensteine-v2_0.md` prüfen. - Tatsächlich ausführen und auswerten: - vollständigen Maven-Reactor-Build, - relevante Test-Suiten, - headless Smoke-/Regressionstests, - GUI-nahe Smoke-/Interaktionstests, soweit im Projekt vorhanden, - Prüfung der Konfigurations- und Dokumentationsbeispiele. - Die Ergebnisse in einer im Repository verbleibenden **Befundliste** dokumentieren. - Befunde klar klassifizieren, insbesondere in: - Release-Blocker, - nicht blockierende Restpunkte, - bewusst außerhalb von V2.0 liegende Themen. - Sicherstellen, dass nur **konkret nachgewiesene** Release-Blocker für das Folge-Arbeitspaket in Betracht kommen. ### Explizit nicht Teil - Behebung der gefundenen Blocker - neue Produktfunktionalität - finale Freigabedokumentation ### Fertig wenn - die integrierte Gesamtprüfung real durchgeführt und dokumentiert wurde, - eine belastbare Befundliste im Repository vorliegt, - Release-Blocker klar und eng eingegrenzt sind, - der Stand weiterhin fehlerfrei buildbar bleibt. --- ## AP-007 Nachgewiesene V2.0-Release-Blocker gezielt beheben ### Voraussetzung AP-006 ist abgeschlossen. ### Ziel Die im vorherigen Arbeitspaket konkret dokumentierten Release-Blocker werden gezielt und ohne Scope-Ausweitung beseitigt. ### Muss umgesetzt werden - Ausschließlich die in der Befundliste aus AP-006 dokumentierten **Release-Blocker** beheben. - Änderungen strikt auf die tatsächlich nachgewiesenen Blocker begrenzen. - Betroffene Tests, Dokumentation und Konfigurationsbeispiele mitziehen, soweit dies zur sauberen Behebung erforderlich ist. - Sicherstellen, dass durch die Behebung keine Themen späterer Ausbaustufen still vorweggenommen werden. - Den relevanten Build-/Testumfang erneut ausführen und grün bekommen. ### Explizit nicht Teil - Behebung nicht blockierender Restpunkte - neue Features - finaler Freigabenachweis ### Fertig wenn - die dokumentierten Release-Blocker gezielt behoben sind, - die relevanten Builds und Tests erneut erfolgreich laufen, - keine Scope-Ausweitung auf spätere Ausbaustufen stattgefunden hat, - ein fehlerfreier, übergabefähiger Stand vorliegt. --- ## AP-008 Finale V2.0-Gesamtprüfung und Freigabedokumentation erstellen ### Voraussetzung AP-007 ist abgeschlossen. ### Ziel Der V2.0-Gesamtstand wird abschließend geprüft und als freigabefähiger Stand nachvollziehbar dokumentiert. ### Muss umgesetzt werden - Die integrierte Gesamtprüfung nach den Blockerbehebungen erneut durchführen. - Tatsächlich ausführen und bewerten: - vollständigen Maven-Reactor-Build, - maßgebliche Test-Suiten, - headless Smoke-/Regressionstests, - GUI-nahe Smoke-/Interaktionstests, - Konfigurations- und Dokumentationsbeispielprüfung. - Eine im Repository verbleibende **Freigabedokumentation** erstellen, die mindestens festhält: - geprüften Stand, - ausgeführte Prüfungen, - Build-/Test-Ergebnisse, - offene nicht blockierende Restpunkte, - klare Freigabeaussage für V2.0. - Sicherstellen, dass die Freigabedokumentation keine Aussagen trifft, die nicht durch reale Prüfungen gedeckt sind. ### Explizit nicht Teil - neue Produktfunktionalität - weitere Qualitätskampagnen jenseits des V2.0-Abschlusses - spätere Ausbaustufen V2.1+ ### Fertig wenn - der V2.0-Gesamtstand erneut vollständig geprüft wurde, - eine belastbare Freigabedokumentation im Repository vorliegt, - der V2.0-Stand als freigabefähig nachvollziehbar beschrieben ist, - ein fehlerfreier, übergabefähiger Abschlussstand vorliegt. --- ## Abschlussbewertung Die Arbeitspakete sind inhaltlich konsistent, widerspruchsfrei und sauber auf den Meilenstein **M13 – V2.0-Abschluss, Dokumentation und Qualitätsnachweis** zugeschnitten. Sie decken den vollständigen Zielumfang dieses Abschlussmeilensteins ab, ohne spätere Ausbaustufen vorwegzunehmen.