🛠️開発記録#287(2025/8/22)本日の開発ログ

今日はEVを取る直前まできたbotが多かったという印象です。

また、AIに思考させずに開発作業と現状報告だけさせるという方針に切り替えたため、開発がいつもよりサクサク進みました。無駄な作業や検証が減ったので、結果的に実装できたことも増えたという感じ。AIを使っての開発もだいぶこなれてきた感があります。

とはいえ、勝てるbotを量産するというフェーズには達していないので、今後もコツコツと開発を続けていきます。

今日は４つだけしっかり取り組んだので、それらの開発ログを残しておきます。

AIに提案させないって大事。

— よだか(夜鷹/yodaka) (@yodakablog) August 22, 2025

botのヘルス監視未起動、ようやく片付きそう。これ、回しておかないと致命的な損害に繋がるやつだから、優先度あげて開発タスクに入れていたけど、それが功を奏した感じ。
ただ動くだけのbotは怖すぎる。

— よだか(夜鷹/yodaka) (@yodakablog) August 22, 2025

MMbot：進捗サマリ（ハイライト）

• 計測／Exporter
  • REGを唯一化し、/metrics = generate_latest(REG)に統一。
  • 旧 start_http_server/重複REGを全廃。9106ポートの競合も解消。
  • health_probeを本番Exporter化（:9106）。mm_health 3点（alive / last_error_code / last_success_seconds）安定。
  • **ヘルス番兵（health_sentinel）**を常駐：stale > 35s でエンジンを強制停止。
• 安全性／運用ガード
  • Sender直前のRateLimitガード：used_weight_1m ≥ 1100 → HALT 60s / orders_10s ≥ 45 → HALT 10s。
  • 終了時キャンセル保証：disable_new_orders → cancel_all_open_orders → wait_all_cancels を SIGINT/SIGTERM/atexit で強制。
  • ACK/Fill 去重をINSERT OR IGNOREで統一。
• 監視系の事故源排除
  • IntegratedPerformanceMonitor / EmberLatencyMonitor を No-Op shimに置換（モニタは後で戻す方針）。
  • 旧REG・旧モニタの残存インポートを撲滅（重複メトリクスも解消）。
• 実行系の整流
  • OrderBookManager 参照を辞書型（ob_mgrs[symbol]）に統一し subscript エラー解消。
  • runner.run_all_pairs() を停止条件付きループ化（ENVで調整）：
    • CANARY_ATTEMPT_BUDGET（例：5本）で自動停止。
    • ENGINE_IDLE_SLEEP_MS / ENGINE_ERR_BACKOFF_MS でCPU焼き・例外後のバックオフ制御。
• 運用方針の収束
  • **ノブは1つ（MAKER_OFFSET_BP）**で回す。TTL/サイズは固定。
  • Canaryは最小ロット×5本×本命時間帯2スロット → KPIで採点。

現在の状態（事実ベース）

• /metrics は health_probe（:9106）単一で稼働、番兵も常駐可。
• エンジンは起動〜停止の制御系は正常（finallyで板掃除保証）。
• 直近の詰まりは run系が早期終了しがち → ループ化パッチを適用済（ENVでバジェット管理）。
• 取引メトリクス（attempt/ack/fill）がまだ安定発火していない時間帯がある（ロジック側のGO判定/WS購読面を個別確認中）。

KPI（合否ライン）

• AUTO→GO ≥ 30%
• GO→FILL ≥ 60%
• median(realized_edge_on_quoted_bps) ≥ fees + slip_p75
• 付随チェック：p95(req→ack) ≤ 400ms、reject{PRICE|LOT|MIN_NOTIONAL} ≤ 1%
• ヘルスは常に：time() - last_success_seconds(com) ≤ 35s

いま残っているリスク/課題（短く）

• /metricsの単一性破壊：9106に別Exporterが湧くと番兵が誤監視（起動時にkill→probe起動→3点確認の順を厳守）。
• attemptが増えない時：送信/ACK/Fillの .inc() 配線漏れか、ゲート常時CLOSEが典型。
• WS/OrderBook：購読未起動や参照ミスマッチがあると end_decide_phase 以前で無仕事→アイドル化。

次のアクション（10〜20分のチェックリスト）

1. プレフライト（確実化）
   • pkill run_engine / health_probe / health_sentinel → lsof -ti :9106 | xargs -r kill -9
   • PROMETHEUS_MULTIPROC_DIR を初期化 → health_probe 起動 → 3点確認。
   • health_sentinel 起動。
2. ENVセット（canary用）
   • SECRETS_PATH=secrets/prod / TTL_MS=600 / MAKER_OFFSET_BP=2
   • CANARY_ATTEMPT_BUDGET=5 / ENGINE_IDLE_SLEEP_MS=250 / ENGINE_ERR_BACKOFF_MS=1000
   • MONITOR_DISABLED=1（No-Op継続）
3. canary起動 → 自動停止 → KPI採点
   • 起動：python -m mm_bot.cli.run_engine --site com ...（nohup推奨）
   • 採点：attempt/ack/fill を /metrics から算出（3本のKPI）。
4. 未達なら“ノブ1個だけ”
   • GO→FILL < 60% → MAKER_OFFSET_BP += 2
   • p95(req→ack) > 400ms → TTL_MS += 150（この変更のみ）
   • unknown > 1%/recon ≠ 0 → 三位一体ログ（pred/quoted/realized/fees/slip）の欠損を先に修正。
5. （attemptが0のときだけ）配線クイック検査
   • git grep 'mm_attempt_total\.inc'（送信直前）
   • git grep 'mm_ack_total\.inc'（ACKハンドラ）
   • git grep 'mm_fill_total\.inc'（Fill処理）

48hの見取り図

• Day1：COMで2スロット canary → KPI達成なら同時間帯でサイズ1.5×／未達ならオフセット+2で再canary。
• 並行：JP疎通（/time=200継続）の確保。WS購読とゲート発火頻度の観測（ok_mm_mm|ok_mm_tk）。
• Day2：EVの芽が見えた時間帯を固定し、連続2ラウンドでの安定性確認。

MMbot：開発方針（原則）

• KPIは入場券：達成＝「検証に進める権利」。必ず再現性試験を挟んでからサイズUP。
• ノブは常に1個：因果維持（まず MAKER_OFFSET_BP、必要時のみ TTL_MS）。
• 副作用一致の徹底：triad（quoted/fees/slip/realized）× fills台帳でダブル仕訳・差分監視。
• “Botが喋る”ログ：意思決定を1行で説明し、そのキーが /metrics にも映る（言語＝数）。

---

48時間プラン（Canary通過→再現性確保）

T+0〜4h：COM 2スロット canary

• ノブ：MAKER_OFFSET_BP=+2（TTL_MS=600固定、サイズ最小）
• KPI：AUTO→GO ≥30% / GO→FILL ≥60% / median(realized) ≥ fees + slip_p75
• 未達：オフセット+2のみで同条件再試。p95(req→ack)>400ms のときだけ TTL_MS+=150（単独変更）

T+4〜24h：再現性試験（3ケース）

1. 同時間帯・同銘柄・最小ロット
2. 近接時間帯（±2h）
3. 流動性階層違い（厚い/薄いペア）
   → 3/3合格でロット1.5×。1でも落ちたらノブ据え置きで原因潰し。

T+24〜48h：EV窓の固定化

• ダッシュボードにゲートCLOSE理由、rate_guard増分、p95(req→ack)、reject率を並置
• triad×fills差分bpsのメトリクスを追加し、乖離>2bpsで警告
• JP疎通（/time=200≤35s）をWARP/東京VMで確保（本運用前提）

---

1週間プラン（ミドルロットへ）

• サイズ階段：1.5× → 2× → 3×（各段、同時間帯で2ラウンド連続＋なら昇格）
• パターン拡張：ボラ/トレンド局面タグ（quiet/trending/spiky）を約定ログに付与し、局面別成績を計測
• イベント限定MMの分岐：BRQ/OFIイベント時のみ TTL短（250–500ms）、裏置きONのブランチを試験
• 安全弁の拡張：
  • 日次DD上限bpsで自動STOP（/metricsで閾値露出）
  • max_position超でHALT→全キャンセル→再起動クールダウン（5–10分）

---

2〜4週間プラン（設計の強化）

• **ヘッジ付きMM（現物+先物/Perp）**のPoC：在庫DD抑制＆実効手数料<10bps狙い
  → 条件：need_bp < 2*maker を継続
• リベート/低fee会場への横展開：スプレッド−2*fee−滑り−逆行 の中央値が安定プラス
• 監視No-Opの段階復帰：
  • まず EmberLatencyMonitor を読み出しのみで再有効化（メトリクス生成はNo-Op継続）
  • 落ちないことを確認後に 低頻度の集計だけON（再帰防止のユニットテスト付）

---

具体タスク（すぐ入れる項目）

1. ダブル仕訳メトリクス
   • mm_realized_ledger_diff_bp（Gauge）：Σtriad.realized_bp - Σledger_bp を1分足で更新
   • 閾値：|diff|>2bps で mm_ev_mismatch_total（Counter）をインクリメント
2. ログ1行フォーマット（送信/見送り）

WHY=ok_mm_mm REASON=spread+3bp TTL=600ms PRED=+18bp QUOTED=+12bp FEES=8bp SLIP=p75:3bp

WHY=skip REASON=rate_guard:used_weight_1m=1123 TTL=600ms

• KEYはそのまま /metrics のラベルに反映（可観測＝言語化）

3. ゲート理由の可視化
   • mm_ev_gate_close_total{reason="diag|rate_guard|need_bp|insufficient_depth|ttl"} を増加
   • ダッシュボードにCLOSE割合（Stacked）と勝率/EVを並べる
4. 再現性試験テンプレ（md）
   • スロット、ノブ、KPI、結果、次アクションを1行で記録できる表を用意
5. runbookの自動化スクリプト
   • bin/preflight.sh：9106クリーン→probe起動→“3点”確認→sentinel起動
   • bin/run_canary.sh：ENVセット→エンジン起動→試行数監視→停止→KPI出力

---

品質ゲート（止める基準）

• ヘルス：time() - last_success_seconds(com) > 35s → 番兵が即停止
• 計測：mm_ev_mismatch_total 増分発生 → 次のスロットは禁止（triad/ledger修正が先）
• 運用：GO→FILL < 40% を2スロット連続 → ノブ増やさず撤退またはピボット

---

ピボット順（No-Go時）

1. イベント限定MM（BRQ/OFI短TTL）
2. ヘッジ付きMM（現物+先物/Perp）
3. リベート会場MM（手数料優位の所へ移管）
4. クロス会場の薄板＋掃き（CEX/DEX）

---

この方針で**「入場券（KPI）→再現性→サイズUP」**を段階的に踏めば、事故らずミドルロットへ到達できる。
直近は ダブル仕訳メトリクス＋ログ1行化＋再現性試験の運用化 を先に入れる。

CEX/DEX arb bot📊 開発進捗状況まとめ

1. 初期フェーズ（効率性スコアと拡張）

• 状況
  • 多数銘柄（30〜40以上）に展開し、「成功率100%」「効率性スコア100点」という数値が出ていた。(異常値)
  • Canary・動的調整・時間窓最適化などの仕組みを形式的に実装。
• 問題
  • 効率性スコアが P&Lと切断。
    → 実際に負けていても「速さ＝正義」で100点。
  • 成功率判定が「実行できたら成功」で緩すぎた。
  • 収益集計が 212銘柄 / 10,465回 という現実離れした数値。

---

2. 問題の発覚フェーズ（指標の破綻）

• 発覚したリスク
  1. 効率性スコアの破綻
     • 実行回数や時間窓が小さいほど「低評価」になる歪んだ設計。
     • 実P&Lと無関係。
  2. 動的調整のスラッシング
     • 調整率100%。
     • deadband/dwell未実装 → 常にパラメータを動かし続ける状態。
  3. 収益集計の不整合
     • 窓重複・重複カウント。
     • fill=成功判定という甘い基準。
• 致命的リスク
  → 本番投入した瞬間に資金を溶かす「合格」表示が出る典型パターン。

---

3. 修正フェーズ（数字を正しい基盤へ）

• 修正内容
  1. 真のKPI算出スクリプト作成
     • AUTO→GO、GO→FILL、EV_bps_weighted、p90遅延、unknown率をログから抽出。
  2. 効率性スコアをP&L主導へ差し替え
     • true_efficiency_calculator.py で「EVを単位リソースで最大化」する設計へ。
  3. 動的調整の安定化
     • deadband、dwell、step、clamp を導入。
  4. 集計の整合性確保
     • ユニークキー化・窓重複の排除。
  5. No-Goゲート実装
     • KPI未達なら自動縮小／停止。
• 修正後の数値（直近24h）
  • AUTO→GO率: 35.0%（目標 ≥30% ✅）
  • GO→FILL率: 0.0%（目標 ≥60% ❌）
  • EV_bps_weighted: +10.67（目標 ≥0 ✅）
  • p90遅延: 150ms（目標 ≤300ms ✅）
  • unknown率: 0.5%（目標 ≤1% ✅）
  • 効率性スコア: 0.180 → 0.370（目標 ≥0.70 ❌）
  • 動的調整頻度: 9〜10回/24h（目標 ≤3回/h ❌）

---

4. 現在の状態

• できたこと
  • 数字の「虚偽の成功率」から「現実の失敗（GO→FILL=0%）」を暴き出した。
  • EVがプラスかどうかの判定を導入。
  • 指標のゲーム化を解消。
  • 動的調整は抑制ロジックを導入済み。
• まだできていないこと（課題）
  1. GO→FILL率改善
     • Canary結果処理が壊れており、fill率を正しくカウントできていない。
  2. effスコア向上（0.370→0.70以上）
     • EVプラスを維持しつつ効率を上げる必要あり。
  3. 動的調整の安定化確認
     • deadband/dwellは入れたが、まだ調整頻度が高い。
  4. 24hダッシュボード再構築
     • KPI3本柱を軸に運用ゲートを張る必要あり。

---

🎯 本日のゴール（現実的ターゲット）

1. GO→FILL ≥ 60% を Canary 実行で確認（最小ロット×5本×2枠）。
2. eff ≥ 0.70 を達成（EVプラスを維持しつつ）。
3. 調整頻度 ≤3回/h をログで確認（deadband/dwell効果の検証）。

---

👉 現在の開発は「虚偽の成功」から「現実の失敗」を正しく可視化するフェーズを完了。
ここからは GO→FILL率の改善＝収益化に直結するボトルネック を突破する。

🎯CEX/DEX arb bot原則（これだけ守る）

1. KPI三本柱で合否：AUTO→GO ≥30%、GO→FILL ≥60%、EV_bps_weighted ≥0（notional重み・fees/slip込み）
2. 安全弁が常に先：No-Goゲート（縮小/停止）→ その後に拡張
3. 1ノブ検証：depth / ts_skew / miss_2nd / size は同時に触らない（因果の保存）

---

🗺️ 今後の開発方針（段階別）

0. リカバリ（本日中）

• ダッシュボード再固定（5m/15m窓）：
  AUTO→GO, GO→FILL, EV_bps_w, p90_latency, recon_mismatch, unknown_ratio, DD%
• No-Goゲート稼働：
  • EV_bps_w<0 2連続 → lot 50%縮小
  • recon_mismatch>0 2回 → 即HALT
  • unknown_ratio>1% 3回 → 発注休止＆点検
• 動的調整の鎮静化：deadband±10bps/±30ms、dwell 10分、lot ±0.25×／depth ±5ms、lot 1.0–2.5×・depth 20–40msにクランプ
• Canary修復：結果パーサを直し、失敗の質ログ（reject/timeout/slippage/2nd_leg_fail/cancel_mismatch）を最小粒度で計上

本日のゴール：GO→FILL ≥60%（最小ロット×5本×2枠）、EV_bps_w ≥0を2連続、調整頻度 ≤3回/時

---

1. 来48時間（安定化スプリント）

• リソース浪費マップ（どこで捨ててるか）
  • 1st/2nd leg 別の p90/p99、reject_reason、timeout率、slippage分解（見積 vs 実績）
  • 1枚テーブル：step → 失敗率 → 失敗コストUSDT → 改善ノブ
• 1ノブ実験テンプレ（45分=1ノブ）
  • depth: 25→30ms or 30→25ms
  • ts_skew: 500→350ms
  • miss_2nd: 0↔1
  • プロトコル：最小ロット×5本×2時間帯, Go/No-Goで即判定 → 合格なら同時間帯のみ1.5×、未達ならロールバック
• 動的調整の“記録”を強化
  • pre/post KPI、Δlot/depth、adjust_reason、no-op理由 を必ず出力（“調整しない勇気”の可視化）

---

2. 1週間（拡張の前に収益の芯を太くする）

• 銘柄配分の再最適化（トップダウン）
  • 直近24hの EV_usdt_per_min と keep(GO→FILL) の2軸で A/B/Cバケット化
  • 予算配分：A=60%、B=30%、C=10%（Cは観測のみ）
• 時間帯ポートフォリオ
  • 時間帯×銘柄のヒートマップから上位窓だけ運用（下位窓は監視）
• 実運用に耐える異常系
  • API失敗率上昇・遅延悪化・極端スリッページ時に 自動で観測モードへ（発注停止）

---

3. 2週間（拡大フェーズ）

• サイズ段階拡大：合格窓でのみ lot を 1段階ずつ増加（1.0×→1.25×→1.5×…）
• マルチ銘柄の“面”拡張：Aバケットから横展開、Cは除外
• 回帰防止：赤テスト
  • test_go_to_fill_regression、test_ev_bps_pipeline、test_adjust_dwell_deadband、test_no_go_gate_triggers

---

🔎 ログ/メトリクス設計（増やし過ぎない最小セット）

カウンタ

• arb_auto_go_total{why,sym,tap}
• arb_go_to_fill_total{sym,tap}
• recon_mismatch_total

サマリ

• ev_bps_sum / notional_sum（加重EV算出用）
• fees_bps_exec、slip_real_bps

失敗の質（ラベルは限定）

• fail_total{kind in [reject, timeout, 2nd_leg, cancel_mismatch, slippage_exceed] , sym}

---

🧪 日次オペ（60分ループ・雛形）

1. 状態確認（10分）
   KPI三本・No-Go・調整頻度・DD% を見る
2. 1ノブ実験（45分）
   変更→canary→KPI合否→サイズ調整/ロールバック
3. ランブック記録（5分）
   変更/期待/結果/採否 を1行で Run Manifest に追記

---

🧯 失敗時の分岐

• GO→FILL <60%：depth→ts_skew→miss_2ndの順で1ノブのみ動かす
• EV_bps_w <0：即 lot 半減、原因が slippage なら size戻す前に depth/ts_skew を再調整
• 調整頻度>3回/h：deadband×2、dwell×1.5、サイズ据え置き

---

✅ 休憩明けのTo-Do（貼ってそのまま実行）

• /metrics 生存確認 & KPI三本が5m/15mで出ている
• Canaryパーサ修正 → GO→FILL ≥60% を最小ロットで確認
• 動的調整ログに no-op理由 と pre/post KPI が出ている
• No-Goが 自動発火 することをテスト（安全弁の動作確認）

---

この方針で“数字で勝っている”状態に戻しつつ、無駄撃ちを削減 → サイズ段階拡大へ繋げる。

オンチェーン清算スナイプbot：開発進捗状況

1. インフラレイヤー（Exporter / Prometheus）

✅ 成功したこと

• Exporter
  • simple_exporter.py を起動・再起動できる状態を確立。
  • exporter_heartbeat・live_exec_attempt_totalなどの基本メトリクスが正しく /metrics に出力。
  • gain/loss メトリクス（hl_gain_usd_total_finalized_total / hl_loss_usd_total_finalized_total）を追加し、正しくPrometheusに供給。
  • /fill webhook を導入し、外部からPnLをPOSTする仕組みを確立。
• Prometheus
  • 起動フローを絶対パス指定に統一し、.prom_data ストレージパスも固定。
  • --web.enable-lifecycle 有効化で /reload による動的ルール更新を実現。
  • status/config APIから実際に読み込まれたYAMLを確認し、設定の齟齬を解消。

❌ 課題と対処

• ポート競合（9106） → プロセスkill後に再起動、正常化。
• Prometheusルール未読込 → 絶対パス化・スモークテストルールを追加 → 読込成功を確認。
• スクレイプ成功だがメトリクスが空 → Exporter停止が原因 → 再起動で復旧。

---

2. ルールレイヤー（min_core / min_gate / EV生成）

✅ 成功したこと

• min_core
  • hl:live_attempts_1m、hl:den_incl_1m、hl:p95_submit_inclusion_ms_1m を生成、素材が正しく動作。
• min_gate
  • 各ゲート（g_ev, g_p95, g_fill, g_den, g_up）の0/1正規化が成功。
  • 「0/1正規化 → 合計 → しきい判定 → ゼロ埋め」の3段構えで hl:adoption_gate_ready_boot がnullを返す問題を解消。
  • adoptionゲートが実際に 1 を返す状態に到達。

❌ 課題と対処

• == bool 5 が null になる問題
  → >= bool 5 に変更、一時解決。ただし依存関係で再度null発生。
  → 評価順序を固定し、二段ゼロ埋めで完全解決。
• EV系列（hl:ev1m_abs_final）が空
  • increase(...[1m]) が常に0になる → 窓の位相ズレが原因。
  • 対処：一時的に [2m] へ拡張、さらに rate×60 版を保険として導入。
• ラベル不一致
  • gain/lossには job と instance が付与されており、他素材と突合できなかった。
  • 対処：sum without (instance, job) で正規化、(symbol,side,reg) のみに揃えるルールを新規作成。

---

3. 計測レイヤー（PnL / EV算出）

✅ 成功したこと

• gain/loss供給の配線: on_fill_finalizedから hl_gain_usd_total_finalized_total / hl_loss_usd_total_finalized_total に反映する仕組みを実装。
• テストループ（TEST_GAIN）: 5秒ごとに+0.01USDを加算 → 動作確認済み。
• /fill webhook: 手動でPnLをPOSTし、Prometheusに反映できることを確認済み。
• Prometheus取り込み: exporterの値がPrometheusに正しく取り込まれていることを確認。

❌ 課題と対処

• TEST_GAINを本番regに載せてしまうと偽陽性リスク
  → 本番前に必ず停止、隔離済み。
• increase()が0のまま
  → scrape_intervalと窓のミスマッチ → [2m] に拡張して捕捉へ。
• EVが依然空
  → ラベル不一致を特定、sum without(instance,job) で正規化するルールを導入。

---

4. クリック実行レイヤー（取引発火 / EV反映）

✅ 成功したこと

• IOCノーフィル潰し戦略を設計
  • size = 0.002（最小の2倍）
  • price = best_ask × (1+20〜50bps)
  • IOCノーフィルを段階的に潰す仕組みを定義。
• on_fill_finalizedログ追加
  • fill発生時に [FILL_FINALIZED] symbol/side/reg pnl=... を出力、可視化。

❌ 課題と対処

• CLI (hl.cli fire-once) が存在しなかった
  → 代替として /fill webhook を導入し、最小EVシナリオを実行可能に。
• fill未発生でEV空
  → IOCのprice/sizeを見直し、確実に約定させる方針を明確化。

---

📌 現在の到達点

• インフラ：Exporter・Prometheusとも安定稼働、TEST_GAINも隔離済み。
• ルール：min_core/min_gateは完全動作、adoptionゲート点灯成功。
• 計測：gain/loss供給ルートとPrometheus取り込みはOK、ラベル不一致修正パッチを適用中。
• クリック：/fill webhookでPnL反映まで通せる状態。
• 残課題：hl:ev1m_abs_final が依然として空 → ラベル正規化ルールの適用確認と1クリックEVの最終検証。

---

🎯 次の最短ステップ（稼ぐまで）

1. ルール修正反映
   • sum without(instance,job) に置換済みの hl:ev1m_abs_final を60〜90秒監視。
   • 数値が出れば Adoption Docket に記録。
2. 極小クリック実行
   • IOC 0.002 SOL, +20bps。
   • fill確定ログ [FILL_FINALIZED] を確認。
3. EV確認
   • hl:ev1m_abs_final{SOL,BUY,regA} に値が出れば合格。
   • pass_flag=1 条件（EV>0 && p95<=350 && has_live=1）で採否判定。

---

✅ ここまでで「ゲート点灯 → クリック → EV確定」までのラインは、残り1パッチ（ラベル正規化EVルール）を適用すれば通せるところまで到達している。

オンチェーン清算スナイプbot：今後の開発方針

1. 短期（〜48時間）：収益確認フェーズ

• 目的: 「EVが数値で出る」ことを証明する（収益の可視化を最優先）。
• やること
  • ルール・ラベルは固定（触らない）。
  • 極小クリック→[FILL_FINALIZED]ログ→EV確認を必ず通す。
  • Adoption Docket に実測値を追記し、pass/failを定量化。
• 禁止事項:
  • Prometheusのルール改造、Exporterラベル改造（事故率高）。
  • TEST_GAINを本番ラベルに混ぜる。

---

2. 中期（〜1週間）：自動化と5分窓回帰

• 目的: 手動チェックを排除し「回すだけでEVが出る」状態を確立。
• やること
  • 「点灯したら即クリック」の発火スクリプトを追加。
    • adoption_gate_ready_boot=1 → fire_once → /fill → CSV追記。
  • EV系列を1m→5m窓へ復帰、閾値も本番仕様（den≥300, has_live≥30, fill率≤0.10）に戻す。
  • 最低1日単位で 「日次ネットEV≥0」 を評価。
• 成果指標:
  • 日次で +EV のラウンドが確認できるか。
  • CSVログが連続して更新されるか。

---

3. 長期（〜1ヶ月）：運用・拡張フェーズ

• 目的: 収益が安定する基盤を整え、複数戦略に拡張。
• やること
  • レッドライン監視をコード化（レジャー≠メトリクス / p95遅延 / fill率悪化）。
  • 5分窓→日次→週次へとKPIを積み上げ、稼働率と勝率を可視化。
  • 新しいreg（戦略・シンボル）を追加し、複数Botを並行検証。
  • ダッシュボードは後回し、収益が安定してから。

---

🎯 開発優先順位の再定義

1. EVを数字で出す（ゼロで飢え死にしない）
2. クリック→EVの自動連動（人力チェックを消す）
3. 5分窓・本番閾値での安定運用
4. 複数戦略の展開 & 収益比較

---

✅ まとめ

• 今の段階でインフラは「十分以上」。もう Prometheus や Exporter を触る必要はない。
• 次は「収益で語る」ために クリック＆EV突合の反復 に集中。
• 最初の1行でもEVがDocketに載れば、それが開発の分水嶺。
• そこからは「自動化→5分窓→日次EV評価→戦略拡張」の一本道。

ショート系bot： 開発進捗状況

🎯 全体目標

• 最短でP/L>0を実証すること。
• 手順：実Fill取得 → EV確定（net EV≥0観測） → 日次ネットEV≥0運用。
• そのための基盤（監視・ガード・昇格/縮退・通知）を整備してきた。

---

1. 基盤構築フェーズ（完了）

• Exporter / Prometheus連携
  • メトリクス統一（REG一本化、:9106エンドポイント固定）。
  • gain/loss カウンタ配線済み（fill確定時にUSD集計）。
  • EVメトリクス（hl:ev1m_abs_final）を確認可能に。
• Canary起動フロー
  • Preflight（ゼロ点確認: inflight=0, samples>0, staleness≤100ms）。
  • 最小ロット / 並列=1 で起動 → 10分受け入れチェック。
  • 昇格条件/縮退条件を自動制御（size×1.25, 並列+1 / size×0.7, 並列-1）。
• Go/No-Go判定
  • fill≥0.50 ∧ ev_net_5m≥+3bps ∧ timeout/orders<0.10 ∧ staleness95≤100ms ∧ no_touch≤0.40
  • No-Goは即inactive化、再開は2窓連続Go。
• Cross2ガード
  • AND固定（sell_flow>0.55, cross_ticks≥2, cum_bid_base≥1.2×qty）。
  • timeout/orders>0.10 or ev_markout150ms_5m≤0 → 自動停止。

---

2. 検証フェーズ（完了）

• 10分受け入れチェック
  • ACCEPT10 ok arms=[...] ev5m=+Xbps inflight=0 skip=0 出力。
  • Slack通知連動可能。
• 60分スプリント
  • PRECHECK / ACCEPT10 / RUN10 診断を1行サマリで出力。
  • ログ例：

PRECHECK ok samples_rate>0 staleness95≤100 inflight=0 inv=ok
ACCEPT10 ok arms=[cross1_A,cross2] ev5m=+4.1bps inflight=0 skip=0
RUN10 ok ev5m=+3.6 fill=0.58 cap=on drift=stable arms=[cross1_A,cross2] inv=ok stall_p50=420ms

• 評価システム
  • 24h: avgEV_net≥+2bps ∧ 成功率≥60% → CONTINUE
  • 72h: 連続ネガティブ/勝ち腕ゼロ/サンプル不足70%超 → FREEZE
  • アクション: CONTINUE / SHRINK / FREEZE_TAKERS / EMERGENCY_STOP
• 閾値調整
  • θ_evt, θ_conf の自動調整（ドリフト検出、履歴追跡）。

---

3. 実運用準備フェーズ（完了）

• 統合設定
  • .env.productionで環境変数を一括管理。
  • production_config_integrator.pyにより統合設定ファイル生成。
• 監視・アラート
  • 当初：Slack / PagerDuty / SMTP の3チャネル必須設計。
  • 監視アラートシステム：健全性スコア算出（0.92/1.00）、異常時通知。
• 本番デプロイシステム
  • 6フェーズ自動化（Preflight → Init → Config → Monitoring → Canary → Verify）。
  • 自動ロールバック機能。

---

4. 方針転換：Slack一本化（最新）

• 理由
  • まだ収益化の目処が立っておらず、防御を固めすぎると前に進めない。
  • まずは実Fillを取りEV検証に進むことが優先。
  • PagerDuty/SMTPは保留、Slack一本で通知を集約。
• 仕様変更
  • Preflight合格条件：Slack疎通のみ必須。
  • クリティカル通知：ACCEPT10 ng / invariant破綻 / ramp停止 → Slackに@here。
  • デッドマンHB：5分ごとにSlackへハートビート送信。
  • ログは軽量に ./logs に保存。
• 運用手順
  1. .env.production に Slack Webhook 実値設定。
  2. Preflight: Slack疎通確認。
  3. Canary起動（最小ロット）。
  4. 10分受け入れチェック（Slackに合否通知）。
  5. 最初の実Fill取得。
  6. Prometheusで hl:ev1m_abs_final > 0 を確認 → EV確定。

---

5. 現在の到達点

• ✅ 基盤システム：実装済み（Exporter, EV, Canary, ガード類）。
• ✅ 受け入れチェック：Slack通知と連動可能。
• ✅ 統合設定 / デプロイ：完成済み。
• ✅ 監視アラート：Slack一本化に仕様変更済み。
• ❌ 最初の実Fill取得：未実行（ここが次のゴール）。

---

6. 次のステップ（最短でP/L>0へ）

• Slack一本のPreflight実行

export ENVIRONMENT=production
python -m src.infra.production_deployment_system --preflight-only

• 本番Canary起動（最小ロット）

./run_canary_with_accept10.sh --symbol BTCUSDT --mode mainnet --size 0.01 --parallelism 1

• Slack通知でACCEPT10合否確認
  • OKなら実Fillを待つ。
  • NGなら縮退。
• PrometheusでEV確認
  • hl:ev1m_abs_final > 0 を確認できれば「EV確定」。
• その後：連続2窓Goで昇格 / 拡張通知チャネル導入。

---

✅ 総合評価

• 進捗率：80〜85%（最初の実FillとEV確定を残すのみ）。
• 設計バランス：最初は防御寄り（多チャネル通知）、現在は攻撃寄り（Slack一本化）にシフト。
• 勝ち筋：まず「EV確定」を取ることが最大の分岐点。そこから勝率・収益性評価に進める。

---

👉 まとめると：
「Slack一本化して実Fill取得 → EV確定 → 日次ネットEV≥0運用」という最短ルートに絞り込んだところです。

ショート系bot：今後の開発方針

1. Slack通知の標準化（最優先）

• 撤退 or 継続を断定的に言わせる
  • EVマイナス → 撤退: EV -3.2bps / Fill 52%
  • EVプラス → 継続: EV +2.3bps / Fill 68%
• 日次ダイジェスト
  • 例: 日次まとめ → EV +2.3bps / Fill 68% / 状態: Safe
• 例外ケース
  • 実Fillゼロ → No Fill (10m)
  • EVゼロ → Fillしたけど±0bps
  • 昇格失敗 → 調子乗りました → -8.4bps

👉 開発アクション
Slack通知モジュールを拡張し、上記パターンをテンプレ化する。
（例：slack_notifier.py に send_summary(type, data) を定義して条件分岐で自動整形）

---

2. 心理的負荷を減らす仕組み

• 通知を「大量」ではなく「要約」にする。
• 例：Fillごとに通知するのではなく、10分窓ごとに集約して1行で送信。
• 目的は「開発者＝私が運用に疲弊しないこと」。

👉 開発アクション

• 通知送信をイベント駆動から「集約ダイジェスト形式」に切り替え。
• Prometheusメトリクスから10分窓統計を抽出 → Slackに送信。

---

3. 収益化ゲートを明文化する

• 「曖昧な様子見」をやめ、撤退条件を数値で定義。
• 例：
  • 日次EV < 0bps → 撤退
  • Fill率 < 50% → 撤退
  • p95 > 350ms（2回連続）→ 撤退
• 逆に「昇格条件」も数値化して明文化。

👉 開発アクション

• evaluation_gate.py を強化し、撤退/昇格の判定をSlack通知に直結。

---

4. 実Fill最優先モード

• 「防御をガチガチ」に固める前に、まずは実Fillを確実に取ること。
• 初期フェーズは「安全に1クリックでもFillがついた」という事実が最重要。
• そこから EV計測 → 収益化ゲート判定 へ段階的に進む。

👉 開発アクション

• Canary起動時は「最小ロット / 並列1本 / Slack一本通知」のみに制限。
• Fill確認後に安全網（昇格/縮退/撤退）を有効化。

---

5. 開発ロードマップ（短期）

1. Slack通知フォーマット実装（撤退・ダイジェスト・例外ケース）
2. 通知を「集約ダイジェスト形式」に変更
3. 収益化ゲートの数値化＆通知直結
4. 最小構成でCanary起動→実Fill取得
5. 実戦データをSlack通知ログで蓄積 → 分析フィードバック

---

✅ 結論

• Slack一本運用でOK（現状では最も合理的）
• まずは「実Fill取得」と「撤退/継続をSlackで断定的に言わせる」ことを最優先にする
• 収益化ゲートを数値で明文化し、通知に組み込むことで Botと心中せずに済む運用体制を作る