シミュレートされたライブ取引手動煙生成ソリューション (live_grid_multi)

ユーザーの皆様、この章は **手動チェックリスト**です。実際の取引日 (または都合の良い時間に) に、リポジトリ サンプル ``examples/live_grid_multi.py` を使用してシミュレートされたライブ取引セッションを実行し、各項目にチェックを入れて、qteasy の動作がドキュメントと一致していることを確認します。

煙検査とは何ですか?新しい船が進水する前の海上試験と同様に、すべての戦略を網羅する必要はありませんが、**修正された例 + 修正されたチェック**を使用して、「機能するかどうか、ログが読み取れるかどうか」を迅速に判断します。このマニュアルは **実際の qt.run + 人間による検証 ** に焦点を当てています。取引時間外には、リポジトリ内のヘッドレス スクリプトをアーキテクチャの回帰に使用することもできます (下記を参照)。

戦略ベースライン: examples/live_grid_multi.py (5-minute VS + multi-mark grid). Maintainers who need to refer to the internal roadmap can refer to the repository .cursor/plans/trader architecture upgrade roadmap_0650f0d5.plan.md (オプション、読む必要はありません)。

ヘッドレススクリプトとの関係

  • tests/notebook_trader_headless_script.py は、Notebook セルで呼び出すことができる段階的なヘッドレス スモーク (5-A/5-B、5-C などを含む) を提供します。

  • このマニュアルは、個人的にライブを起動し、CLI/ログを表示し、ボックスをチェックすることに重点を置いています。

  • 推奨スケジュール: **取引日**はこのマニュアルに従ってください。 **市場閉鎖中**は、ヘッドレス スクリプトを使用して回帰分析を実行します。

I. 環境と前提条件

  1. Python: /opt/anaconda3/envs/py39/bin/python が推奨されます。 pip 経由で qteasy をインストールした場合、作業ディレクトリは examples/live_grid_multi.py を含む任意のパスにすることができます (リポジトリ全体を複製する必要はありませんが、サンプル スクリプトにアクセスできる必要があります)。

  2. 新規口座、オープンポジションなし (古い注文による干渉を避けるため):

    • -n/--new_account <username> は新しいアカウントを作成します。または

    • account_id がすでに存在し、--restart がレコードをクリアする場合は、オープンポジションがないことを確認した後にのみ再開してください。

  3. データ: 分ベースの戦略には、stock_1min などのローカル テーブルが必要です。最初の補充には時間がかかる場合がありますが、これは正常です。

  4. **ログ: sys_log_file_path と trade_log_file_path は書き込み可能です (artifacts で確認してください)。

II.起動コマンドテンプレート

例を含むディレクトリで実行します (アカウントに応じて調整します):

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

注記：

  • コールド スタート: 新しい -n または --restart を作成し、その位置が空であることを確認します。

  • 財務的プレッシャーを避けるために、未知の環境で trade_batch をスケールアップしないでください。

  • 5-C 関連 CLI run --task diagnose_pending_orders を実行できるように、--debug を追加することをお勧めします。

Ⅲ．段階的承認 (各項目にチェックを入れます)

次のステージは、内部ロードマップ 0-5-C / ステージ 11 に対応します。各項目には、この段階での検証内容、動作、および承認が含まれます。

フェーズ 0: ベースライン、ステート マシン、可観測性

確認内容: Trader は正常に起動でき、状態遷移は適切で、ログは「起動 → スケジュール → 重要なタスク」の順序を復元できます。

  • 操作: CLI/ログのステータス (停止→スリープ/実行中など) とキューに登録されているタスクを観察します。

  • 受け入れテスト: 原因不明のデッドロックはありません。完全な起動タイムラインを再構築できます。

フェーズ 1: 標準化された終了

確認内容: リソースは通常の停止/終了後に解放され、ブレークポイントやログに異常な切り捨てはありません。

  • 操作: シェルを使用して通常どおり終了します。プロセスを強制的に強制終了しないでください。

  • 受け入れテスト: ゾンビ スレッドはありません。完全なログ。

フェーズ 2: タスクのスケジュール設定とスキップ

確認事項: 非同期の価格上昇と戦略タスクには明確な境界があります。タスクがスキップされると、ログには読み取り可能な skip_reason が含まれます。

  • 操作: acquire_live_price や run_strategy などのスケジュールを順守してください。

  • 受け入れ: 異常/スキップは説明可能であり、統計的に有意です。

フェーズ 3: スケジュールと進捗状況

確認内容: スケジュールは同じ構成で再現できます。ディスクから起動したときの「再実行」動作はドキュメントと一致しています。

  • 操作: 同じ日の 2 つの重要な瞬間を比較するか、取引中に 1 つを開始します。

  • 受け入れ: スケジュール出力は再現可能です。

フェーズ 3.5: トランザクションの記録と支払いの一貫性

検証内容: 取引後、現金/ポジション/注文が重複して差し引かれることなく一致している必要があります。

  • 操作: 少なくとも 1 回のシミュレートされたトランザクションの後で台帳を検証します。

  • 承諾：「部分提出」に矛盾はありません。

フェーズ 4-A: トランザクションのリターン パス

検証内容: トランザクションは`poll_fills` などのパブリックパスを通じて消費され、SIM は一日中安定して動作します。

  • 操作: 半取引日または丸一日実行します。

  • 受け入れテスト: 内部キュー クラス エラー スタックが見つかりませんでした。

フェーズ 4-B: 原因ベースのバケット化をスキップする

確認内容: ログ内の skip_reason= は手動で分類できます (例: gate_failed、snapshot_stale)。

  • 操作: skip_reason= を取得します。

  • 承認: すべてのフィールドが入力されており、その意味が理解できます。

フェーズ 5-A: 戦略のスナップショット

確認事項: 分割が有効な場合は、実行前に準備を行ってください。期限切れでログのあるスナップショットをスキップします。

  • 操作: まず、live_trade_split_strategy_prepare=False を設定してベースラインを確立します。次に、True を設定し、live_trade_prepare_lead_seconds と live_trade_strategy_snapshot_max_age_seconds を構成します (qt.run の前に構成する必要があります)。

  • 承諾: スケジュール/ログの準備を参照してください。 snapshot_stale は説明です。

フェーズ 5-B: アクセス制御のアクティブ化

確認内容: warn は警告のみを発行します。 block は、重大な障害が発生した場合にポリシーがキューに入れられるのをブロックします。

  • 操作: 異なる層で warn / block をテストします。シェルは`gate`を実行します。

  • 受け入れテスト: block は、通常の取引日の取引を誤ってブロックしてはなりません (グレースケール テストには、最初に warn を使用します)。

フェーズ 11 / 5-C: マッピング、ローテーション、診断、調整

検証内容: 証券口座のライトバック、リスク ログのローテーション、輸送中の注文の診断、およびクロージング調整 JSON。

  1. 注文マッピング — 成功した注文には broker_order_id が付いています。カウンター拒否には rejected があり、ブローカーは空です。リスク管理の拒否には新しい注文明細はありませんが、risk_log には `.<RISK REJECTED> ` があります

  2. プロダクトとローテーション — artifacts writable with four keys; rotatelogs --days 30 cleans up expired *.risk.log。

  3. 未決注文の診断 — デバッグ: run --task diagnose_pending_orders、すべてのフィールドが完了しています。

  4. post_close — is_ok、failures などを含む reconcile JSON

IV. live_grid_multiに関する補足情報

  • マルチターゲット VS + multi_pars: 各ターゲットのグリッド パラメーターは初日に合理的に初期化されます。

  • サブ日頻度補充: 煙が発生する日の場合、補充テーブルを stock_1min などの最小セットのみに減らすことができます。

  • 受け入れ: オープンポジションがない初日の動作は、サンプルロジックと一致していました。 NaN 価格エラーはありませんでした。

5. ヘッドなしで煙を発するノート (オプション)

市場閉鎖中に、tests/notebook_trader_headless_script.py の stage* 関数をノートブック内で呼び出すことができます。詳細については、スクリプトのコメントを参照してください。これは手動ライブ モードと組み合わせて使用​​できます。

VI.日々の作業サマリーシート

手動スモークテストが完了したら、以下の表を使用して「今日のテストのどのステップが完了したか」をすぐに確認できます。各行は、上記のパート 3 のステージ番号に対応します。 **アクションの概要**は実際に実行されたとおりに入力する必要があり、**チェック基準**はその段階の受け入れ仕様に基づいています。この表は、ブローカー/QMT 統合を除く、ロードマップ 0 から 5-C / ステージ 11 をカバーしています (仲介アダプテーション層と統合 を参照)。

列の意味: ステージ はロードマップ番号です。 あなたの行動の概要**はあなたによって記録されます。 **チェックマーク基準 は、このステージに合格するための最低要件です。

使用方法: スモークプロセスの特定の段階を完了した後、「アクションの概要」列に文章を書き込みます (例: 「警告モードでゲートを通過しました」)。目標が達成された場合は、心の中で、またはコピーのボックスにチェックを入れてください。目標が達成されなかった場合は、§7 記録テンプレートの「結論」列に記録します。

ステージ

アクションの概要

チェックマークの基準

0

ステータス/ログの表示

ブートリンクは復元できる

1

標準化された出口

リソースの通常の解放

2～4-B

スケジュールとスキップ

スキップ理由、わかりますか？

5-A/B

スナップショットとアクセス制御

古い/ゲートは解釈可能です

11/5-C

マッピング/ローテーション/診断/調整

上の 4 つのセクションを参照してください。

VII.レコードテンプレート (推奨)

各発煙信号の後に、バージョン番号、コア live_trade_* 構成、gate 結果、拒否された注文サンプリング、reconcile 概要、および結論 (合格/保留中/ブロック) を記録します。これは翌営業日の比較です。

関連資料