AuraTrader Sample

AuraTrader/Projektplan.md

@@ -0,0 +1,74 @@
+# Projektplan: Meilenstein Daten-Infrastruktur
+
+*Datum: 13. Juni 2025*
+
+## Status: Design-Phase abgeschlossen, Basis-Implementierung erfolgt
+
+---
+
+## Stufe 1: Asynchrone Datenstrom-Schnittstelle (`IDataStream<T>`) - **ABGESCHLOSSEN**
+
+* **Motivation**: Das ursprüngliche, zustandsbehaftete Design war für die Verarbeitung asynchron eintreffender Daten (z.B. von `TFuture`-Objekten) zu komplex und fehleranfällig.
+
+* **Ziel**: Die Schaffung eines robusten, ereignisgesteuerten und non-blocking Modells, das den Datenproduzenten sauber vom Konsumenten entkoppelt.
+
+* **Ergebnis**:
+    * Die `IDataStream<T>`-Schnittstelle wurde überarbeitet. Die `HasData`-Eigenschaft liefert nun ein `TSignal`, das Konsumenten aktiv über potenziell neue Daten informiert.
+    * Die Referenzimplementierung `TAuraFileStream<T>` wurde erfolgreich angepasst und nutzt eine saubere Ereignis-Kopplung (`Subscribe`) für eine robuste und wartungsarme Logik.
+    * Die korrekte Funktionalität wurde durch eine angepasste DUnitX-Test-Suite verifiziert.
+
+---
+
+## Stufe 2: Abstraktion für Handelssysteme (`IDataSeriesProvider`) - **ENTWORFEN**
+
+* **Motivation**: Ein Handelssystem benötigt einen stets validen und kontinuierlichen Daten-Lookback. Ein roher `IDataStream<T>` kann dies nicht garantieren, da Lücken in den Daten auftreten können (z.B. beim Übergang von Historie zu Live).
+
+* **Ziel**: Die Konzeption einer übergeordneten Abstraktionsschicht, die diese komplexe Anforderung kapselt, die Datenintegrität sicherstellt und dem Handelssystem eine einfache, sichere Schnittstelle bietet.
+
+* **Ergebnis**:
+    Entworfen wurde der `IDataSeriesProvider`, der als "Black Box" für das Handelssystem fungiert und die Komplexität der Datenbeschaffung vollständig verbirgt. Er wurde mit zwei unterschiedlichen, vom Anwender wählbaren Betriebsmodi konzipiert:
+
+    ### Modus 1: "Live-Handel"
+    * **Motivation**: Um einen echten **"Sofort-Start"** im Live-Handel zu ermöglichen, muss die Lücke zwischen den statischen, lokalen Historiendaten und dem aktuellen Zeitpunkt geschlossen werden.
+    * **Ziel**: Ein lückenloser, tagesaktueller Start des Handelssystems ohne manuelles Eingreifen oder lange Wartezeiten für den Nutzer.
+    * **Ergebnis**: Das Design einer **Drei-Phasen-Synchronisation**: (1) Lokale History laden, (2) "Catch-up"-Daten vom Broker holen, (3) auf den Live-Stream umschalten.
+
+    ### Modus 2: "Simulation & Backtest"
+    * **Motivation**: Für Entwicklung, Test und Analyse muss die Software **völlig autonom** und ohne Abhängigkeit von einer externen, potenziell nicht verfügbaren Broker-API lauffähig sein.
+    * **Ziel**: Einen "Sofort-Start" für Backtests zu jedem beliebigen Zeitpunkt in der Vergangenheit zu ermöglichen, der rein auf lokalen Dateien basiert.
+    * **Ergebnis**: Ein Design, bei dem der relevante Datenkontext in den Speicher geladen wird, um von dort aus einen schnellen Start und ein "Playback" der Daten zu ermöglichen.
+	
+# TODO-Einträge: Dateninfrastruktur
+
+## Stufe 2: `IDataSeriesProvider`
+
+-   [ ] **Interface und Basis-Implementierung erstellen**
+    * Definiere das `IDataSeriesProvider<T>`-Interface.
+    * Definiere die `TProviderStatus`-Enumeration (`psInitializing`, `psReadyContinuous`, `psReadyWithGap`, `psFaulted`).
+    * Implementiere eine abstrakte Basisklasse `TDataSeriesProvider<T>`, die die grundlegenden Felder (z.B. für die interne `TDataSeries`) und Methoden bereitstellt.
+
+-   [ ] **Simulations-Modus implementieren**
+    * Erstelle eine konkrete Implementierung (z.B. `TSimulationSeriesProvider<T>`).
+    * Implementiere die Start-Logik:
+        * Laden des gesamten relevanten Datenkontexts via `TAuraDataServer.LoadDataSeries`.
+        * Positionierung auf einen wählbaren Startzeitpunkt via `TDataSeries.IndexOf`.
+        * Extrahieren des initialen Lookback-Puffers.
+    * Implementiere das "Playback" der nachfolgenden Datenpunkte aus der im Speicher gehaltenen Serie.
+    * Setze den `Status` korrekt auf `psReadyContinuous`, da im Simulationsmodus per Definition keine Lücke zur "Gegenwart" existiert.
+
+-   [ ] **Live-Handel Modus implementieren**
+    * **Voraussetzung**: Definiere eine Schnittstelle für Live-Datenquellen (z.B. `ILiveDataSource<T>`), die eine Methode zur Abfrage rezenter historischer Daten (`GetCatchUpData`) enthält.
+    * **Start-Logik (Drei-Phasen-Synchronisation)**:
+        * Implementiere den parallelen Start der asynchronen Operationen:
+            1.  Laden der lokalen Historie.
+            2.  Herstellen der Broker-Verbindung und Abrufen der "Catch-up"-Daten.
+        * Implementiere die "Splicing"-Logik, die beide Datenquellen zu einem nahtlosen Lookback-Puffer verbindet.
+        * Implementiere die Prüfung auf ein "Markt-Gap" beim Übergang, um den initialen Status korrekt auf `psReadyContinuous` oder `psReadyWithGap` zu setzen.
+    * **Laufzeit-Logik**:
+        * Implementiere das kontinuierliche Verarbeiten des Live-Streams.
+        * Implementiere die Fehlerbehandlung für Laufzeit-Unterbrechungen (Verbindungsverlust), inklusive des Wechsels in den `psFaulted`-Status und des sicheren "Re-Priming".
+
+-   [ ] **Session-Kalender entwerfen und implementieren**
+    * **Motivation**: Notwendig für die Unterscheidung zwischen "Markt-Gaps" (natürlich) und "Daten-Lücken" (Fehler) im Live-Betrieb.
+    * **Anforderung**: Muss pro Asset konfigurierbar sein (Handelszeiten, Feiertage).
+    * **Implementierung**: Erstelle eine Klasse, die für ein gegebenes Zeitintervall prüfen kann, ob der Markt geöffnet oder geschlossen war. Integriere diese Prüfung in die Laufzeit-Logik des `TDataSeriesProvider` im Live-Modus.