Meilensteine für V2.0 in der Pre-Version angelegt

docs/workpackages/M12 - Arbeitspakete.md

@@ -0,0 +1,429 @@
+# 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.