Beginning Editor

Doc/Roadmap.md

@@ -1,80 +1,68 @@
-### **Projektplan: Visueller AST-Editor für Handelsstrategien**
+### **Roadmap: Implementierung des Interaktiven Semantischen Editors**
 
-* **Datum:** 08.09.2025 11:38
-
-#### **Motivation**
-
-Ziel ist die Schaffung eines Systems, das es Fachexperten ohne Programmierkenntnisse ermöglicht, komplexe Handelsstrategien visuell zu entwerfen, zu debuggen und zu backtesten. Die traditionelle Hürde der textbasierten Programmierung wird durch einen rein visuellen, geführten Ansatz eliminiert, der Fehler von vornherein vermeidet. Eine Kernanforderung ist die robuste Schnittstelle für den Import und Export von Logik aus externen Quellen, insbesondere LLMs.
-
-#### **Ziel**
-
-Die Entwicklung einer dualen Systemarchitektur, die eine intuitive, fehlerresistente Entwicklungsumgebung von einer hochperformanten Backtesting-Engine trennt. Die Architektur muss eine strikte Trennung zwischen dem logischen Modell (AST) und dem visuellen Zustand (UI-Metadaten) gewährleisten, um eine hohe Datenintegrität bei internen und externen Bearbeitungen sicherzustellen und eine nahtlose Persistenz von Projekten zu ermöglichen.
-
-#### **Ergebnis: Architekturentwurf**
-
-Der Editor basiert auf einer verfeinerten Model-View-ViewModel-Architektur, die maximale Robustheit und Flexibilität gewährleistet.
-
-1. **Das Model: Der High-Level AST (HAST)**  
-   * Der IAstNode-Baum ist die alleinige "Source of Truth" und enthält ausschließlich die reine, zustandslose Programmlogik. Diese Datenreinheit ist die Voraussetzung für die einfache Serialisierung und die Interaktion mit externen Systemen.  
-2. **Der Vermittler: Die ViewModel-Schicht**  
-   * Ein parallel zum HAST existierender Baum aus TVisualNodeViewModel-Objekten dient als Brücke zur UI.  
-   * Jedes ViewModel erhält eine **stabile, permanente ID** (TViewModelID), die es unabhängig von seiner Position im Baum macht. Diese ID ist der Schlüssel zur Lösung für stabile Bearbeitungen und Metadaten.  
-3. **Die Ansicht: Deterministisches Layout mit Overrides**  
-   * Die visuelle Darstellung (TAuraNode-Controls) wird durch einen deterministischen Algorithmus aus dem ViewModel-Baum generiert (View \= f(ViewModel)).  
-   * Manuelle Layout-Änderungen durch den Benutzer werden als "Overrides" in einer separaten Metadaten-Struktur gespeichert und über die stabile TViewModelID zugeordnet.  
-4. **Zweifaches Metadaten-System**  
-   * **Logische Metadaten** (z.B. Farbkodierung) werden an den IAstNode gekoppelt und gelten für alle seine visuellen Instanzen.  
-   * **Visuelle Instanz-Metadaten** (z.B. Position, IsCollapsed) werden an die stabile TViewModelID gekoppelt und gelten nur für eine spezifische Instanz.  
-5. **Duale Ausführungs-Engines & Serialisierung**  
-   * Ein **HAST-Interpreter** arbeitet im Debug-Modus direkt auf dem HAST für eine reichhaltige UI-Erfahrung.  
-   * Ein **CAST-Evaluator** arbeitet im Backtest-Modus auf einer optimierten Repräsentation (Core AST) für maximale Performance.  
-   * Ein **duales Clipboard/Dateiformat** serialisiert entweder nur den reinen HAST (für LLMs) oder den HAST inklusive aller Metadaten (für Projekte).
+**Leitprinzip:** Die Serialisierung ist kein nachträgliches Feature, sondern das Fundament. Das Datenformat wird zuerst vollständig definiert und implementiert. Die Visualisierungs- und Editierfunktionen bauen darauf auf.
 
 ---
 
-### **TODO: Priorisierte Roadmap**
+#### **Phase 1: Das Fundament – Datenmodell & Persistenz**
 
-#### **Phase 1: Minimales Architektur-Fundament**
+**Ziel:** Eine robuste Serialisierungs-Engine zu schaffen, die den gesamten Zustand des Editors (AST, logische Metadaten, Instanz-Metadaten) verlustfrei speichern und laden kann, *bevor* eine einzige visuelle Komponente existiert.
 
-* **Ziel:** Die technische Basis für alle weiteren Schritte schaffen. Dieser Schritt ist die Voraussetzung für die Serialisierung.  
-* **Schritte:**  
-  1. **ViewModel-Schicht implementieren:** Die TVisualNodeViewModel-Klasse mit der stabilen TViewModelID erstellen.  
-  2. **Metadaten-Strukturen aufbauen:** Die beiden Dictionaries für TLogicalMetadata (gekoppelt an IAstNode) und TVisualInstanceMetadata (gekoppelt an TViewModelID) definieren und implementieren.  
-  3. **Visitor refaktorisieren:** Den TAstToAuraNodeVisitor so umbauen, dass er den ViewModel-Baum erzeugt und dabei die stabilen IDs vergibt.  
-  4. **Layout-Engine implementieren:** Den deterministischen Layout-Algorithmus umsetzen, der die Basis-Positionierung vornimmt. Die Engine muss bereits in der Lage sein, Positions-Overrides aus den TVisualInstanceMetadata zu berücksichtigen.
+1. **Definition der Kern-Datenstrukturen:**  
+   * **TViewModelID**: Ein Int64-Typ als eindeutige, stabile ID für jede visuelle Knoteninstanz.  
+   * **TVisualNodeViewModel**: Die Vermittlerklasse zwischen IAstNode und TAuraNode. Enthält eine Referenz auf den IAstNode und seine eigene TViewModelID.  
+   * **TLogicalMetadata**: Record für Metadaten, die an einen IAstNode gebunden sind (z.B. semantische Farbcodierung).  
+   * **TVisualInstanceMetadata**: Record für Metadaten, die an eine TViewModelID gebunden sind. **Hier wird die neue Anforderung verankert:**  
+     * PositionOverride: TPointF  
+     * IsCollapsed: Boolean  
+     * VisualizationMode: (vmSyntactic, vmSemantic) // Definiert, wie DIESE Instanz ihre Kinder darstellt.  
+2. **Festlegung des finalen JSON-Formats:**  
+   * Das JSON-Format wird von Anfang an so entworfen, dass es alle zukünftigen Anforderungen abbilden kann. Es besteht aus drei Hauptteilen:  
+     1. **ast**: Der reine IAstNode-Baum. Zur Persistenz wird jedem IAstNode beim Speichern eine temporäre, datei-interne Integer-ID zugewiesen.  
+     2. **logicalMetadata**: Ein Dictionary, das die temporären IAstNode-IDs auf ihre TLogicalMetadata abbildet.  
+     3. **instanceMetadata**: Ein Dictionary, das die stabilen TViewModelIDs auf ihre TVisualInstanceMetadata abbildet (inklusive des neuen VisualizationMode).  
+3. **Implementierung des Serialisierungs- & Deserialisierungs-Backbones:**  
+   * Entwicklung der Routinen, die einen IAstNode-Baum und die dazugehörigen Metadaten-Dictionaries entgegennehmen und eine JSON-Datei gemäß Schritt 1.2 erzeugen.  
+   * Entwicklung der Gegenstücke, die eine solche JSON-Datei einlesen und die In-Memory-Strukturen (IAstNode-Baum, Dictionaries für Metadaten) vollständig und konsistent wiederherstellen.  
+   * **Wichtig:** Diese Logik arbeitet komplett ohne UI-Komponenten.
 
-#### **Phase 2: Kern-Feature – Persistenz & Interoperabilität**
+**Ergebnis von Phase 1:** Eine voll funktionsfähige "headless" Lade- & Speicher-Bibliothek. Man kann einen Editor-Zustand programmatisch erzeugen, speichern, wieder laden und die Datenintegrität per Unit-Tests verifizieren. **Die Serialisierung ist damit vom ersten Tag an das stabilste Element der Architektur.**
 
-* **Ziel:** Das System schnellstmöglich nutzbar machen, indem Projekte gespeichert/geladen und Logik extern ausgetauscht werden kann.  
-* **Schritte:**  
-  1. **Duale JSON-Serialisierung entwickeln:**  
-     * **Routine A (Projekt):** Serialisiert den HAST und beide Metadaten-Systeme.  
-     * **Routine B (Logik-Clipboard):** Serialisiert ausschließlich den reinen HAST.  
-  2. **Deserialisierung implementieren:**  
-     * **"Projekt laden":** Stellt den HAST, den ViewModel-Baum und alle Metadaten aus der Projektdatei vollständig wieder her.  
-     * **"Logik einfügen":** Eine pragmatische erste Version, die einen reinen HAST-Teilbaum deserialisiert, dafür neue ViewModels mit neuen IDs erzeugt und ihn von der Layout-Engine automatisch positionieren lässt.  
-  3. **UI-Anbindung:** Die Aktionen "Projekt speichern", "Projekt laden", "Logik als JSON kopieren" und "Logik aus JSON einfügen" in der UI implementieren.
+---
 
-#### **Phase 3: Interaktivität & Benutzerführung**
+#### **Phase 2: Die Flexible Visualisierungs-Engine**
 
-* **Ziel:** Den Editor um die volle, geführte Bearbeitungsfunktionalität erweitern.  
-* **Schritte:**  
-  1. **Command Pattern umsetzen:** IEditorCommand-Schnittstelle und TCommandManager für Undo/Redo erstellen.  
-  2. **Socket-basierte Controller-Logik entwickeln:** Die Interaktion implementieren, bei der Klicks auf Input-Sockets kontextsensitive Menüs mit validen Optionen öffnen. Jede Aktion wird über das Command-System abgewickelt.  
-  3. **Refactoring-Funktionen implementieren:** Visuelle Operationen wie "Zu Funktion zusammenfassen" umsetzen.
+**Ziel:** Die in Phase 1 definierten Datenstrukturen sichtbar machen und den Wechsel zwischen syntaktischer und semantischer Darstellung ermöglichen.
 
-#### **Phase 4: Ausführung & Debugging**
+1. **Der "ViewModel-Builder"-Visitor:**  
+   * Dieser Visitor nimmt einen IAstNode (HAST) sowie die Metadaten entgegen und erzeugt den TVisualNodeViewModel-Graphen.  
+   * Er arbeitet modus-abhängig, basierend auf dem VisualizationMode des Eltern-ViewModels:  
+     * **Im vmSyntactic-Modus:** Erzeugt für jeden Kind-IAstNode eine neue, einzigartige TVisualNodeViewModel-Instanz mit einer neuen TViewModelID. Das Ergebnis ist ein Baum.  
+     * **Im vmSemantic-Modus:** Nutzt nach dem obligatorischen Binding-Schritt einen TDictionary\<TResolvedAddress, TVisualNodeViewModel\>, um für bereits visualisierte semantische Entitäten das existierende ViewModel wiederzuverwenden. Das Ergebnis ist ein DAG.  
+2. **Die Layout- & Rendering-Engine (TAuraLayoutEngine):**  
+   * Diese Engine nimmt den TVisualNodeViewModel-Graphen (der ein Baum oder DAG sein kann) und erzeugt die visuellen TAuraNode-Controls.  
+   * Für jedes ViewModel liest sie die TVisualInstanceMetadata (über die TViewModelID) und wendet Position, Kollaps-Zustand etc. an.  
+   * Sie muss in der Lage sein, die Verbindungen für eine DAG-Struktur korrekt zu zeichnen (d.h. Linien von mehreren Eltern zu einem Kind).  
+3. **Implementierung des Modus-Wechsels:**  
+   * Schaffung einer UI-Aktion (z.B. Kontextmenü auf einem TAuraNode), um den VisualizationMode in den Metadaten einer ViewModel-Instanz zu ändern.  
+   * Diese Änderung löst eine Aktualisierung aus: Der ViewModel-Builder wird für den betroffenen Teilbaum neu ausgeführt, und die Layout-Engine zeichnet den Bereich neu.
 
-* **Ziel:** Den im Editor erstellten HAST interaktiv ausführbar und debuggbar machen.  
-* **Schritte:**  
-  1. Den **HAST-Interpreter** (Debugger) implementieren oder ausbauen.  
-  2. Den Interpreter tief mit der UI und dem ViewModel-Baum koppeln, um Debugging-Features zu realisieren (visuelles Hervorheben, Breakpoints, Step-Logik etc.).
+**Ergebnis von Phase 2:** Ein interaktiver Viewer. Projekte können geladen, in beiden Modi (syntaktisch/semantisch) dargestellt und per Knoten umgeschaltet werden.
 
-#### **Phase 5: Performance & Optimierung**
+---
 
-* **Ziel:** Die Ausführung von Strategien für die Massen-Datenverarbeitung optimieren und die UX verfeinern.  
-* **Schritte:**  
-  1. Die **CAST-Struktur** (Core AST) definieren.  
-  2. Den **HAST-zu-CAST-Expander** (Compiler/Visitor) entwickeln.  
-  3. Den "headless" **CAST-Evaluator** (Backtester) implementieren.  
-  4. Den **"Smart Paste"-Algorithmus** (Diff & Merge) als finale Verfeinerung für das Einfügen von Logik nachrüsten.
+#### **Phase 3: Der Interaktive Editor**
+
+**Ziel:** Dem Benutzer die sichere und strukturierte Bearbeitung des Graphen zu ermöglichen.
+
+1. **Implementierung des Command Patterns:**  
+   * Jede Änderung am AST (Knoten hinzufügen, löschen, Eigenschaft ändern) wird als IEditorCommand mit Execute und Unexecute implementiert, um Undo/Redo zu ermöglichen.  
+   * Ein Command modifiziert **immer nur das HAST-Modell**, niemals direkt das ViewModel oder die View.  
+2. **Entwicklung des Socket-basierten Controllers:**  
+   * Implementierung der Logik, die Benutzerinteraktionen (Klick auf ein "Socket") in die Erzeugung und Ausführung des passenden Commands übersetzt.  
+3. **Etablierung des Update-Zyklus:**  
+   * Nachdem ein Command das HAST-Modell erfolgreich modifiziert hat, wird der Update-Prozess angestoßen:  
+     1. Der "ViewModel-Builder" läuft über den geänderten Teil des HAST. Er versucht dabei, existierende ViewModels (anhand ihrer IAstNode-Referenz) wiederzuverwenden, um deren stabile IDs und damit die UI-Zustände zu erhalten. Nur für neue IAstNodes werden neue ViewModels erzeugt.  
+     2. Die TAuraLayoutEngine rendert die neuen TAuraNode-Controls.
+
+**Ergebnis von Phase 3:** Ein voll funktionsfähiger, interaktiver Editor mit robustem Zustandsmanagement, flexibler Visualisierung und Undo/Redo-Funktionalität.

Doc/Visueller Editor für Handelsstrategien (Revision 1).md

@@ -0,0 +1,21 @@
+### **Projektplan: Visueller Editor für Handelsstrategien (Revision 1\)**
+
+* **Datum:** 08.09.2025 14:20
+
+#### **Motivation**
+
+Ziel ist die Schaffung eines Systems, das es Fachexperten ermöglicht, die **Logik und den Datenfluss** von Handelsstrategien visuell zu entwerfen. Statt der reinen Syntax wird der **semantische Graph** abgebildet, um Redundanzen zu eliminieren und die tatsächlichen Beziehungen zwischen den Variablen und Operationen in den Vordergrund zu stellen. Dies schafft ein intuitiveres Verständnis der Strategie-Logik.
+
+#### **Ziel**
+
+Die Entwicklung einer Architektur, die den **semantisch korrekten Graphen** einer Strategie visualisiert. Dies erfordert eine klare Abfolge der Verarbeitungsschritte: Zuerst muss eine semantische Analyse (Binding) des rohen Abstract Syntax Tree (AST) erfolgen. Erst auf Basis dieses angereicherten, semantischen Modells wird der visuelle Graph (ein Directed Acyclic Graph, DAG) erzeugt, in dem semantisch identische Entitäten (z.B. Verwendungen derselben Variable) zu einem einzigen visuellen Knoten zusammengefasst werden.
+
+#### **Ergebnis: Architekturentwurf (Revision 1\)**
+
+Die Architektur wird angepasst, um den semantischen Graphen als "Source of Truth" für die Visualisierung zu nutzen.
+
+1. **Semantische Analyse als Voraussetzung:** Der Bind-Prozess ist der obligatorische erste Schritt vor jeder Visualisierung. Er analysiert den AST und reichert die Knoten, insbesondere die Identifier, mit semantischen Adressinformationen (TResolvedAddress) an.  
+2. **Der Builder (TAstToViewModelVisitor):** Der Visitor wird intelligent. Er übersetzt den AST nicht mehr 1:1, sondern erzeugt einen TVisualNodeViewModel-Graphen (DAG). Dazu nutzt er einen internen Cache (TDictionary\<TResolvedAddress, TVisualNodeViewModel\>), um bereits erstellte ViewModels für semantisch identische Identifier wiederzuverwenden.  
+3. **Das Modell (TVisualNodeViewModel):** Die Struktur der ViewModels ist nicht länger ein Baum, sondern ein DAG, da ein Knoten (z.B. für eine Variable) nun von mehreren Elternknoten referenziert werden kann.  
+4. **Die Ansicht (TAuraLayoutEngine):** Die Layout-Engine muss in der Lage sein, die resultierende DAG-Struktur korrekt darzustellen, inklusive der Verbindungen von mehreren Eltern zu einem Kind.
+