Lösung zur manuellen Erzeugung von simuliertem Rauch im Live-Handel (live_grid_multi)

Lieber Benutzer, dieses Kapitel ist eine manuelle Checkliste: Führen Sie an einem realen Handelstag (oder zu einem für Sie passenden Zeitpunkt) eine simulierte Live-Handelssitzung mit dem Repository-Beispiel „examples/live_grid_multi.py“ durch, haken Sie jeden Punkt ab und bestätigen Sie, dass das Verhalten von qteasy mit der Dokumentation übereinstimmt.

Was ist Smoke-Testing? Ähnlich wie Probefahrten vor dem Stapellauf eines neuen Schiffes müssen dabei nicht alle Strategien abgedeckt werden, sondern anhand fester Beispiele und festgelegter Prüfungen schnell festgestellt werden, ob es funktioniert und ob die Protokolle lesbar sind. Dieses Handbuch konzentriert sich auf echte `qt.run`-Ausführungen in Kombination mit manueller Überprüfung. Außerhalb der Handelszeiten können für Architektur-Regressionstests auch Headless-Skripte im Repository verwendet werden (siehe unten).

Strategie-Baseline: examples/live_grid_multi.py (5-Minuten-VS + Multi-Mark-Grid). Maintainer, die die interne Roadmap benötigen, können das Repository .cursor/plans/trader architecture upgrade roadmap_0650f0d5.plan.md konsultieren (optional, nicht zwingend erforderlich).

Beziehung zu Headless-Skripten

tests/notebook_trader_headless_script.py stellt phasengesteuerten Headless-Smoke (einschließlich 5-A/5-B, 5-C usw.) bereit, der in Notebook-Zellen aufgerufen werden kann.
Dieses Handbuch konzentriert sich auf Folgendes: das persönliche Starten der Live-Umgebung, das Anzeigen der CLI/Protokolle und das Ankreuzen der Kontrollkästchen.
Empfohlener Zeitplan: An Handelstagen folgen Sie dieser Anleitung; Während der Börsenschließungen verwenden Sie ein Headless-Skript zur Durchführung von Regressionsanalysen.

I. Umfeld und Voraussetzungen

Python: /opt/anaconda3/envs/py39/bin/python wird empfohlen. Wenn Sie qteasy über pip installiert haben, kann das Arbeitsverzeichnis ein beliebiger Pfad sein, der examples/live_grid_multi.py enthält (Sie müssen nicht das gesamte Repository klonen, aber Sie müssen auf das Beispielskript zugreifen können).
Neues Konto, keine offenen Positionen (um Interferenzen durch alte Aufträge zu vermeiden):
- -n/–new_account <Benutzername> erstellt ein neues Konto; oder
- Falls eine account_id bereits existiert und –restart den Datensatz löscht, starten Sie erst neu, nachdem Sie sich vergewissert haben, dass keine offenen Positionen mehr vorhanden sind.
Daten: Bei minutenbasierten Strategien werden lokale Tabellen wie stock_1min benötigt; die anfängliche Nachfüllung kann länger dauern, was normal ist.
**Protokolle: sys_log_file_path und trade_log_file_path sind beschreibbar (prüfen Sie dies mit artifacts).

II. Startbefehlsvorlage

Führen Sie den Befehl im Verzeichnis aus, das das Beispiel enthält (passen Sie die Pfade an Ihr Benutzerkonto an):

/opt/anaconda3/envs/py39/bin/python examples/live_grid_multi.py \\
    -a <ACCOUNT_ID> -n <NEW_USER_NAME_OR_OMIT> \\
    --ui cli \\
    [--debug] [--restart]

veranschaulichen:

Kaltstart: Erstellen Sie ein neues -n oder –restart und vergewissern Sie sich, dass die Position leer ist.
Um finanziellen Druck zu vermeiden, sollte trade_batch in einer unbekannten Umgebung nicht hochskaliert werden.
5-C-bezogene CLI Es wird empfohlen, –debug hinzuzufügen, damit run –task diagnose_pending_orders ausgeführt werden kann.

III. Stufenweise Abnahme (Jeden Punkt abhaken)

Die folgenden Phasen entsprechen den internen Roadmaps 0-5-C / Phase 11; jeder Punkt beinhaltet was in dieser Phase überprüft wird, den Betrieb und die Abnahme.

Phase 0: Baseline, Zustandsautomat und Beobachtbarkeit

Was zu überprüfen ist: Der Trader kann normal starten, die Zustandsübergänge sind plausibel und die Protokolle können die Reihenfolge von „Start → Zeitplan → Kritische Aufgaben“ wiederherstellen.

Vorgehensweise: Beobachten Sie den Status (angehalten → im Ruhemodus/läuft usw.) in der CLI/im Protokoll und die Aufgabenwarteschlange.
Abnahmetest: Keine unerklärlichen Deadlocks; Fähigkeit, einen vollständigen Startzeitablauf zu rekonstruieren.

Phase 1: Standardisierter Ausstieg

Was zu überprüfen ist: Werden die Ressourcen nach einem normalen Stopp/Beenden freigegeben und treten keine ungewöhnlichen Kürzungen in Haltepunkten und Protokollen auf?

Vorgehensweise: Beenden Sie den Prozess normal über die Shell; beenden Sie den Prozess nicht zwangsweise.
Akzeptanztest: Keine Zombie-Threads; vollständige Protokolle.

Phase 2: Aufgabenplanung und Überspringen

Was zu überprüfen ist: Asynchrone Preiserhöhungen und Strategieaufgaben haben klare Grenzen; wenn eine Aufgabe übersprungen wird, enthält das Protokoll lesbare skip_reason.

Vorgehensweise: Beobachten Sie die Zeitpläne wie acquire_live_price und run_strategy.
Akzeptanz: Anomalien/Auslassungen sind erklärbar und statistisch signifikant.

Phase 3: Zeitplan und Aufholprozess

Was zu überprüfen ist: Der Zeitplan lässt sich unter der gleichen Konfiguration reproduzieren; das „erneute Ausführen“-Verhalten beim Starten von der Festplatte entspricht der Dokumentation.

Vorgehensweise: Vergleichen Sie die beiden Schlüsselmomente am selben Tag oder initiieren Sie einen während des Handels.
Akzeptanz: Die Zeitplanausgabe ist reproduzierbar.

Phase 3.5: Übereinstimmung zwischen Transaktionserfassung und Zahlung

Was wird überprüft: Kassenbestand/Position/Auftrag müssen nach der Transaktion übereinstimmen, ohne dass doppelte Abzüge erfolgen.

Vorgehensweise: Überprüfen Sie das Hauptbuch nach mindestens einer simulierten Transaktion.
Annahme: Kein Widerspruch zur „teilweisen Einreichung“.

Phase 4-A: Transaktionsrücklaufpfad

Was wird überprüft: Transaktionen werden über öffentliche Pfade wie poll_fills verarbeitet, und die SIM kann den ganzen Tag stabil laufen.

Vorgehensweise: Läuft einen halben oder einen ganzen Handelstag lang.
Akzeptanztest: Es wurde kein interner Warteschlangenklassenfehler gefunden.

Phase 4-B: Ursachenbasierte Kategorisierung überspringen

Was zu überprüfen ist: Die skip_reason=-Einträge in den Protokollen können manuell kategorisiert werden (z. B. gate_failed, snapshot_stale).

Operation: Rufe skip_reason= ab.
Akzeptanz: Alle Felder sind vollständig ausgefüllt und ihre Bedeutung ist verständlich.

Phase 5-A: Strategieüberblick

Was zu überprüfen ist: Wenn Split aktiviert ist, bereiten Sie die Ausführung vor; überspringen Sie Snapshots, die ablaufen und Protokolle enthalten.

Vorgehensweise: Setzen Sie zunächst live_trade_split_strategy_prepare=False, um eine Basislinie festzulegen; setzen Sie dann True und konfigurieren Sie live_trade_prepare_lead_seconds und live_trade_strategy_snapshot_max_age_seconds (muss vor qt.run konfiguriert werden).
Akzeptanz: Siehe prepare for schedule/log; snapshot_stale ist erläuternd.

Phase 5-B: Zugangskontrolle aktivieren

Was zu überprüfen ist: warn gibt lediglich eine Warnung aus; block verhindert, dass die Richtlinie im Falle eines schwerwiegenden Fehlers in die Warteschlange gestellt wird.

Operationen: Testen von warn / block in verschiedenen Ebenen; Shell führt gate aus.
Akzeptanztest: block sollte an normalen Handelstagen nicht fälschlicherweise Transaktionen blockieren (verwenden Sie zuerst warn für Graustufentests).

Phase 11 / 5-C: Kartierung, Rotation, Diagnose, Abgleich

Was wird überprüft: Rückbuchung von Brokerkonten, Rotation des Risikoprotokolls, Diagnose von Aufträgen während des Transits und Abschlussabstimmungs-JSON.

Auftragszuordnung — Erfolgreiche Aufträge haben eine broker_order_id; Zählerablehnungen haben eine rejected und der Broker ist leer; Risikokontrollablehnungen haben keine neuen Auftragszeilen, aber risk_log hat einen Wert von ``.<RISK REJECTED> ``
Produkte und Rotation — artifacts sind mit vier Schlüsseln beschreibbar; rotatelogs --days 30 bereinigt abgelaufene *.risk.log.
Diagnose ausstehender Aufträge — DEBUG: run --task diagnose_pending_orders, alle Felder sind ausgefüllt.
post_close — reconcile JSON mit is_ok, failures usw.

IV. Ergänzende Informationen zu live_grid_multi

Multi-target VS + multi_pars: Die Rasterparameter für jedes Ziel werden am ersten Tag sinnvoll initialisiert.
Nachfüllhäufigkeit unter einem Tag: An Tagen mit Rauchentwicklung kann die Nachfülltabelle auf den kleinsten Satz, z. B. stock_1min, reduziert werden.
Akzeptanz: Das Verhalten am ersten Tag ohne offene Positionen entsprach der Beispiellogik; es traten keine NaN-Preisfehler auf.

5. Notebook, das ohne Kopf Rauch ausstößt (optional)

Während der Börsenschließung können die stage*-Funktionen in tests/notebook_trader_headless_script.py innerhalb des Notebooks aufgerufen werden; Details dazu finden Sie in den Skriptkommentaren. Dies kann in Verbindung mit dem manuellen Live-Modus verwendet werden.

VI. Tägliche Arbeitsübersicht

Nach Abschluss der manuellen Smoke-Tests können Sie anhand der folgenden Tabelle schnell abhaken, welcher Testschritt heute abgeschlossen wurde. Jede Zeile entspricht der Stufennummer in Teil 3. Tragen Sie eine Zusammenfassung Ihrer durchgeführten Aktionen ein. Die Prüfkriterien stammen aus den Abnahmespezifikationen der jeweiligen Stufe. Diese Tabelle deckt Roadmap 0 bis 5-C / Stufe 11 ab, mit Ausnahme der Broker/QMT-Integration (siehe Brokerage-Anpassungsschicht und Integration).

Spaltenbedeutungen: Phase ist die Nummer im Fahrplan; Eine Zusammenfassung Ihrer Aktionen wird von Ihnen erfasst; Check-Kriterien sind die Mindestanforderungen für das Bestehen dieser Phase.

Anwendung: Nach Abschluss eines bestimmten Schritts im Smoke-Prozess tragen Sie einen Satz in die Spalte „Aktionszusammenfassung“ ein (z. B. „Gate im Warnmodus passiert“). Wenn das Ziel erreicht wurde, setzen Sie ein Häkchen im Kopf oder auf dem Dokument; andernfalls tragen Sie dies in die Spalte „Schlussfolgerung“ der Protokollvorlage §7 ein.

Bühne	Aktionszusammenfassung	Kriterien zum Ankreuzen
0	Status/Protokolle anzeigen	Die Bootverbindung kann wiederhergestellt werden
1	Standardisierter Ausgang	Normale Freigabe von Ressourcen
2～4-B	Terminplanung und Überspringen	skip_reason, verstehst du?
5-A/B	Schnappschüsse und Zugriffskontrolle	stale/gate ist interpretierbar
11/5-C	Kartierung/Rotation/Diagnose/Abgleich	Siehe die vier obenstehenden Abschnitte.

VII. Vorlage für die Aufzeichnung (Empfohlen)

Nach jedem Rauchsignal werden folgende Daten protokolliert: Versionsnummer, Kernkonfiguration von live_trade_*, Ergebnis von gate, Stichprobe abgelehnter Aufträge, Zusammenfassung von reconcile und Ergebnis (bestanden/ausstehend/blockiert). Diese Daten dienen dem Vergleich am nächsten Handelstag.