diff --git a/docs/workpackages/M10 - Arbeitspakete.md b/docs/workpackages/M10 - Arbeitspakete.md index c2a288b..5110b89 100644 --- a/docs/workpackages/M10 - Arbeitspakete.md +++ b/docs/workpackages/M10 - Arbeitspakete.md @@ -27,7 +27,7 @@ Die Reihenfolge der Arbeitspakete ist verbindlich. ## Explizit nicht Bestandteil von M10 -- sofortige Validierung beim Öffnen oder während der Eingabe +- automatische Validierung beim Öffnen oder während der Eingabe - zentraler Meldungsbereich mit Info/Hinweis/Warnung/Fehler - feldnahe rote Fehlermeldungen unter Eingabefeldern - Provider-ComboBox @@ -81,9 +81,8 @@ Ab M10 gilt verbindlich: - **„Öffnen“** und **„Speichern unter“** filtern auf **`*.properties`**. - **„Speichern“** verhält sich bei einer neuen, noch nie gespeicherten Konfiguration wie **„Speichern unter“**. -- **„Speichern unter“** schlägt standardmäßig denselben Standardpfad vor, den der bestehende headless Betrieb in V1.1 verwendet, also **`config/application.properties`** relativ zum Arbeitsverzeichnis. Dadurch ist die in der GUI gespeicherte Datei ohne weitere Schritte für den nächsten headless Scheduler-Lauf nutzbar. +- **„Speichern unter“** schlägt standardmäßig **`pdf-umbenenner.properties`** vor. - Beim Speichern auf eine bereits existierende Datei erscheint eine klare Rückfrage **„Datei überschreiben?“**. -- Vor dem Überschreiben einer bestehenden `.properties`-Datei legt die GUI eine `.bak`-Sicherung im selben Schema wie der bestehende V1.1-Migrationspfad an (**`.bak`**, bei Kollision **`.bak.1`**, **`.bak.2`**, …). ### 5. Editorzustand und ungespeicherte Änderungen @@ -226,7 +225,7 @@ Bestehende Konfigurationsdateien können über den GUI-Dateidialog geladen und i ### Muss umgesetzt werden - Native Dateiauswahl für **„Öffnen“** mit Filter auf **`*.properties`** implementieren. - Bestehende `.properties`-Datei technisch laden und in den Editorzustand überführen. -- Beim Öffnen einer erkannten Legacy-Konfiguration aus Vor-V1.1 die bestehende Migrationslogik des headless Pfads wiederverwenden; die GUI führt keinen zweiten, separaten Migrationspfad ein. +- Die durchgeführte Legacy-Migration im Editorzustand als ausstehende Migrationsmeldung festhalten, sodass der in M11 eingeführte zentrale Meldungsbereich diese Meldung beim Anbinden automatisch anzeigen kann. In M10 selbst erscheint noch kein sichtbarer Migrationshinweis. - Sicherstellen, dass die Dateiübernahme mit dem aus M9 bereits vorhandenen GUI-Start über gültiges `--config ` zusammenarbeiten kann. - Header-Anzeige nach erfolgreichem Laden auf den vollständigen Pfad aktualisieren. - Fehlersituationen beim Laden kontrolliert behandeln, soweit für M10 nötig. @@ -260,10 +259,9 @@ Der Editor kann neue und bestehende Konfigurationen zuverlässig, normalisiert u - Schreiblogik für bestehende und neue Konfigurationen implementieren. - **„Speichern“** für bereits bekannte Dateipfade umsetzen. - **„Speichern“** für neue, noch nie gespeicherte Konfigurationen wie **„Speichern unter“** behandeln. -- **„Speichern unter“** mit Vorschlag desselben Standardpfads implementieren, den der bestehende headless Betrieb in V1.1 verwendet, also **`config/application.properties`** relativ zum Arbeitsverzeichnis. +- **„Speichern unter“** mit Vorschlag **`pdf-umbenenner.properties`** implementieren. - Dialogfilter auf **`*.properties`** anwenden. - Rückfrage **„Datei überschreiben?“** bei existierender Zieldatei umsetzen. -- Vor dem Überschreiben einer bestehenden `.properties`-Datei eine `.bak`-Sicherung im selben Schema wie der bestehende V1.1-Migrationspfad anlegen (**`.bak`**, bei Kollision **`.bak.1`**, **`.bak.2`**, …); diese Sicherung ist verbindlicher Teil der Speicherlogik. - Speicherung als normalisierte `.properties` sicherstellen. - Für API-Key-Felder sicherstellen, dass ein leeres GUI-Feld einen bereits vorhandenen Property-Wert nicht stillschweigend entfernt; stattdessen muss ein kontrolliertes Ergebnis für die spätere Warnanzeige aus M11/M12 bereitstehen. - Header-Pfad nach erfolgreichem Erstspeichern bzw. Speichern unter korrekt fortschreiben. @@ -371,10 +369,8 @@ Der vollständige M10-Datei- und Editorfluss wird integriert abgesichert, einsch - GUI-Start ohne geladene Konfiguration, - **Neu** mit Standardvorlage, - **Öffnen** bestehender `.properties`, - - Wiederverwendung der bestehenden headless Migrationslogik beim Öffnen einer Legacy-Konfiguration, - **Speichern** und **Speichern unter**, - Überschreibdialog, - - `.bak`-Sicherung beim Überschreiben einer bestehenden `.properties`-Datei, - Dirty-State-Markierung, - Schutzdialog bei offenen Änderungen, - gültigen GUI-Start mit `--config`. @@ -398,4 +394,4 @@ Der vollständige M10-Datei- und Editorfluss wird integriert abgesichert, einsch ## Abschlussbewertung -Die Arbeitspakete sind inhaltlich konsistent, widerspruchsfrei und sauber auf den Meilenstein **M10 – GUI-Konfigurationseditor, Dateihandling und Benutzerführung** zugeschnitten. Sie liefern einen echten, benutzerfreundlichen Konfigurationseditor auf Basis der bestehenden `.properties`-Wahrheit, ohne bereits Provider-Komfortlogik, sofortige Validierung oder technische Test-/Korrekturfunktionen aus **M11/M12** vorwegzunehmen. \ No newline at end of file +Die Arbeitspakete sind inhaltlich konsistent, widerspruchsfrei und sauber auf den Meilenstein **M10 – GUI-Konfigurationseditor, Dateihandling und Benutzerführung** zugeschnitten. Sie liefern einen echten, benutzerfreundlichen Konfigurationseditor auf Basis der bestehenden `.properties`-Wahrheit, ohne bereits Provider-Komfortlogik, sofortige Validierung oder technische Test-/Korrekturfunktionen aus **M11/M12** vorwegzunehmen. diff --git a/docs/workpackages/M11 - Arbeitspakete.md b/docs/workpackages/M11 - Arbeitspakete.md index 8fdbe93..208923f 100644 --- a/docs/workpackages/M11 - Arbeitspakete.md +++ b/docs/workpackages/M11 - Arbeitspakete.md @@ -31,7 +31,7 @@ Die Reihenfolge der Arbeitspakete ist verbindlich. - Aktion **„Validieren“** - Aktion **„Technische Tests ausführen“** -- Aktion **„Modelle neu laden“** als vollständige Bedienlogik, soweit dafür M12-spezifische Gesamtprüfung oder Korrekturhilfen nötig wären +- M12-spezifische Gesamtprüfungs- und Korrekturpfade rund um die Aktion **„Modelle neu laden“** (die Aktion selbst gehört zu M11 als manueller Wieder-Auslöser des bereits vorhandenen Modellabrufs) - technische Gesamtprüfung aller Konfigurations- und Laufzeitvoraussetzungen - schreibende Korrekturhilfen oder Sammel-Bestätigungsdialoge - automatische Erzeugung fehlender Prompt-Dateien @@ -232,8 +232,6 @@ Für den aktuell ausgewählten Provider kann eine Modellliste technisch geladen - Provider liefert keine nutzbare Modellliste, - sonstige technische Kommunikationsfehler. - Sicherstellen, dass diese Fälle als benutzerfreundliche Befunde weitergegeben werden können und die GUI nicht abbrechen lassen. -- Modellabruf läuft asynchron auf einem Worker-Thread; das Ergebnis wird über den JavaFX Application Thread in die GUI zurückgespielt. -- Versuche und Ergebnisse des Modellabrufs werden im bestehenden Log4j2-Log nachvollziehbar protokolliert. - Bootstrap-Verdrahtung nur im minimal erforderlichen Umfang ergänzen. - JavaDoc für Modellabruf, Providergrenzen und Nicht-Ziele von M11 ergänzen. @@ -272,8 +270,6 @@ Die GUI reagiert auf Providerwechsel sofort mit Modellabruf, bietet zusätzlich - Benutzer zur manuellen Eingabe befähigen. - Sicherstellen, dass ein früherer manueller Modellwert verworfen wird, wenn später eine echte Liste geladen wird und der Wert dort nicht vorkommt. - Die Modellwert-Übernahme so schneiden, dass die `.properties`-Struktur später korrekt geschrieben werden kann. -- Modellabruf läuft asynchron auf einem Worker-Thread; das Ergebnis wird über den JavaFX Application Thread in die GUI zurückgespielt. -- Erfolgreiche Listenladung, manueller Fallback und technische Fehlschläge werden im bestehenden Log4j2-Log nachvollziehbar protokolliert. - Benötigte Meldungen für erfolgreichen Modellabruf bzw. Fallback vorbereiten. - JavaDoc/Kommentare für die Modellfeldsemantik ergänzen. @@ -316,7 +312,6 @@ Der aktuelle GUI-Zustand wird beim Öffnen und während der Bearbeitung sofort a - Sicherstellen, dass die Validierung mit dem aktuellen GUI-Zustand arbeitet und kein implizites Speichern auslöst. - Sichtbar machen können, wenn aktuell eine Umgebungsvariable den Property-Wert übersteuert. - Sicherstellen, dass ein leeres API-Key-Feld einen bereits vorhandenen Property-Wert nicht stillschweigend entfernt; stattdessen ist ein deutlicher Befund für den zentralen Meldungsbereich vorzubereiten. -- Wesentliche Ergebnisse der automatischen Validierung werden im bestehenden Log4j2-Log nachvollziehbar protokolliert. - Validierungsmodell so schneiden, dass es später sowohl zentrale Meldungen als auch feldnahe Befunde speisen kann. - JavaDoc für Validierungsgrenzen, API-Key-Vorrangregel und Nicht-Ziele von M11 ergänzen. @@ -353,6 +348,7 @@ Die GUI zeigt automatische Modellabruf- und Validierungsbefunde sowohl zentral a - Feldnahe rote, kleine, deutschsprachige Fehlermeldungen direkt unter problematischen Eingabefeldern anbinden. - Sicherstellen, dass zentrale und feldnahe Befunde konsistent aus demselben Validierungs-/Meldungsmodell gespeist werden. - Modellabruf-Ergebnisse in den Meldungsbereich integrieren, z. B. erfolgreiche Listenladung oder manueller Fallback. +- API-Key-Herkunftsanzeige (Umgebungsvariable vs. Property-Wert) in den zentralen Meldungsbereich und, soweit feldnah sinnvoll, unter das API-Key-Feld anbinden. - Die GUI so schneiden, dass M12 später zusätzliche Meldungen aus expliziten Gesamtprüfungen anschließen kann, ohne M11 neu zu zerlegen. - JavaDoc/Kommentare für Meldungssemantik und Renderinggrenzen ergänzen. @@ -397,11 +393,11 @@ Der vollständige M11-Zielzustand wird automatisiert abgesichert und als stabile ### Fertig wenn - der definierte M11-Zielzustand automatisiert abgesichert ist, -- Provider-Bedienung, Modellabruf und sofortige Validierung stabil nachgewiesen sind, +- Provider-Bedienung, Modellabruf und automatische Validierung stabil nachgewiesen sind, - der Stand fehlerfrei buildbar und übergabefähig ist. --- ## Abschlussbewertung -Die Arbeitspakete sind inhaltlich konsistent, widerspruchsfrei und sauber auf den Meilenstein **M11 – Provider-Bedienung, Modellabruf und automatische Validierung** zugeschnitten. Sie decken den geplanten M11-Umfang vollständig ab, ohne technische Gesamttests, Korrekturhilfen oder andere V2.0-Bausteine späterer Meilensteine vorwegzunehmen. \ No newline at end of file +Die Arbeitspakete sind inhaltlich konsistent, widerspruchsfrei und sauber auf den Meilenstein **M11 – Provider-Bedienung, Modellabruf und automatische Validierung** zugeschnitten. Sie decken den geplanten M11-Umfang vollständig ab, ohne technische Gesamttests, Korrekturhilfen oder andere V2.0-Bausteine späterer Meilensteine vorwegzunehmen. diff --git a/docs/workpackages/M12 - Arbeitspakete.md b/docs/workpackages/M12 - Arbeitspakete.md index 7bfe817..33f137f 100644 --- a/docs/workpackages/M12 - Arbeitspakete.md +++ b/docs/workpackages/M12 - Arbeitspakete.md @@ -184,7 +184,6 @@ Die GUI bietet eine explizite Validierungsaktion, die den aktuellen Editorzustan - 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 @@ -226,8 +225,7 @@ Die für V2.0 geforderten providerbezogenen technischen Prüfpunkte können kont - 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. +- Provider-nahe technische Prüfungen laufen asynchron auf einem Worker-Thread; die Ergebnisrückführung in die GUI erfolgt über den JavaFX Application Thread. - Keine impliziten Korrekturen durchführen. - JavaDoc/Kommentare für technische Prüfpunkte und Nicht-Ziele ergänzen. @@ -266,6 +264,8 @@ Die GUI und ihre Prüflogik behandeln Windows-Pfade einschließlich gemappter La - nicht schreibbar, - ungültig, - anlegbar. +- Pfadprüfungen laufen asynchron auf einem Worker-Thread; die Ergebnisrückführung in die GUI erfolgt über den JavaFX Application Thread. +- Ausführung und Ergebnis der Pfadprüfungen werden im bestehenden Log4j2-Log nachvollziehbar protokolliert. - JavaDoc/Kommentare für Windows-/Netzlaufwerksfähigkeit und technische Grenzen ergänzen. ### Explizit nicht Teil @@ -305,10 +305,8 @@ Die GUI kann einen vollständigen technischen Gesamttest des aktuellen Editorzus - 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 @@ -339,7 +337,6 @@ Die GUI kann sichere technische Korrekturen gesammelt vorschlagen und nach einma - 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. @@ -376,7 +373,6 @@ Fehlende, technisch anlegbare Ressourcen können im Rahmen der Korrekturhilfen s - 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 @@ -426,4 +422,4 @@ Der vollständige M12-Zielzustand wird automatisiert abgesichert und als konsist ## 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. \ No newline at end of file +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. diff --git a/docs/workpackages/M13 - Arbeitspakete.md b/docs/workpackages/M13 - Arbeitspakete.md index d7aee58..13a66be 100644 --- a/docs/workpackages/M13 - Arbeitspakete.md +++ b/docs/workpackages/M13 - Arbeitspakete.md @@ -115,13 +115,12 @@ Keine. Dieses Arbeitspaket ist der M13-Startpunkt. 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. +- 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 `, - - 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. @@ -143,7 +142,46 @@ Der V2.0-Betrieb wird für Benutzer und Betreiber klar, widerspruchsfrei und vol --- -## AP-002 Konfigurationsbeispiele, Standardvorlage und Prompt-Bezug für den V2.0-Endstand konsolidieren +## AP-002 Endbenutzer-Bedienanleitung der V2.0-GUI erstellen + +### Voraussetzung +AP-001 bis AP-006 sind 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. @@ -161,8 +199,6 @@ Die im Repository enthaltenen Konfigurations- und Prompt-Beispiele passen konsis - 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. @@ -180,7 +216,7 @@ Die im Repository enthaltenen Konfigurations- und Prompt-Beispiele passen konsis --- -## AP-003 Regressionstests für headless Abwärtskompatibilität, Startoptionen und Konfigurationspfade ergänzen +## AP-004 Regressionstests für headless Abwärtskompatibilität, Startoptionen und Konfigurationspfade ergänzen ### Voraussetzung AP-001 und AP-002 sind abgeschlossen. @@ -195,7 +231,6 @@ Die kritischen V2.0-Risiken im bisherigen Server-/Scheduler-Betrieb werden autom - 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. @@ -212,7 +247,7 @@ Die kritischen V2.0-Risiken im bisherigen Server-/Scheduler-Betrieb werden autom --- -## AP-004 GUI-Smoke- und Interaktionstests für den V2.0-Kernumfang vervollständigen +## AP-005 GUI-Smoke- und Interaktionstests für den V2.0-Kernumfang vervollständigen ### Voraussetzung AP-001 bis AP-003 sind abgeschlossen. @@ -245,7 +280,7 @@ Die zentralen V2.0-GUI-Pfade sind automatisiert so abgesichert, dass Bedienung, --- -## AP-005 Build-, Packaging- und Artefaktdokumentation für das gemeinsame V2.0-JAR vervollständigen +## AP-006 Build-, Packaging- und Artefaktdokumentation für das gemeinsame V2.0-JAR vervollständigen ### Voraussetzung AP-001 bis AP-004 sind abgeschlossen. @@ -278,7 +313,7 @@ Das gemeinsame ausführbare JAR für GUI und headless ist nachvollziehbar beschr --- -## AP-006 Integrierte Gesamtprüfung des V2.0-Stands und belastbare Befundliste erstellen +## AP-007 Integrierte Gesamtprüfung des V2.0-Stands und belastbare Befundliste erstellen ### Voraussetzung AP-001 bis AP-005 sind abgeschlossen. @@ -294,7 +329,7 @@ Der V2.0-Gesamtstand wird ganzheitlich geprüft, und es entsteht eine belastbare - 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. +- Die Ergebnisse als neuen V2.0-Abschnitt in der bestehenden **`befundliste.md`** dokumentieren. - Befunde klar klassifizieren, insbesondere in: - Release-Blocker, - nicht blockierende Restpunkte, @@ -314,10 +349,10 @@ Der V2.0-Gesamtstand wird ganzheitlich geprüft, und es entsteht eine belastbare --- -## AP-007 Nachgewiesene V2.0-Release-Blocker gezielt beheben +## AP-008 Nachgewiesene V2.0-Release-Blocker gezielt beheben ### Voraussetzung -AP-006 ist abgeschlossen. +AP-008 ist abgeschlossen. ### Ziel Die im vorherigen Arbeitspaket konkret dokumentierten Release-Blocker werden gezielt und ohne Scope-Ausweitung beseitigt. @@ -342,7 +377,7 @@ Die im vorherigen Arbeitspaket konkret dokumentierten Release-Blocker werden gez --- -## AP-008 Finale V2.0-Gesamtprüfung und Freigabedokumentation erstellen +## AP-009 Finale V2.0-Gesamtprüfung und Freigabedokumentation erstellen ### Voraussetzung AP-007 ist abgeschlossen. @@ -358,6 +393,7 @@ Der V2.0-Gesamtstand wird abschließend geprüft und als freigabefähiger Stand - 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, @@ -381,4 +417,4 @@ Der V2.0-Gesamtstand wird abschließend geprüft und als freigabefähiger Stand ## 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. \ No newline at end of file +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. diff --git a/docs/workpackages/M9 - Arbeitspakete.md b/docs/workpackages/M9 - Arbeitspakete.md index b20160f..18dce5b 100644 --- a/docs/workpackages/M9 - Arbeitspakete.md +++ b/docs/workpackages/M9 - Arbeitspakete.md @@ -92,15 +92,7 @@ Ab M9 gilt verbindlich: - GUI-Code und JavaFX dürfen im **headless Pfad** nicht unnötig früh initialisiert oder geladen werden. - Fehlen GUI-Voraussetzungen beim tatsächlichen GUI-Start, ist das ein **kontrollierter GUI-Startfehler** mit klarer Rückmeldung. -### 5. Logging-Basis und bestehender Log4j2-Stack - -Ab M9 gilt verbindlich: - -- Der GUI-Adapter nutzt denselben bestehenden Log4j2-Stack wie der headless Pfad. -- Es wird **keine** zweite Logging-Konfiguration für die GUI eingeführt. -- Logformat und Log-Pfad bleiben gegenüber dem bestehenden headless Betrieb unverändert. - -### 6. Plattformziel +### 5. Plattformziel Ab M9 gilt verbindlich: @@ -108,15 +100,7 @@ Ab M9 gilt verbindlich: - Der headless Betrieb bleibt für **Windows Server / Task Scheduler** kompatibel. - M9 führt noch keine GUI-Funktionalität ein, die gemappte Laufwerke oder Datei-Dialoge fachlich ausreizt; die technische Grundlage darf dem späteren Windows-zentrierten Pfadverhalten jedoch nicht widersprechen. -### 7. Exit-Code-Semantik - -Ab M9 gilt verbindlich: - -- **`0`** für die normale erfolgreiche Beendigung eines headless Laufs sowie für das reguläre Beenden der GUI. -- **`1`** für harte Start-, Bootstrap-, Verdrahtungs-, Konfigurations- oder Initialisierungsfehler, einschließlich ungültiger CLI-Verwendung, nicht existenter `--config`-Datei im headless Start und GUI-Startfehlern vor erfolgreicher Anzeige der Oberfläche. -- Dokumentbezogene Verarbeitungsfehler des bestehenden headless Laufs verändern dieses Exit-Code-Modell nicht. - -### 8. GUI-Zielstand innerhalb von M9 +### 6. GUI-Zielstand innerhalb von M9 M9 liefert **kein** vollständiges GUI-Produkt, sondern nur ein **technisch lauffähiges Grundgerüst**. @@ -126,6 +110,27 @@ Daraus folgt: - Diese Shell dient nur dem Nachweis des GUI-Startpfads. - Ein echter Konfigurationseditor ist ausdrücklich erst Gegenstand von **M10**. +### 9. GUI-Teststrategie + +Ab M9 gilt verbindlich für alle V2.0-Meilensteine: + +- **View-Modelle und Application-nahe GUI-Logik** werden mit JUnit unit-getestet. Testfokus liegt auf Zustandsübergängen, Validierungsregeln und Datenflüssen, nicht auf Rendering. +- **GUI-Smoke-Tests** laufen unter **headless JavaFX (Monocle)** in der Maven-Test-Phase. Sie prüfen, dass zentrale GUI-Pfade (Start, Laden, grundlegende Interaktionen) technisch durchlaufen, ohne einen sichtbaren Desktop vorauszusetzen. +- Es wird **kein TestFX** und **kein weiteres GUI-Testframework** über Monocle hinaus eingeführt. +- Diese Teststrategie gilt als Referenz für alle testbezogenen Formulierungen in den Arbeitspaketen von M9 bis M13. + +### 10. JavaDoc-Standard für V2.0 + +Ab M9 gilt verbindlich für alle V2.0-Meilensteine: + +Für jede **neu hinzugefügte** oder **substanziell geänderte** öffentliche Klasse, öffentliche Methode und jedes neue Java-Package gilt: + +- **Klassen-JavaDoc**: Zweck, Verantwortung und Abgrenzung der Klasse. +- **Methoden-JavaDoc**: Zweck, Parameter, Rückgabewert und dokumentierte Ausnahmen. +- **`package-info.java`**: pro neuem Package, mit Kurzbeschreibung der Paketverantwortung. + +Dieser Standard gilt als Bestandteil jedes „Fertig wenn"-Abschnitts in V2.0. Ein Arbeitspaket ist erst dann fertig, wenn die betroffenen öffentlichen Klassen und Methoden dem JavaDoc-Standard entsprechen. + --- ## AP-001 Neues GUI-Modul und Maven-/Reactor-Basis einführen @@ -142,7 +147,6 @@ Die Projektstruktur wird um ein eigenständiges GUI-Modul erweitert, ohne die be - Abhängigkeiten so schneiden, dass das GUI-Modul als **Inbound-Adapter** auf die bestehenden inneren Schichten aufsetzen kann. - JavaFX-Grundabhängigkeiten nur dort einführen, wo sie für das GUI-Modul technisch erforderlich sind. - Sicherstellen, dass Domain, Application, Adapter-Out und CLI-Adapter frei von JavaFX-Abhängigkeiten bleiben. -- Sicherstellen, dass das GUI-Modul den vorhandenen Log4j2-Stack des Projekts ohne neue Logging-Konfiguration mitbenutzt. - Erste neutrale Paket- und Klassenstruktur im neuen Modul anlegen, soweit für einen buildbaren Stand nötig. - JavaDoc und `package-info` für die neue Modulverantwortung ergänzen. @@ -207,7 +211,6 @@ Bootstrap kann zwischen GUI und headless sauber umschalten, ohne seine Verantwor - Bootstrap so erweitern, dass es abhängig vom geparsten Startmodus den passenden Inbound-Adapter startet. - Sicherstellen, dass der bestehende headless Pfad fachlich und technisch erhalten bleibt. - Kontrollierte Fehlerableitung für harte Startfehler ergänzen, soweit M9 dies bereits erfordert. -- Exit-Code-Modell für V2.0 an die bestehende V1.1-/M7-Semantik anschließen: `0` für normale erfolgreiche GUI-/headless-Beendigung, `1` für harte Start-, Bootstrap-, Konfigurations- oder Initialisierungsfehler. - Behandlung des Konfigurationspfadbezugs im Bootstrap vervollständigen. - Sicherstellen, dass Bootstrap keine GUI-Fachlogik oder M10-Editorlogik aufnimmt. - JavaDoc und `package-info` für aktualisierte Bootstrap-Verantwortung ergänzen. @@ -333,7 +336,7 @@ AP-001 bis AP-006 sind abgeschlossen. Der vollständige M9-Zielzustand wird automatisiert abgesichert und als konsistenter Übergabestand nachgewiesen. ### Muss umgesetzt werden -- Tests für den GUI-Standardstart ergänzen, soweit im Projekt technisch sinnvoll automatisierbar. +- Tests für den GUI-Standardstart gemäß der in M9 festgelegten GUI-Teststrategie ergänzen. - Tests für **`--headless`** ergänzen. - Automatisierten Nachweis ergänzen, dass der headless Start ohne Initialisierung der JavaFX-Application-Klasse durchlaufen kann. - Tests für **`--config `** in beiden Startarten ergänzen. @@ -343,8 +346,6 @@ Der vollständige M9-Zielzustand wird automatisiert abgesichert und als konsiste - `--config` ohne Wert. - Tests ergänzen, die belegen, dass headless ohne `--config` weiterhin das bisherige Default-Verhalten nutzt. - Smoke-Tests für die Artefakterzeugung und Packaging-Basis ergänzen. -- Mindestens einen technischen Test ergänzen, der das GUI-Threadingmodell belegt, z. B. den Nachweis, dass der UI-Thread während eines simulierten langen Hintergrundvorgangs nicht blockiert. -- Tests für das verbindliche Exit-Code-Modell von GUI- und headless Startpfad ergänzen, soweit im Projekt stabil automatisierbar. - Sicherstellen, dass dokumentbezogene Batch-Funktionalität nicht versehentlich regressiert ist. - Den M9-Stand abschließend auf Architekturtreue, Abwärtskompatibilität und Nicht-Vorgriff auf M10+ prüfen. @@ -378,4 +379,4 @@ Die Arbeitspakete decken den vollständigen Zielumfang von **M9 – GUI-Grundger - Absicherung, dass headless ohne unnötige GUI-Initialisierung weiter nutzbar bleibt - Tests für Startverhalten, Fehlerpfade und Packaging -Damit ist M9 bewusst klar von den späteren GUI-Funktionalitäten aus **M10** bis **M13** getrennt und liefert dennoch einen eigenständig lauffähigen, architekturtreuen und reviewbaren Zwischenstand. \ No newline at end of file +Damit ist M9 bewusst klar von den späteren GUI-Funktionalitäten aus **M10** bis **M13** getrennt und liefert dennoch einen eigenständig lauffähigen, architekturtreuen und reviewbaren Zwischenstand.