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

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 <pfad> 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 <pfad>,
  • 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.