# 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
- Die bestehende Betriebsdokumentation **`betrieb.md`** sowie ggf. vorhandene README-Dateien gezielt auf den V2.0-Stand erweitern.
- Mindestens folgende Punkte klar und konsistent dokumentieren:
  - gemeinsames ausführbares JAR,
  - GUI als Standardstart,
  - `--headless`,
  - `--config <pfad>`,
  - 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 Endbenutzer-Bedienanleitung der V2.0-GUI erstellen

### Voraussetzung
AP-001 ist abgeschlossen.

### Ziel
Die V2.0-GUI erhält eine eigenständige, deskriptive Bedienanleitung, die dem Endbenutzer alle GUI-Funktionen, Zustände und Verhaltensweisen verständlich erklärt.

### Muss umgesetzt werden
- Eine neue Datei **`gui-bedienanleitung.md`** neben `betrieb.md` anlegen.
- Der Inhalt ist **deskriptiv** (beschreibend), nicht als Schritt-für-Schritt-Tutorial.
- Mindestens folgende Themen abdecken:
  - Startzustände (GUI-Standardstart, Willkommenstext, Start mit `--config`),
  - Aktionen: **Neu**, **Öffnen**, **Speichern**, **Speichern unter**, **Validieren**, **Technische Tests ausführen**, **Modelle neu laden**,
  - Bedeutung der vier Meldungsstufen (Info, Hinweis, Warnung, Fehler),
  - feldnahe Fehlermeldungen,
  - Provider-Bedienung und Modellabruf,
  - API-Key-Auflösungsreihenfolge mit Vorrang der Umgebungsvariable,
  - Dirty-State und Schutzdialoge,
  - `.bak`-Sicherung beim Überschreiben und Legacy-Migration,
  - Windows-Hinweise zu gemappten Laufwerken,
  - bekannte Einschränkungen: kein manueller Verarbeitungslauf in V2.0, keine Erkennung externer Änderungen an der `.properties`-Datei, keine Koordination mit parallelen headless Läufen.
- Die Anleitung so schneiden, dass sie zum realen V2.0-Verhalten der GUI passt.
- Terminologie zwischen Bedienanleitung, `betrieb.md`, GUI-Texten und Meilensteinbeschreibungen vereinheitlichen.

### Explizit nicht Teil
- Betriebsdokumentation (bleibt in `betrieb.md`)
- technische Entwicklerdokumentation
- Release-Befundliste
- Freigabedokument

### Fertig wenn
- `gui-bedienanleitung.md` im Repository vorliegt,
- alle definierten Themen deskriptiv abgedeckt sind,
- die Terminologie mit `betrieb.md` und den GUI-Texten konsistent ist,
- der Build weiterhin fehlerfrei ist.

---

## AP-003 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.
- 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-004 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.
- 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-005 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-006 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-007 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 als neuen V2.0-Abschnitt in der bestehenden **`befundliste.md`** 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-008 Nachgewiesene V2.0-Release-Blocker gezielt beheben

### Voraussetzung
AP-007 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-007 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-009 Finale V2.0-Gesamtprüfung und Freigabedokumentation erstellen

### Voraussetzung
AP-008 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.
- Endbenutzer-Bedienanleitung (`gui-bedienanleitung.md`) auf Vollständigkeit, Konsistenz mit `betrieb.md` und Übereinstimmung mit dem realen GUI-Verhalten prüfen.
- 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.
