# M12 - Arbeitspakete ## Geltungsbereich Dieses Dokument beschreibt ausschließlich die Arbeitspakete für den definierten Meilenstein **M12 – Technische Tests, Korrekturhilfen und Windows-/Netzlaufwerksfähigkeit**. Die Meilensteine **M1** bis **M11** 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 Domain, Application, Adapter, Bootstrap, GUI 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 **M13+**. - Kein Umbau bestehender M1–M11-Strukturen ohne direkten M12-Bezug. - **„Validieren“** und **„Technische Tests ausführen“** arbeiten mit dem **aktuellen GUI-Zustand**, nicht mit dem zuletzt gespeicherten Dateistand. - Es erfolgt **kein implizites Speichern**. - Der Gesamttest läuft **immer vollständig** durch und bricht **nicht** beim ersten Fehler ab. - Schreibende Korrekturen dürfen nur nach **einem gesammelten Bestätigungsdialog** erfolgen. - Netzlaufwerke über **gemappte Laufwerksbuchstaben** sind im Windows-Kontext ausdrücklich zu unterstützen. - Änderungen klein, fokussiert und architekturtreu halten. - Neue Testmodelle, Prüfergebnisse, Korrekturpläne, Ports, Services und GUI-Zustände so schneiden, dass sie aus einem einzelnen Arbeitspaket heraus klar benennbar, testbar und reviewbar sind. ## Explizit nicht Bestandteil von M12 - DB-/Historienanzeige - manueller Verarbeitungslauf aus der GUI - EXE - Installer - neues Konfigurationsformat - neue Provider über Claude und OpenAI-kompatibel hinaus - Cost-Tracking oder Token-/Preisberechnung - mehrseitige GUI oder weitere Tabs - Änderungen an fachlicher Kernverarbeitung, Statussemantik, Retry-Regeln oder Persistenz-Wahrheiten - plattformübergreifende GUI-Unterstützung außerhalb des definierten Windows-Ziels ## Verbindliche M12-Regeln für **alle** Arbeitspakete ### 1. Unterschied zwischen „automatischer Validierung“, Aktion „Validieren“ und „Technische Tests ausführen“ Ab M12 gilt verbindlich: - **Automatische Validierung** bleibt die in M11 definierte Hintergrundprüfung beim Öffnen und während der Bearbeitung. - **Aktion „Validieren“** ist die explizite, **nicht schreibende, lokale Gesamtprüfung** des aktuellen Editorzustands. - **Aktion „Validieren“** arbeitet ohne implizites Speichern und ohne schreibende Korrekturen. - **„Technische Tests ausführen“** ist ein **vollständiger Gesamttest** des aktuellen Editorzustands. - Der Gesamttest darf zusätzlich zu lokalen Prüfungen auch technische Prüfungen gegen Dateisystem und Provider durchführen. - Der Gesamttest darf **korrigierende Maßnahmen** vorschlagen, aber erst nach Bestätigung durchführen. ### 2. Vollständiger Gesamttest ohne Frühabbruch Ab M12 gilt verbindlich: - Der Gesamttest führt **alle definierten Prüfpunkte** aus. - Ein einzelner Fehler darf **nicht** dazu führen, dass spätere Prüfpunkte ausgelassen werden. - Alle Befunde werden gesammelt im zentralen Meldungsbereich ausgegeben. - Die Ausführung basiert auf dem **aktuellen GUI-Zustand**, auch wenn dieser noch ungespeichert ist. ### 3. Definierte Prüfpunkte des Gesamttests Ab M12 gilt verbindlich, dass der Gesamttest mindestens folgende Prüfpunkte unterstützt: - Konfiguration grundsätzlich validierbar - Provider-Konfiguration prüfbar - Base-URL/Endpoint technisch erreichbar - API-Key vorhanden, auch wenn der effektive Wert ausschließlich über eine passende Umgebungsvariable bereitgestellt wird - API-Key technisch akzeptiert - Modellliste abrufbar - ausgewähltes Modell plausibel - Prompt-Datei vorhanden und lesbar - Quellordner vorhanden und lesbar - Zielordner vorhanden oder anlegbar sowie schreibbar - SQLite-Datei bzw. SQLite-Pfad technisch nutzbar ### 4. Schreibende Korrekturhilfen Ab M12 gilt verbindlich: - Schreibende Korrekturen werden **nicht still** durchgeführt. - Vor schreibenden Korrekturen wird **ein gesammelter Bestätigungsdialog** angezeigt. - Nur **sichere technische Korrekturen** dürfen angeboten werden. - Nicht automatisch korrigierbar bleiben insbesondere: - falscher API-Key, - unerreichbare Base-URL, - nicht verfügbare Modellliste, - fachlich unplausible, aber formal zulässige Werte. ### 5. Automatische Prompt-Erzeugung Ab M12 gilt verbindlich: - Wenn die konfigurierte Prompt-Datei fehlt, darf eine **sinnvolle Standard-Prompt-Datei** automatisch erzeugt werden. - Diese Standard-Prompt-Datei ist **deutschsprachig**. - Sie liegt standardmäßig **im selben Ordner wie die `.properties`-Datei**. - Die Erzeugung ist eine **schreibende Korrektur** und unterliegt dem gesammelten Bestätigungsdialog. ### 6. Windows- und Netzlaufwerksfähigkeit Ab M12 gilt verbindlich: - Die GUI und ihre Prüflogik unterstützen ausdrücklich **gemappte Laufwerksbuchstaben** wie `S:\` oder `H:\`. - Solche Pfade dürfen **nicht** allein deshalb abgelehnt oder umgedeutet werden, weil dahinter technisch ein UNC-Pfad stehen könnte. - Maßgeblich ist, dass Windows den Pfad als gültigen Pfad bereitstellt. - Diese Regel gilt mindestens für: - Quellordner, - Zielordner, - SQLite-Datei, - Prompt-Datei. ### 7. Grenzen von M12 M12 liefert die vollständige technische Prüf- und Korrekturunterstützung der V2.0-GUI, aber noch **nicht** den V2.0-Abschluss mit finaler Dokumentation und Gesamtqualitätsnachweis. --- ## AP-001 Prüf- und Korrektur-Kernobjekte, Ergebnissemantik und Port-Verträge präzisieren ### Voraussetzung Keine. Dieses Arbeitspaket ist der M12-Startpunkt. ### Ziel Die M12-relevanten Prüf-, Korrektur- und Dialogmodelle werden eindeutig eingeführt, damit spätere Arbeitspakete ohne Interpretationsspielraum implementiert werden können. ### Muss umgesetzt werden - Neue M12-relevante Typen bzw. GUI-/Application-nahe Modelle anlegen, insbesondere für: - explizite Validierungsanforderung, - Gesamttestanforderung, - Prüfpunktergebnis, - Korrekturvorschlag, - gesammelten Korrekturplan, - Bestätigungsdialog-Inhalt, - schreibenden vs. nicht schreibenden Prüfschritt, - Ergebnis eines vollständigen Gesamttests. - Verträge so schneiden, dass spätere Arbeitspakete unterscheiden können zwischen: - lokalem Validierungsbefund, - technischem Prüfbefund, - korrigierbarem Befund, - nicht korrigierbarem Befund, - bestätigtem Korrekturplan, - abgelehntem Korrekturplan. - Outbound-Ports bzw. Application-Verträge definieren oder schärfen für: - Provider-nahe technische Tests, - Dateisystem-/Pfadtests, - schreibende Korrekturhilfen, - Prompt-Datei-Erzeugung. - Sicherstellen, dass Domain und Application frei von JavaFX-, HTTP-, NIO- und JDBC-Bibliothekstypen bleiben. - JavaDoc und `package-info` für Verantwortlichkeiten und Grenzen ergänzen. ### Explizit nicht Teil - konkrete GUI-Buttons - konkrete Prüflogik - konkrete Korrekturen - Bootstrap-Verdrahtung - Gesamttest-Orchestrierung ### Fertig wenn - die M12-relevanten Typen und Verträge vorhanden sind, - Validieren, Gesamttest und Korrekturplan klar unterscheidbar modelliert sind, - Domain und Application frei von Infrastrukturtypen bleiben, - der Build weiterhin fehlerfrei ist. --- ## AP-002 Aktion „Validieren“ als explizite, nicht schreibende Gesamtprüfung des Editorzustands umsetzen ### Voraussetzung AP-001 ist abgeschlossen. ### Ziel Die GUI bietet eine explizite Validierungsaktion, die den aktuellen Editorzustand lokal und vollständig prüft, ohne etwas zu speichern oder zu verändern. ### Muss umgesetzt werden - Die Aktion **„Validieren“** funktionsfähig anbinden. - Sicherstellen, dass die Aktion mit dem **aktuellen GUI-Zustand** arbeitet, nicht mit dem zuletzt gespeicherten Dateistand. - Keine implizite Speicherung auslösen. - Keine schreibenden Korrekturen durchführen. - Alle lokalen Befunde gesammelt erzeugen und dem vorhandenen Meldungsmodell zuführen. - Relevante feldnahe Fehlermeldungen ergänzen oder schärfen. - Eindeutige deutsche Meldungen für Fehler, Warnungen, Hinweise und Infos verwenden. - Ausführung und Ergebnis der Aktion **„Validieren“** werden im bestehenden Log4j2-Log nachvollziehbar protokolliert. - JavaDoc/Kommentare für die Abgrenzung zur M12-Gesamttestaktion ergänzen. ### Explizit nicht Teil - Provider-nahe Remote-Tests - schreibende Korrekturen - Bestätigungsdialog für Korrekturmaßnahmen - Prompt-Datei-Erzeugung ### Fertig wenn - **„Validieren“** den aktuellen Editorzustand explizit und nicht schreibend prüfen kann, - keine implizite Speicherung stattfindet, - die Befunde verständlich und vollständig angezeigt werden, - der Build weiterhin fehlerfrei ist. --- ## AP-003 Provider-nahe technische Prüflogik für Endpoint, API-Key, Modellliste und Modellplausibilität umsetzen ### Voraussetzung AP-001 und AP-002 sind abgeschlossen. ### Ziel Die für V2.0 geforderten providerbezogenen technischen Prüfpunkte können kontrolliert und providerabhängig ausgeführt werden. ### Muss umgesetzt werden - Die technische Prüflogik für mindestens folgende providerbezogene Prüfpunkte implementieren: - Base-URL/Endpoint erreichbar, - API-Key vorhanden, - API-Key technisch akzeptiert, - Modellliste abrufbar, - ausgewähltes Modell plausibel. - Für den Prüfpunkt **„Modellliste abrufbar“** ausdrücklich denselben Outbound-Port und denselben Adapter verwenden, die bereits in M11 für den Modellabruf eingeführt wurden; der Prüfpunkt ist ein zusätzlicher Aufruf, keine zweite Implementierung. - Die Prüflogik für Claude und OpenAI-kompatibel sauber kapseln. - Beim Prüfpunkt **„API-Key vorhanden“** die bestehende Vorrangregel respektieren, sodass reine Umgebungsvariablen-Setups nicht fälschlich als fehlender API-Key bewertet werden. - Sicherstellen, dass providerbezogene technische Fehler verständlich in das bestehende Meldungsmodell überführt werden. - Sichere Abgrenzung zwischen: - fehlender Voraussetzung, - technischer Unerreichbarkeit, - Authentifizierungsproblem, - nicht verfügbarer Modellliste, - unplausibler Modellauswahl. - Provider-nahe technische Prüfungen und Dateisystem-/SQLite-Prüfungen laufen asynchron; die Ergebnisrückführung in die GUI erfolgt über den JavaFX Application Thread. - Ausführung und Ergebnis der providernahen technischen Prüfpunkte werden im bestehenden Log4j2-Log nachvollziehbar protokolliert. - Keine impliziten Korrekturen durchführen. - JavaDoc/Kommentare für technische Prüfpunkte und Nicht-Ziele ergänzen. ### Explizit nicht Teil - schreibende Korrekturen - Pfad-/Dateisystemtests - Gesamttest-Orchestrierung - Prompt-Datei-Erzeugung ### Fertig wenn - alle providerbezogenen technischen Prüfpunkte separat ausführbar und auswertbar sind, - Befunde verständlich im vorhandenen Meldungsmodell ankommen, - der Build weiterhin fehlerfrei ist. --- ## AP-004 Windows-Pfadprüfung und ausdrückliche Unterstützung gemappter Laufwerke umsetzen ### Voraussetzung AP-001 und AP-002 sind abgeschlossen. ### Ziel Die GUI und ihre Prüflogik behandeln Windows-Pfade einschließlich gemappter Laufwerksbuchstaben korrekt und benutzerfreundlich. ### Muss umgesetzt werden - Pfadprüfungen für folgende Konfigurationswerte vervollständigen: - Quellordner, - Zielordner, - SQLite-Datei, - Prompt-Datei. - Gemappte Laufwerksbuchstaben wie `S:\` oder `H:\` im Windows-Kontext ausdrücklich akzeptieren. - Sicherstellen, dass solche Pfade nicht allein wegen möglicher UNC-Backings abgelehnt oder umgedeutet werden. - Lokale Validierungs- und Testbefunde für Pfadprobleme sauber unterscheiden, insbesondere: - fehlt, - nicht lesbar, - nicht schreibbar, - ungültig, - anlegbar. - JavaDoc/Kommentare für Windows-/Netzlaufwerksfähigkeit und technische Grenzen ergänzen. ### Explizit nicht Teil - schreibende Erstellung fehlender Ressourcen - Prompt-Datei-Erzeugung - Gesamttest-Orchestrierung - Provider-nahe Remote-Tests ### Fertig wenn - Windows-Pfade korrekt validiert werden, - gemappte Laufwerke als gültige Pfade akzeptiert werden, - der Build weiterhin fehlerfrei ist. --- ## AP-005 Aktion „Technische Tests ausführen“ als vollständigen Gesamttest ohne Frühabbruch umsetzen ### Voraussetzung AP-001 bis AP-004 sind abgeschlossen. ### Ziel Die GUI kann einen vollständigen technischen Gesamttest des aktuellen Editorzustands ausführen und alle Befunde gesammelt zurückgeben. ### Muss umgesetzt werden - Die Aktion **„Technische Tests ausführen“** funktionsfähig anbinden. - Sicherstellen, dass sie mit dem **aktuellen GUI-Zustand** arbeitet und nichts implizit speichert. - Die definierten Prüfpunkte vollständig orchestrieren, insbesondere: - Konfiguration grundsätzlich validierbar, - Provider-Konfiguration prüfbar, - Base-URL/Endpoint erreichbar, - API-Key vorhanden, - API-Key technisch akzeptiert, - Modellliste abrufbar, - ausgewähltes Modell plausibel, - Prompt-Datei vorhanden und lesbar, - Quellordner vorhanden und lesbar, - Zielordner vorhanden oder anlegbar sowie schreibbar, - SQLite-Datei bzw. SQLite-Pfad technisch nutzbar. - Sicherstellen, dass der Gesamttest **nicht** beim ersten Fehler abbricht. - Provider-nahe technische Prüfungen und Dateisystem-/SQLite-Prüfungen laufen asynchron; die Ergebnisrückführung in die GUI erfolgt über den JavaFX Application Thread. - Alle Befunde gesammelt und verständlich im zentralen Meldungsbereich ausgeben. - Deutlich kenntlich machen, dass sich das Ergebnis auf den aktuellen Editorzustand bezieht. - Ausführung, Teilresultate und Gesamtergebnis der Aktion **„Technische Tests ausführen“** werden im bestehenden Log4j2-Log nachvollziehbar protokolliert. - JavaDoc/Kommentare zur Gesamttest-Semantik ergänzen. ### Explizit nicht Teil - schreibende Korrekturen - Sammel-Bestätigungsdialog - Prompt-Datei-Erzeugung - Abschlussdokumentation ### Fertig wenn - die Aktion **„Technische Tests ausführen“** vollständig arbeitet, - kein Frühabbruch stattfindet, - alle Befunde gesammelt sichtbar werden, - der Build weiterhin fehlerfrei ist. --- ## AP-006 Schreibende Korrekturhilfen und gesammelten Bestätigungsdialog einführen ### Voraussetzung AP-001 bis AP-005 sind abgeschlossen. ### Ziel Die GUI kann sichere technische Korrekturen gesammelt vorschlagen und nach einmaliger Bestätigung kontrolliert durchführen. ### Muss umgesetzt werden - Einen gesammelten Korrekturplan aus Prüfbefunden ableiten. - Einen einmaligen Bestätigungsdialog implementieren, der die geplanten schreibenden Maßnahmen gesammelt anzeigt. - Nur sichere technische Korrekturen zulassen, insbesondere dort, wo Ressourcen fehlend, aber technisch anlegbar sind. - Sicherstellen, dass ohne Bestätigung keine schreibenden Änderungen ausgeführt werden. - Nach Durchführung die Ergebnisse erneut verständlich in den Meldungsbereich zurückführen. - Schreibende Korrekturen, Bestätigung und Ergebnisrückmeldung werden im bestehenden Log4j2-Log nachvollziehbar protokolliert. - Keine stillen Auto-Korrekturen im Hintergrund zulassen. - JavaDoc/Kommentare für die Korrekturgrenzen ergänzen. ### Explizit nicht Teil - providerbezogene Auto-Heilung - Änderung fachlich riskanter Werte - automatische Lauf-/Verarbeitungsstarts - Abschlussdokumentation ### Fertig wenn - sichere technische Korrekturen gesammelt vorgeschlagen werden können, - genau ein Bestätigungsdialog vor der Ausführung erscheint, - ohne Bestätigung nichts geschrieben wird, - der Build weiterhin fehlerfrei ist. --- ## AP-007 Automatische deutsche Standard-Prompt-Erzeugung und anlegbare Ressourcen vervollständigen ### Voraussetzung AP-001 bis AP-006 sind abgeschlossen. ### Ziel Fehlende, technisch anlegbare Ressourcen können im Rahmen der Korrekturhilfen sinnvoll hergestellt werden; insbesondere kann eine fehlende Prompt-Datei automatisch als deutsche Standarddatei erzeugt werden. ### Muss umgesetzt werden - Die automatische Erzeugung einer sinnvollen **deutschsprachigen Standard-Prompt-Datei** implementieren. - Sicherstellen, dass diese standardmäßig **im selben Ordner wie die `.properties`-Datei** angelegt wird. - Die Erzeugung nur dann als Korrekturmaßnahme anbieten, wenn der vorgesehene Zielpfad tatsächlich beschreibbar ist. - Wenn der Standardpfad nicht beschreibbar ist, im Bestätigungsdialog entweder einen alternativen Ablageort vorschlagen oder die Erzeugung ausdrücklich als **„nicht möglich, bitte manuell anlegen“** melden. - Die Erzeugung in den Korrekturplan und Bestätigungsdialog aus AP-006 integrieren. - Weitere sichere technische Korrekturen für anlegbare Ressourcen dort ergänzen, wo sie für V2.0 explizit gefordert sind, insbesondere: - Zielordner anlegen, - SQLite-Datei bzw. nutzbaren SQLite-Pfad vorbereiten, - Prompt-Datei anlegen. - Verständliche deutsche Meldungen für Erfolg, Teilfehler und Nichtdurchführbarkeit bereitstellen. - Prompt-Erzeugung, Ressourcenkorrekturen und deren Ergebnisse werden im bestehenden Log4j2-Log nachvollziehbar protokolliert. - JavaDoc/Kommentare für Prompt-Generierung und Ressourcenkorrektur ergänzen. ### Explizit nicht Teil - fachliche Prompt-Evolution über die Standarddatei hinaus - manuelle Prompt-Bearbeitung in Spezialansichten - neue Betriebsfeatures - Abschlussdokumentation ### Fertig wenn - die Standard-Prompt-Datei automatisch erzeugt werden kann, - die Erzeugung sauber in den Korrekturplan integriert ist, - weitere sichere technische Ressourcenkorrekturen funktionieren, - der Build weiterhin fehlerfrei ist. --- ## AP-008 Tests für Gesamttest, Korrekturdialog, Prompt-Erzeugung und Netzlaufwerksfähigkeit ergänzen ### Voraussetzung AP-001 bis AP-007 sind abgeschlossen. ### Ziel Der vollständige M12-Zielzustand wird automatisiert abgesichert und als konsistenter Übergabestand nachgewiesen. ### Muss umgesetzt werden - Tests für **„Validieren“** mit aktuellem, ungespeichertem Editorzustand ergänzen. - Tests für **„Technische Tests ausführen“** ohne Frühabbruch ergänzen. - Tests für providerbezogene technische Prüfpunkte ergänzen, soweit innerhalb von M12 sinnvoll und stabil automatisierbar. - Tests für den gesammelten Bestätigungsdialog ergänzen. - Tests für sichere technische Korrekturen ergänzen. - Tests für automatische Prompt-Erzeugung ergänzen. - Tests für Windows-/Netzlaufwerksannahmen ergänzen, insbesondere dafür, dass gemappte Laufwerksbuchstaben korrekt akzeptiert werden. - Sicherstellen, dass der definierte M12-Zielzustand vollständig buildbar und übergabefähig ist. ### Explizit nicht Teil - Abschlussdokumentation des Gesamtprojekts - GUI-Erweiterungen aus M13+ - DB-/Historienanzeige - manueller Verarbeitungslauf ### Fertig wenn - die M12-spezifische Test-Suite grün ist, - Gesamttest, Korrekturhilfen und Netzlaufwerksfähigkeit automatisiert abgesichert sind, - ein fehlerfreier, übergabefähiger Stand vorliegt. --- ## Abschlussbewertung Die Arbeitspakete sind inhaltlich konsistent, widerspruchsfrei und sauber auf den Meilenstein **M12 – Technische Tests, Korrekturhilfen und Windows-/Netzlaufwerksfähigkeit** zugeschnitten. Sie decken den vollständigen Zielumfang dieses Meilensteins ab, ohne spätere Ausbaustufen vorwegzunehmen.