I'm building an SPX analysis app with AI help. What would you finish and prove first?

Ich bin ein Anfänger in der Programmierung und baue eine persönliche Windows-Anwendung für Intraday-Analysen des SPX, wobei ich bei der Entwicklung auf Codex und Claude zurückgreife. ChatGPT/Codex hat auch bei der Organisation und beim Verfassen dieses Beitrags aus meinem Projektmaterial geholfen. Ich bin inzwischen an dem Punkt angelangt, an dem ich einen erfahrenen Entwickler brauche, der das Design auf die Probe stellt, und nicht noch eine KI-Erklärung, warum es funktionieren sollte.

Die Anwendung platziert keine Trades. Meine Frage dreht sich darum, die gesamte Anwendung benutzbar und konsistent zu machen, und nicht darum, einen weiteren Indikator hinzuzufügen oder einen einzelnen Benchmark schneller zu machen.

Die Datenerfassung soll im Hintergrund weiterlaufen, man öffnet den Bildschirm für den heutigen Tag und sieht die SPX-Kurse neben der vollständigen Auswahl an infrage kommenden Optionskontrakten des gleichen Handelstages, standardmäßig PM-quotierten SPXW-Optionen. Die vorgesehene Analyse umfasst Gamma/GEX, ein Gamma-Flip-Level, Call- und Put-Walls, Max Pain und Optionsflow mit klar ausgewiesenen Quellen-Einschränkungen. Das Volumen der ES-Futures dient als ergänzender Kontext, nicht als eigenes gehandeltes Volumen des SPX.

Ich möchte zwischen Ansichten mit 1, 5, 15, 30 und 60 Minuten wechseln, die Historie einsehen, exakt die Analyse speichern, die ich gesehen habe, und dieses Ergebnis später wieder öffnen. Beim erneuten Öffnen sollten keine neueren Eingabedaten oder eine andere Berechnung stillschweigend eingesetzt werden. Forschungsszenarien sind zusätzliche Funktionen, keine Voraussetzung für das Öffnen des heutigen Bildschirms.

Der Stack besteht aus C#/.NET 10 unter Windows, SQLite und Protobuf, mit Adaptern für Interactive Brokers und Moomoo OpenD. Die Erfassung läuft getrennt von der Analyse. Der vorgesehene Ablauf ist folgender:

Provider-Callbacks → aufgezeichnete Batches, deren Vollständigkeit bestätigt wurde → ein Reducer, der den angesammelten Zustand aktualisiert → eine Transaktion, die Fakten, Neustart-Zustand und Fortschritt gemeinsam speichert → Commit → veröffentlichter Fortschritt → Berechnung aus festgelegten Eingabedaten → gespeichertes Ergebnis → Bildschirm → Speichern → Wiederöffnen.

Eine einzelne Transaktion kann bis zu acht vollständige Batches enthalten. Die Absicht ist, dass Berechnungen nur übergebenen Fortschritt verwenden und dass dieselben Regeln für den Aufbau des Zustands durchgängig gelten. Das ist das Design, kein Nachweis, dass jede Übergabe bereits funktioniert.

Für Kurse, SPX- und ES-Bars, Open Interest, ein Quellen-Gamma/OI-Proxy, Trades sowie begrenzte Speicher- und Wiederöffnungstests gibt es funktionierende Bausteine. Der übliche Gamma- und Flip-Workflow fehlt im kontinuierlichen Dienst und in der Benutzeroberfläche noch. Eine separate bedingte Forschungsberechnung existiert, aber sie vervollständigt den täglichen Betrachtungs-Workflow nicht. Die Berechnung der eigenen impliziten Volatilität ist geplant, aber noch nicht validiert.

Die Qualifikation von Quotes, Carry-Annahmen und asynchrone Snapshots bleiben ungelöst. Das Gamma/OI-Ergebnis ist ein Proxy für Positionierungen, kein beobachteter Händlerbestand. Diese Einschränkungen müssen den Weg bis zum Bildschirm und zur gespeicherten Historie überstehen und dürfen nicht hinter einem plausibel aussehenden Chart verschwinden.

Auch der Start, die Wiederherstellung, das Speichern nach einer verlorenen Antwort sowie realistische Kapazitätsgrenzen müssen noch bearbeitet werden. Eine KI-unterstützte Durchsicht des Quellcodes hat drei Bedenken hervorgehoben, die ich von einer Person prüfen lassen möchte:

Ich habe keine unabhängige menschliche Überprüfung, die diese Bedenken oder die vorgeschlagenen Korrekturen bestätigt.

Ein älterer Kandidat erreichte einen Kontrollpunkt von rund 300.000 Datensätzen in 88,93 Sekunden und stieß dann vor einem Kontrollpunkt von rund 803.000 Datensätzen an ein gemeinsames Limit von 120 Sekunden. Spätere Korrekturen an Lösch-Schlüsseln und dem Ressourcenbesitz haben nur kleine funktionale Belege, darunter ein synthetisches End-to-End-Beispiel mit 45 Datensätzen. Für diesen korrigierten Kandidaten gibt es im Material keinen neuen Benchmark mit großen Stichproben. Ein älterer instrumentierter Lauf verwendete eine andere, größere Aufzeichnung; er belegt nicht den aktuellen Engpass.

Wenn du dieses Projekt übernehmen würdest: Welchen nächsten vollständigen, nützlichen Workflow würdest du zu Ende führen und belegen, bevor du weitere Funktionen ergänzt? Ich möchte, dass er mit den eingehenden Daten beginnt und mit dem erneuten Öffnen der gespeicherten Beobachtung endet, statt an einer bestandenen Berechnung oder einem Datenbank-Schreibvorgang Halt zu machen.

Wie sähe das kleinste überzeugende Abnahmebeispiel aus? Insbesondere: Was sollte es über unterbrochene Erfassung, veraltete Eingabedaten, einen Neustart und eine unsichere Speicherantwort beweisen?

Wenn du einen Designfehler in einer einzelnen Stufe erkennst, sag mir bitte auch, was deine Änderung stromaufwärts erfordern würde und was sie stromabwärts verändern würde. Ich habe Sorge, dass ich einzelne für sich vernünftige Korrekturen ansammle, die dann nicht mehr übereinstimmen, was der Nutzer tatsächlich gesehen und gespeichert hat.

Der Projekt-Snapshot endet am 26. Oktober 2026 um 04:13 UTC, vor einem neuen profilierten Produktionslauf. Mein Begleitmaterial enthält Kopien der Quelltext-Lektüre, Design-Notizen, Testbelege und Meinungsverschiedenheiten zwischen KI-Reviews. Es ist keine lauffähige Reproduktion: Rohe Aufzeichnungen, SDK-Binärdateien, vollständige Maschinendetails und ein aktueller Trace fehlen. Ich bitte um einen begründeten nächsten Schritt und behaupte nicht, dass dieses Material beweist, dass die Architektur tragfähig ist.