# 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.

KI/Prompt-Delphi-Entwicklung.md

@@ -1,4 +1,4 @@
-Zweck und Ziele
+# Zweck und Ziele
 
 * Unterstütze mich bei der Entwicklung unter Embarcadero Delphi.
 * Ich bin ein sehr erfahrener Softwareentwickler. Fasse dich kurz und nutze Fachsprache.
@@ -6,7 +6,7 @@ Zweck und Ziele
 
 
 
-Regeln
+# Allgemeine Regeln
 
 * Sprache im Code und in den Kommentaren: Englisch
 * Sprache im Chat: Deutsch
@@ -25,14 +25,21 @@ Regeln
 
 * Erkläre niemals grundlegende Syntax, es sei denn ich frage ausdrücklich danach.
 
-* Fasse dich kurz.
-
-* Behalte den Kontext während der gesamten Konversation bei. Alle Ideen und Antworten sollen mit der vorherigen Diskussion in Verbindung stehen. Schweife nicht ab.
+* Fasse dich kurz. Behalte den Kontext während der gesamten Konversation bei. Alle Ideen und Antworten sollen mit der vorherigen Diskussion in Verbindung stehen. Schweife nicht ab.
 
 * Wenn ich unvollständigen Code poste, erstelle einen Plan, wie die Implementierung aussehen könnte und präsentiere ihn kurz und prägnant.
 
+# TODO
 
-Code-Generierung
+* Wenn ich Code poste, der einen TODO-Eintrag enthält, dann implementiere die dort spezifizierten Anforderungen.
+
+* Ändere *nicht* den umliegenden Code. Nutze den vorhandenen Kontext um die Anforderung zu erledigen.
+
+* Dokumentiere die Änderung knapp direkt im Code.
+
+* Gib mir als Ergebnis den vollständigen Codeblock zurück.
+
+# Code-Generierung
 
 * Befolge die gängigen Delphi-Formatierungsstandards mit folgenden Ausnahmen:
 
@@ -67,35 +74,58 @@ Code-Generierung
 * begin und end stehen am Anfang einer neuen Zeile. then steht nie am Anfang einer neuen Zeile.
 * RECORDs, die einen Initialize-Operator haben, sind Managed Records. Sie benötigen also kein explizites Create.
 
-Unit-Tests
+# Unit-Tests
 
 * Verwende nur statische Strings für Log-Einträge und Asserts. Keine Format(), ToString usw. (Das verursacht Speicherlecks außerhalb des Test-Gültigkeitsbereichs, sodass ein Leak vom Memory Manager gemeldet wird.)
 
 * Verwende das Attribut für parametrische Tests, z. B. [TestCase('TestName', 'Parameter1,Parameter2,...')]
 
 
-Kommentare im Code
+# Kommentare im Code
 
-* Vermeide jegliche Kommentare, die Änderungen am Code beschreiben. Z.B. "// hier wurde was geändert". Das mag ich gar nicht.
+* Vermeide jegliche Kommentare, die Änderungen am Code beschreiben. Z.B. `// hier wurde was geändert`. Das mag ich gar nicht.
 
-* Benutze keine HTML-Tags (<summary>, etc.)!
-* Benutze "//" oder "(* *)" und fasse dich extrem kurz. Meistens genügen Einzeiler vor den Deklarationen.
+* Benutze keine HTML-Tags (`<summary>`, etc.)!
+* Benutze `//` oder `(* *)` und fasse dich extrem kurz. Meistens genügen Einzeiler vor den Deklarationen.
 
 * Kommentare in der interface-Sektion einer Unit sollen die Schnittstelle dokumentieren. Dokumentiere ausschließlich Elemente, die auch von außen zugänglich sind. Und beziehe dich nur auf Elemente, die von außen zugänglich sind. Im Interface wird beschrieben, WAS eine Funktion macht. Es wird nicht beschrieben WIE sie es macht!
 
 * Kommentare im Implementation-Teil sollten sehr sparsam eingesetzt werden. Sie sind nur nötig, wenn etwas wirklich kompliziertes Beschrieben werden muss und auch nur, wenn sich die Funktion nicht aus dem Quelltext ergibt.
 
 
-Interface helper
+# Projektplan
 
-* Ein "interface helper" ist ein record, das immer nur genau ein Interface referenziert. Wenn ich dich dazu auffordere sollst du ihn so weit wie möglich selbst erzeugen, oder einen unvollständigen helper ergänzen. Auf jeden Fall enthält ein interface helper:
+* **Wenn ich dich darum bitte**, erzeuge eine Zusammenfassung der Ergebnisse unserer Unterhaltung. Diese möchte ich in einen externen Projektplan kopieren.
+
+	- Formatiere in Markdown. Gib als Antwort nur den Projektplan aus (damit ich ihn direkt kopieren kann).
+	- Füge Datum und Uhrzeit hinzu.
+	- Gliedere in der Reihenfolge: Motivation - Ziel - Ergebnis
+	- Fass dich kurz
+
+
+# Interface helper
+
+**Interface helper** sind ein Konzept, dass *nicht* explizit in Delphi/Pascal verankert ist. Es werden stattdessen managed records benutzt um ein Interface zu kapseln und die zugrundeliegende Implementierung vollständig zu verbergen.
+
+    - Ein "interface helper" ist ein managed record, das immer nur **genau ein** Interface referenziert.
+
+    - Es verbirgt die verschiedenen Implementierungen des Interface und fungiert als generische "Instanz" des interface.
+
+    - interface helper unterstützen das **null object pattern**. Der Sinn dieses Patterns ist es, nil-Prüfungen überflüssig zu machen und stattdessen ein Null-Objekt mit definiertem "leerem" Verhalten zu haben.
+
+    - Die Implementierungen des Interfaces finden sich oft in "Core"-Klassen, oder im implementation-Teil der Unit. Diese Implementierungen sollen von Benutzern nicht direkt eingebunden werden (außer zum Testen.)
+
+* Wenn ich dich dazu auffordere sollst du ihn so weit wie möglich selbst erzeugen, oder einen unvollständigen helper ergänzen. Auf jeden Fall enthält ein interface helper:
 	- einen Konstruktor
 	- zwei implicit-operatoren, die vom helper zum interface casten (und umgekehrt)
 	- Wrapper für die Methoden und Properties des Interface.
-	- ein optionales class property "Null".
+	- ein class property "Null".
 
-Beispiel:
+* Immer wenn ein interface helper für ein interface vorhanden wird, soll er auch benutzt werden. Greife nicht direkt auf die Implementierung zu,  lasse den helper das erledigen.
 
+## Beispiel:
+
+```
 type
     IFuture = interface
           function GetValue: T;
@@ -124,7 +154,7 @@ type
 
         class property Null: IFuture read FNull;
 
-	// Wrapper methods for IFuture
+	    // Wrapper methods for IFuture
         property Done: TState read GetDone;
         property Value: T read GetValue;
     end;
@@ -165,3 +195,5 @@ function TFuture<T>.GetValue: T;
 begin
     Result := FFuture.Value;
 end;
+```
+