Bot 開発ログ

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

開発ログを晒して始めて1週間が経過しました。ログをまとめる間にも別のbotをどんどん作っているので、この作業自体が開発におけるロスなのではないかという気持ちもあるのですが、とりあえず8月の間は続けてみようと思います。(最近はこの形式でのアウトプットが思考の整理にならないような気がしている)

他にも色々開発しているのですが、本日の作業時間が長かった4点に絞ってログをまとめました。スイング系、ガンマスキャ、エアドロ系などもゴリゴリ作っています。

MMbot開発ログ

1) 時系列サマリ（ハイライト）

  • 計測基盤の整備
    • Exporterを単一HTTPサーバへ統一、Prometheus連携・主要KPI（attempt/ACK/reject/fill）分離、段別レイテンシ/Cancel RTT 追加。
    • REG二重化（metrics.py と registry_hub.py）が発覚 → 単一ソースに統一方針を確立。
    • /metrics=generate_latest(REG) に固定（start_http_server 排除）。
  • EVゲート設計
    • 2モード（MM→MM／MM→TK）、ウォームアップ・ヒステリシス・ヘルス連動を実装。
    • TTLをqueue_stall_p50で自動調整、slip/adverseの自動追従（p90/p75）設計。
  • 安全性・去重
    • ACK/Fill去重（SQLite・INSERT OR IGNOREで原子的）、/control 認証・ID付与、メトリクス監査ラインを整備。
  • 監視の拡張
    • RateLimit（used-weight-1m/order-count-10s）、Reject理由別、Queue滞留、Build/環境露出、boot監査（MM_BOOT_PHASE）。
  • ネットワーク/インフラ
    • api.binance.co.jp:443 が回線側でブロック → .comは到達可。
    • 旧Prometheus（:9094）と混線 → mm-bot-prometheusを:9090に統一。
  • 診断モード導入
    • mode=diag / gate_enabled=false / health_bind=com / userstream_bind=none を実装（Paperで計測を先に回す）。
  • 主ブロッカー顕在化
    • pollerがalive=0のまま（REG不一致やGaugeモード未指定、例外即死）。
    • mm_build_info 重複定義→解消済み。
    • logging/sys の局所再代入に起因する UnboundLocalError→是正。

2) 現状スナップショット（技術的状態）

  • Exporter/REG
    • Exporterは単一REGを返す実装に収斂。REGは registry_hub の1本に統一方針。
  • メトリクス
    • KPI（attempt/ACK/reject/fill）、PnL器（fees/spread/slip/adverse）、段別レイテンシ、RateLimit、Reject理由別、Queue滞留、build/env、boot監査（MM_BOOT_PHASE）。
    • ヘルス系（poller）：mm_health_poller_alive、...last_success_seconds_{com|jp}、...last_error_code_{com|jp} を実装。
  • EVゲート
    • need_mm_mm=2*maker+slip+adverse / need_mm_tk=maker+taker+slip+adverse
    • ウォームアップ・ヒステリシス・ヘルス連動・diag_mode 強制CLOSEあり。
  • ネットワーク
    • .co.jp egress ブロック継続中（ローカル）。.comは到達可。
  • モード
    • 現在は診断モード（Paper）。ACK/Fillは0でも正常。目的は計測循環。

3) 主要ブロッカー（不可解点）

  • B1. poller が still alive=0
    • 可能性：REG不一致／multiprocess Gaugeのmultiprocess_mode未指定による即死／スレッド例外。
  • B2. initialize が実エントリで走っていない
    • 兆候：MM_BOOT_PHASE遷移がログに出ない。
  • B3. JP疎通がない
    • .co.jp:443ブロックにより、本運用（health_bind=jp／userstream=jp）に移れない。

4) 修正済み（Good）／残タスク（Todo）

✅ 修正済み

  • mm_build_info 重複解消／REG単一ソース方針／Exporter一本化。
  • diag_mode 導入（ゲート強制CLOSE理由カウント）。
  • ACK/Fill去重（SQLite原子化）、/control 認証・IDログ、RateLimit監視、Reject理由別カウント。
  • 旧Prometheus（9094）混線の切り離し（9090へ）。

🛠️ 残タスク（緊急度順）

  1. REGアイデンティティの強制：metrics.REG is registry_hub.REG を起動時に assert。
  2. poller 証跡の強制書き込み：起動直後に alive=1・last_error=-99、ループで 200/-2/-3/-9 を必ず set。threading.excepthook を有効化。
  3. multiprocess Gauge モード明示：alive=livesum、last_*_seconds / last_error=max。
  4. initialize の一本化＋ログ force：main() でのみ initialize_application()→MM_BOOT_PHASE 遷移を出力。
  5. モジュール名上書きの排除：logging/sys の再代入を grep で一掃。
  6. （ネットワーク）JP疎通の用意：短期は 東京VM または WARP/Tailscale で .co.jp:443 を通す。

5) 運用DoD（合格ライン）

診断（Paper）

  • /metrics に mm_health_poller_alive・...last_error_code_com が表示
  • mm_health_poller_alive == 1
  • time()-...last_success_seconds_com ≤ 35s
  • mm_health_exchange_time_last_error_code_com == 200 が継続
  • sum(increase(mm_ev_gate_close_total{reason="diag_mode"}[15m])) が増分（常時CLOSE）

本運用（JP）

  • time()-...last_success_seconds_jp ≤ 35s、mm_health_userstream_up==1
  • /control place_canary×2 → attempt+2 / ACK+1（去重OK）
  • ok_mm_mm|ok_mm_tk の発火
  • mm:ev5m_quote 非NaN → 連続3窓>0 で極小Liveへ

6) 直近アクション（15分で完了させるセット）

  1. REG統一のアサート導入（initialize冒頭）。
  2. poller起動直後の証跡（alive=1 / last_error=-99）と multiprocess_mode 明示を再確認。
  3. /metricsで証跡の可視（Exporter=単一REG） → PromQLで 3 指標（alive / last_success_com / last_error_code_com）。
  4. MM_BOOT_PHASE遷移ログ（0→3→5）を確認。
  5. （並行）JP疎通計画：VM or WARP/Tailscale の選定・準備。

7) 中期ロードマップ（JP疎通後 48h）

  • Day-1：prod切替→Canary×2（ACK+1）→15分観測→slip/adverse自動化ON、TTL係数k≈0.35。
  • Day-2：ゲート閾値（±2–4bp）微調整、Rate/Reject潰し、**連続3窓 mm:ev5m_quote>0**で極小Liveへ。

8) いま注視すべき不可解シグナル（早見表）

  • /metrics に alive / last_error が無い → REG不一致 or poller未起動
  • alive=0 かつ last_success=9999 / last_error=-99 → 起動即死（Gaugeモード or 例外）
  • MM_BOOT_PHASE が出ない → main経路未実行 or logging未force
  • diag_mode 増分が0 → gate OFF 未適用（設定反映漏れ）

MMbot開発：継続or撤退/切り替えポイント

結論

継続は “条件付き・時間箱付き（≤ 2 週間）”。
次の合格条件が揃わなければ即撤退 or ピボットを推奨。

合格条件（48時間のPaper→極小Live）

  1. 環境：JP疎通（/time=200≤35s・UserStream up=1・poller alive=1）
  2. 最小実績：place_canary×2 → attempt+2 / ACK+1（去重OK）
  3. EVの芽：mm:ev5m_quote > 0 が連続3窓（または N≥30本の中央値>0）
  4. 健全性：reject{PRICE/LOT/MIN_NOTIONAL} ≤ 1%、p95(request→ack) ≤ 400ms、rate_guard*のCLOSE ≤ 10/時

満たせないなら：このJP現物MMは一旦捨て、下記の代替へ即移行。

なぜ（3点）

  1. 市場構造の逆風：JP現物はmaker≒10bps & リベート無し。常時パッシブMMはスプレッド＜手数料×2になりがちでEVは負に寄る。
  2. 検証前のインフラ過多：poller/REG/Exporter整理は進んだが、ACK+1の最小実績すら未取得。これ以上のインフラ磨きは機会費用が高い。
  3. 他戦略の機会：現在はFR/清算スナイプ/裁定も走らせている。EVの立つ窓にリソースを寄せる方が期待値高。

Go / No-Go ルール（チェックリスト）

前提（Day 0）

  • JP疎通：東京VM or WARP/Tailscale で .co.jp:443 到達
  • mm_health_poller_alive=1、time()-last_success_jp ≤ 35s、mm_health_userstream_up=1
  • /metrics = generate_latest(REG)、metrics.REG is hub.REG（起動時assert）

Paper 24–48h（EVゲートON）

  • ok_mm_mm|ok_mm_tk の発火≥5分/時
  • reject{PRICE/LOT/MIN_NOTIONAL} ≤ 1%（filters前検証OK）
  • p95(request→ack) ≤ 400ms、state_changes_total[15m] < 10
  • 判定：mm:ev5m_quote > 0 連続3窓 or サンプル30本の中央値>0 → Go（極小Live）
    それ以外 → No-Go（撤退 or ピボット）

極小Live（48h）

  • 日次DD上限/自動停止が動作
  • net_edge_after_fees が日次＋ → 継続、負 or 変動過大 → 撤退

続けるなら（短期スプリント 72h）

T+0〜4h：環境問題に全振り

  • 東京VM起動 or WARP/Tailscale設定 → /time=200、UserStream(JP) up=1
  • REG単一・multiprocess_mode 明示（alive=livesum、last_*=max）・poller起動時に証跡（alive=1/last_error=-99）

T+4〜8h：ACK+1

  • place_canary×2 → attempt+2 / ACK+1（SQLite去重確認）
  • reject{PRICE/LOT/MIN_NOTIONAL}=0〜微小

T+8〜72h：EVゲート計測

  • slip_bp=p90(slip,15m)・adverse_bp=p75(adverse,15m)で自動追従（clip）
  • TTL=clip(350 + 0.35*queue_stall_p50,350..900)
  • ok_mm_mm|ok_mm_tk と mm:ev5m_quote の分布で±2〜4bp微調整
  • 48hでGo/No-Goを即決

捨てる/切り替えるなら（ピボット優先順）

  1. ヘッジ付きMM（現物MM＋先物/パーペで瞬間ヘッジ）
    • 目的：在庫DD抑制＋実効手数料＜10bpsへ
    • 判定：ヘッジコスト込みで need_bp が常時 2*maker 未満に
  2. イベント限定MM（BRQ単独）
    • OFI×BOB/BOA切替×短窓反転で瞬間裏置き・TTL短（250–500ms）
    • 判定：イベント時 net_edge_per_sec > 0 継続
  3. リベート or 低fee会場へ移管（先物・リベート有り取引所）
    • 判定：スプレッド−2*fee −滑り −逆行 の中央値が+@bpを安定
  4. クロス会場 薄いMM＋掃き（CEX/DEX/他CEX）
    • 判定：net_edge_after_fees > 0 を N≥50 で確認
  5. 並行でEVの立つ戦略（あなたの既存資産）
    • 清算スナイプ / CEX-DEX裁定 / FR系

いまの不可解点（刺さる指摘）

  • /metrics に mm_health_poller_alive / last_error_code が出ない → REG不一致or poller未起動（Exporterとメトリクス定義が同じREGか起動時assertで強制）。
  • MM_BOOT_PHASE が出ない → main経路未実行 or ログforce不足。python -m mm_bot.cli.main run を唯一の起動点に。
  • alive=0・last_success=9999・last_error=-99 → multiprocess_mode未指定による即死が濃厚（.set()で落ちる）。
  • JP回線が塞がったまま → 本運用不可。診断はCOMのみ（Paper）で合格→必ずJP疎通の計画を先に。

最後に（決断の指針）

  • YES（継続）：上の合格条件を48時間で満たせる体制（JP疎通+ACK+1+EV>0の芽）がある。
  • NO（撤退/切替）：環境が作れない or EV>0の実測が48時間で立たない。

DEX/CEX arbbot開発ログ

1) フェーズ到達状況（サマリ）

  • Phase 0：比較の正しさ → 完了
    • per-SOL/USDT正規化の貫通（dq/cb/mid）、BUY=BID／SELL=ASKの厳守
    • r分布是正（p90 ≤ 1%）、_emit統一・直呼び排除、diag取り込み修正
    • ルート/契約のスキーマ指紋化（schema_fpr/route_fpr）、VWAP共通化・二重丸め防止
  • Phase 1：実弾 canary の安全装置 → 主要項目は実装済み
    • fail-closed原則（未知＝発注しない）／例外3階層（retry/degrade/fatal）＋非同期タスク捕捉
    • HALT/メンテ gateの先頭配置＋送信直前ゲート（窓抜け防止）
    • kill-switch（bps基準・ヒステリシス：ON=100bps / OFF=80bps）
    • gas gate（推定コスト×3未満拒否／oracle失敗はgas_estimate_error）
    • RPS autoshed（429前駆で乗法0.7降速、手動RPS＞自動）
    • outbox冪等送信（WAL/FULL/busy_timeout、CAS、ACK照会で消込）
    • 状態機械（PENDING→SENT→ACK|FILLED|CANCELLED のみ、逆行はstate_conflict）

2) ログ・メトリクス・SLO（観測系）

  • 三位一体ログ：pred/quoted/realized を同一runで記録＋手数料/滑り4点分離
    fees_bps_q, fees_bps_exec, slip_est_bps, slip_real_bps
  • rメトリクス3系統：arb_r_dev_pred_bps / …quoted_bps / …realized_bps（1-2-5系列バケット）
  • 速断メトリクス（意思決定に直結）：
    arb_auto_go_total{why,sym(=whitelist),tap}→ lost_by WHY %（Top3で“今日の1ノブ”を選定）
  • SLO & アラート
    • 比較SLO：:arb:r_dev_pred_p90_5m ≤ 100bps（±1%）
    • why=unknown ≤ 1%（5分窓）、超過時は直近10件の軽量ダンプ
    • ReconMismatch（10分窓 0件）
    • RPSAutoshed（ack p95 傾斜で自動降格）
  • 高カーディナリティ抑制：ラベルに route_id/order_id 禁止（CI静的検査）

3) CI・赤テスト（回帰防止）

  • 最小セット（Green）
    • test_halt_gate_runs_first（HALT先頭化の実証）
    • test_state_machine_no_regression（状態遷移の単調性）
    • test_fail_closed_on_status_api_error（ステータスAPI失敗＝fail-closed）
    • test_precheck_order_is_round_then_notional（丸め→notional→フィルタ順序）
  • 決定論保証：random.seed／time_ns/monotonic_ns 固定fixture

4) 直近で入れた詰め切りパッチ（“ラスト数ミリ”）

  • os import 全入口監査（entrypoints / scripts / tests まで洗い出し）
  • HALT gate：本流先頭＋送信直前へ関所を追加（全経路の一貫性）
  • kill-switch：閾値の**単位(bps)**統一アサートを追加（回帰防止）
  • Go/No-Goワンショット：PromQL 3本（p90 / unknown / recon）で即判定
  • 高カード監査：labels(…route_id|order_id) をCIで落とす

5) Go/No-Go 最終ゲート（数値で即判定）

Go 条件（すべて満たす）

  1. :arb:r_dev_pred_p90_5m ≤ 100bps（30分連続）
  2. :arb:why_unknown_ratio_5m ≤ 1%
  3. ReconMismatch == 0（10分窓）

→ 1つでも外れれば No-Go（該当ゲートを先に修復して再判定）

6) 実弾 canary ランブック（45分＝1ノブ）

  1. preflight（構文・高カード監査・赤テスト）
  2. 今日の1ノブを1つだけ変更
    • depth→CEX VWAP間隔 100→80ms
    • ts_skew→許容C 500→350ms
    • miss_2nd→プリフェッチON（p95>2000msなら窓+200ms）
  3. canary：最小ロット×5本 × 本命時間帯×2
  4. KPI判定：
    AUTO→GO ≥30% / GO→FILL ≥60% / median(realized_edge_on_quoted_bps) ≥ fees+slip_p75
    • 達成→サイズ×1.5（TR内）
    • 未達→同ノブをもう一段だけ動かして再canary
  5. Run Manifestに「変更/期待/結果」を1行記録

7) 残る軽微リスク & 対処（未然防止リスト）

  • entrypoints/scripts/tests の os 残り：一括検知→空出力まで修正（可能な限り Path 化）
  • HALT gate の例外ルート（再送・フォールバック）でも先頭で判定
  • 成功系ログの逆流：INFO成功はサンプリング、WARN/ERROR常時、非同期Appender背圧ON
  • outbox PRAGMA の適用漏れ：新規接続生成時にも WAL/FULL/busy_timeout を毎回適用
  • fx_local_diverged：USDC/USDT の場内乖離 50–80bps 超で fail-closed
  • 手数料通貨混在：fee_to_bps() でUSDT等価化→fees_bps_execへ合算

8) スケール／再設計／撤退の分岐（自動化基準）

  • スケール：2時間帯×2日で KPI達成＋recon一致 → 面／銘柄を段階拡大
  • 再設計：ts_skew / priority_spike / route_lag がTop1のまま2日改善なし
  • 撤退/ピボット：10日 or 200トレードで realized_edge < fees+slip_p75 or recon 連続不一致
    → イベント駆動arb／FR戦略／清算スナイプ／薄板マイクロMM へ切替

次アクション（今日やること）

canaryのRun Manifestに「変更/期待/結果」を追記（再現性＆意思決定の核）。

Go/No-Go をシェルで自動判定 → Goなら45分=1ノブ canary、No-Goなら該当ゲートだけ直して再判定。

DEX/CEX arbbot開発：継続or切り替えポイント

結論

継続すべき。ただし“時間と指標を厳格に切った検証スプリント”として。
いま捨てるのはもったいない。比較系（Phase 0）と運用安全装置（Phase 1）の出来が強く、残課題はほぼ「面（α）」の証明だけ。このインフラは他戦略にも転用が効くので、短期でEV>0を実証できなければ即ピボットの形が最適。

継続の根拠（要点）

  • 土台が強い：正規化・r分布・BID/ASK厳守・三位一体ログ・fail-closed・HALT gate先頭化・kill-switch（bps統一）・outbox冪等・状態機械CAS・速断メトリクス（lost_by WHY %）まで実装済み。
  • 残リスクが“測れる状態”：realized_edgeと費用/滑りが分離され、原因別（depth/ts_skew/priority/route_lag）の寄与率が即見える。
  • ** sunk cost の回収可能性**：ここまでの監視・冪等・SLOはFR/清算スナイプ/マイクロMMにもそのまま載る。

時間を切った“最終スプリント”計画（10日 or 200トレード）

この期間で達成できなければピボット。達成できればサイズ拡大。

成功KPI（どれも満たす）

  • AUTO→GO ≥ 30%
  • GO→FILL ≥ 60%
  • median(realized_edge_on_quoted_bps) ≥ fees + slip_p75（p25も≳0なら尚良）
  • :arb:r_dev_pred_p90_5m ≤ 100bps（±1%）& why=unknown ≤ 1%（5分窓）
  • ReconMismatch = 0（10分窓、外部要因控除後）

即ピボット条件

  • 上記KPIを10日 or 200トレードで満たせず
  • recon不一致が連続2日（外部要因で説明不可）
  • lost_by WHY %のTop1がts_skew/priority/route_lagのまま2日改善しない

“勝てる面”を検証する3つの実験（45分=1ノブで回す）

  1. depth対策ノブ：CEX VWAP間隔 100→80ms → canary最小ロット×5×2時間帯
    • 期待：lost_by WHY %のdepthが低下、GO→FILL上昇
  2. ts_skew対策ノブ：許容C 500→350ms（必要ならDEX優先fee↑）
    • 期待：ts_skew低下、realized_edgeのp25改善
  3. miss_2nd対策ノブ：プリフェッチON（p95>2000msなら窓+200ms）
    • 期待：miss_2nd低下、2nd leg失敗率↓

各実験は1ノブだけ動かし、Run Manifestに変更/期待/結果を1行で記録。因果を崩さない。

それでもダメなら（即ピボット先と理由）

  • イベント駆動arb：Jupiterルート再計算／上場直後／メンテ明けの短時間窓に限定（個人が勝てる土俵）。
  • FR（Funding Rate）系：コスト構造が読みやすく、現行の監視/冪等/kill-switchが活きる。
  • 清算スナイプ（Hyperliquid）：既に取り組んでいるKPI（KEEP≥60%, p95≤350ms, fill_drop≤10%）で勝ち筋が明確。
  • 薄板アルトのマイクロMM：サイズ固定・回数勝負（リベート無しでも微利積み上げ）。

今日やること（超短縮手順）

  1. Go/No-Go 自動判定（p90/unknown/recon）→ Goなら次へ、No-Goなら該当ゲート修復。
  2. 今日の1ノブを1つだけ（depth or ts_skew or miss_2nd）→ canary最小ロット×5×2時間帯。
  3. KPI判定 → 達成ならサイズ×1.5、未達なら同ノブをもう1段だけ動かし再canary。

総評

続ける価値は十分ある。いまは“走らせて真実を取るだけ”の地点にいる。インフラはプロレベルに近く、面の検証コストが低い。ただし時間は切る——数字が出なければ迷わずピボット。

オンチェーン清算スナイプbot：開発ログ

概要

目的：Hyperliquid清算スナイプbotを「事故らず」「正規ゲートで」回し、最短で**実データ採用 → 日次ネットEV≥0（UTC）**へ。

1. 時系列ダイジェスト

  • 初期：Exporter/Prom配線、擬似供給で配線確認。A/B、SIGNIF、p95(incl)/p99、EV/ガス、Deadman、在庫/予算ガードなど“全部盛り”を設計。
  • 中盤：NaN撲滅、registry一本化（:9106）、メトリクス名とラベル集合の正規化（symbol,side,reg,ab_block/le）。
  • 課題発覚：Prometheusがrules未読込、hl:adoption_gate_ready など正規ゲートが空。代替メトリクスでGO判定していた（危険）。
  • 是正：
    • :9106 を get_registry()+127.0.0.1 で起動（multiprocess & 外部露出防止）。
    • rule_files: の絶対パス化、ファイル縮小（最小4条件のゲートで通電）。
    • 供給8分→minゲートでの Go/No-Go に切替。
  • スプリント実行：preflight/quick/finalチェック群、Prom再読み込み、sim供給、最小ゲートの稼働確認まで整備。

2. 現状サマリ（達成度）

  • 観測/計測基盤：◎
    • :9106一本化、multiprocess掃除手順、Prom 9094最小構成、metric_relabel防火壁。
    • 必須元メトリクス：
      live_exec_attempt_total / live_fill_success_total / shadow_exec_attempt_total / shadow_fill_success_total / submit_inclusion_ms_bucket{le} / hl_gain_usd_total_finalized / hl_loss_usd_total_finalized。
  • 正規ゲート（最小版）：○（通電済み）
    • 4条件＝EV>0 / p95(incl)≤350ms / fillrate_drop≤10% / min_den_ok≥300
    • 欠測0倒し・同ラベル集合に統一。
  • 安全性：○
    • ループバックbind、外部露出遮断、drain SLOの枠、鍵ローテ/最小権限、allowlist（deny-by-default）。
  • 未：一部rulesのYAMLエラー/拡張ゲート（SIGNIF/ヒステリシス/予算/Deadman銘柄別など）の段階的復帰。

3. 直近の修正内容（15–25分パッチ）

  • 危険：代替CounterでのGO判定 → 禁止。
  • 修正：
    1. prometheus-test.yml を絶対パスの rule_files で再定義。
    2. 最小ルールに縮退（rules_min_core.yaml / rules_min_gate.yaml）。
    3. :9106 を start_http_server(9106, addr="127.0.0.1", registry=get_registry()) で統一。
    4. 供給→8分待機→4コア指標が0でないことを確認。
  • 検証：/api/v1/rules にレコーディングルールが載る、4指標の len()>0。

4. 現在の運用状態（“回る最小形”）

  • Go/No-Go（最小版）：
    hl:adoption_gate_ready by (symbol,side,reg) が 1 の組だけ「撃つ」。空/0は「撃たない」。
  • Round-1手順：shadow起動→5分交互A/B→ev5m_abs_final>0 ∧ p95≤350 ∧ fillrate≤10% ∧ min_den_ok→採用→T+60分回帰A/B→退行なら自動RB。
  • ログ：採用行をCSV 1行で保存（symbol,side,ev5m_abs_final,p95_incl,fill_drop,effect_size,pass_flag,fail_reasons）。

5. 未解決課題（優先度順）

  1. RulesのYAMLエラー消し：現状は最小2ファイルで通電。拡張ルール（SIGNIF/p値、ヒステリシス、予算、Deadman銘柄別、RPC CB指標等）を段階的に復帰。
  2. 元メトリクスの恒常供給：submit_inclusion_ms_bucket（le単調）/ live & shadow の試行/フィル/カウンタ類の継続供給。
  3. SIGNIF（A/Bの有意性）：アプリ側でp値→ hl_ab_signif{metric="ev5m_abs_final"} を追加し、ゲートにAND。
  4. 保持時間・ヒステリシス：ゲートのフラップ抑止（ON保持10分/OFF保持5分をローカルゲートに実装）。
  5. 予算/EV効率：hl:ev_per_gas_5m≥閾値、日次ネットEV≥0（UTC）をAND。
  6. Deadman（銘柄×side）：rate(iid_total[5m]) by (symbol,side)>0 をAND。
  7. 監査自動照合：レジャー合算 vs メトリクス差分（±ε）を日次でチェック→不一致なら自動停止。

6. 戦略見直し/別戦略への分岐点（チェックリスト）

  • EV>0不達（主要セッション×銘柄で 10ラウンド中≤4勝）：
    → 二相探索（粗：倍々→細：±1）を3ノブ（OI_Z/priority_fee/burst）で回す → なお不達なら停止→戦略切替検討。
  • EV/attempt < 最小改善幅（例 $0.02/att）を3セッション連続：停止→切替。
  • p95(incl)>350ms 2セッション連続（CB/fee制御後も）：RPC構成再設計。
  • fillrate_drop>15% 90分継続：キュー/PO最適化 or 撃たない帯。
  • 供給(strict)不足継続：時間帯/銘柄プリセット見直し（撃たない宣言）。
  • EV/ガス<1.0 を2日連続：fee下げ→停止。
  • 監査不一致 1回でも：即停止→原因確定まで撃たない。
  • ゲートフラップ>10/日：保持時間＆しきい値再調整、改善無ければ停止。

7. 実行ランブック（毎回ここだけ見れば回る）

プレフライト（15分）

  1. promtool check rules monitoring/rules_min_*.yaml → OK
  2. prometheus --config.file=prometheus-test.yml … → up=1
  3. 供給→sleep 480
  4. 4コア指標の件数チェック（0なら元メトリクス/ラベル名ズレ）

Go/No-Go（30秒）

curl -s :9094/api/v1/query --data-urlencode \
 'query=hl:adoption_gate_ready by (symbol,side,reg)'
  • 1 の組だけ GO。空/0は NO GO。

Round-1（45分）

  • shadow→5分交互A/B→採用→T+60分回帰A/B→RB判定。

終端（5分）

  • CSV 1行追記
  • 日次ネットEV（UTC）確認、ゲートフラップ回数、トップ3障害（nofill{reason}/RPC/供給）。

8. いまの一手（次のチャットで貼ってほしいもの）

  1. curl -s :9094/api/v1/rules | jq '.data.groups[].name' | sort -u | head -20
  2. 4コア指標の件数（hl:ev5m_abs_final / hl:p95_submit_inclusion_ms / hl:fillrate_drop_5m / hl:adoption_gate_ready）
  3. :9106/metrics の該当行（submit_inclusion_ms_bucket / hl_gain_usd_total_finalized / live_exec_attempt_total 各2–3行）

オンチェーン清算スナイプbot：継続or撤退ポイント

結論

“続ける。ただし条件付きで短期決着”
いまの配線・安全装置は個人として最高水準。問題はαの未証明だけ。よって、2週間の時限付き実験で “清算スナイプ”の実力を数字で判定し、**基準未達なら即ピボット（並走戦略へリソース移管）**が最適。

続行の根拠

強み

  • 可観測性・安全性は◎（確定EV・p95/99・Deadman・予算・在庫ガード・drain）。
  • 最小ゲートで“壊れず回す”土台は完成。実験→学習→採否のループが回せる。

弱み

  • α（どこで勝つか）の実証が未了。
  • ルール群の肥大化で運用が複雑化しやすい（最小ゲート運用に絞るのが吉）。
  • 清算は供給×同着勝負で競争が激しい。撃つ帯の選球とqueue/PO最適化が収益差の決定要因。

2週間の“有無を言わせぬ”判定条件（ラダー式）

48時間内（Round-1〜Canary）

  • ① 採用ライン通過：ev5m_abs_final>0 ∧ p95(incl)≤350ms ∧ fillrate_drop≤10% ∧ min_den_ok を2セッション連続で達成。
  • ② 回帰A/Bで退行なし（T+60分）。

未達→一時停止して、銘柄/時間帯プリセットを入れ替え。再チャレンジは最大2回まで。

1週間内

  • ③ 日次ネットEV（UTC）≥0 を3/5日で達成。
  • ④ EV/ガス ≥ 1.2 を3セッション連続で維持。
  • ⑤ ゲートフラップ ≤ 2/日（最小保持：ON10分/OFF5分で運用）。

未達→開発継続は非推奨（ピボット推奨）。

2週間内（最終判定）

  • ⑥ 稼働日の過半でネットEV>0、かつ 最大ドローダウンが当初許容内。
  • 達成なら縮小拡大（ノッチ・銘柄・時間帯を漸増）。未達なら撤退。

即日やること（3点）

  1. 最小ゲート運用に固定：EV>0 / p95≤350 / fillrate≤10% / min_den_ok の4条件だけでGo/No-Go。
  2. 実データRound-1→回帰A/Bを2セッション消化（銘柄×sideで1クリックずつ）。
  3. Adoption Docketを1行保存（閾値/効果量/失敗理由）＆日次で整合監査（レジャー≡メトリクス）。

ピボット時の並走戦略（“キャッシュの芯”候補）

  • Funding-Carry（低速・低競合）：FR歪み回収。日次EVの土台づくりに最適。
  • 低速MM（厚い板・限定帯）：在庫中立＆小サイズ。撃つ帯を厳選。
  • CEX/DEX 裁定：比較の正しさFix済みなら最小ノッチでAUTO→GOを仕上げる。

いずれも既存の計測・ゲートをそのまま流用可。清算は研究トラックに落として継続学習。

レッドライン（即停止）

  • 監査不一致（レジャー≠メトリクス）を1回でも検知
  • EV/ガス < 1.0 を2日連続
  • p95(incl) > 350ms が2セッション連続（CB/プロバイダ切替後も）
  • フィル率ドロップ > 15% が90分継続

最後に

この開発は捨てる段階ではない。ただし、“勝てる帯だけ撃つ”ことと、期限付きの判定がプロの流儀。
2週間の時限実験で数字が出なければ、未練なく収益が太りやすい並走戦略へ主力を移す。

ショート系bot：開発ログ

1. サマリー

  • 計測の嘘は解消：EV（micro基準）、Markout(Δ150ms・重み付き)、fee実測、L2累積のBASE基準統一、メトリクス一元化・多重プロセス対応OK。
  • 整合は構造化：attempted/sent/inflight 三点セット、sent基準の恒等式、ACK/DONEの単一ヘルパ化、ラベル完全一致ガード、負値検知。
  • 原因分類の精度向上：precondition→送信前SKIP／staleness@send凍結／cross_ticks_at_send凍結／no_touch（ACK→DONE p5自動校正）／maker_posted独立化。
  • AB運用が回る：cross1(1tick)/cross2(2tick)の ITT（assigned） と PP（effective） を分離記録、スキュー監視（±20%）。
  • 品質ゲート：
    • cross1：cum_bid_base ≥ 1.3→1.4 × qty ＋ sell_flow>0.65→0.70 ＋ staleness@send≤100ms、samples<4はPASS
    • cross2：軽量 sell_flow>0.55（A/B）
  • 現状の壁：1tick/2tickテイカーは 地合い的なタッチ率不足（no_touch優勢）でEVが伸びにくい。sell_flow 実値化がラストピース。

2. 完了（主な修正と実装）

  • EV系
    • p_ref を microprice/mid に是正、瞬間EVと Markout(Δ150ms) を別系列で記録、Markoutは notional重み。
    • fee bps は実測でネット化（コード側は raw のみ・Recording Rules で差引）。
  • 原因判定
    • 優先度固定：staleness → ws_gap → exchange_reject → maker_posted → liquidity → (cross_ticks_at_send<=1) → no_touch → timeout → other
    • no_touch 阈値は腕別 p5（min(5ms,p5)）で自動校正、timeoutは p95。
  • L2/価格
    • L2累積はBASE基準に統一（cum_bid_base_at(price)）、丸めは price_floor_to_tick() を全経路共通。
    • ORDER_DEBUG に cum_bid_base/quote, l2_bucket, units=BASE を出力。
  • 整合・運用
    • orders_attempted/sent 分離、inflight_gauge（ACK+1/DONE−1）、送信例外で reject_total++ と cause="exchange_reject" を強制。
    • WSギャップ検知→REST回復、ready=False 期間は発注ブロック、復帰後3〜5ティックのウォームアップ。

3. 現状KPI（直近ログの要約）

  • cross1 約定率：17% → 40%（ゲート強化後・改善）
  • cross2 約定率：0%（no_touch 主体）
  • 主因TOP：cross_too_narrow（cross1）／no_touch（cross2）
  • sell_flow：購読と配線は実装完了、samplesが未充足のため実力発揮はこれから

4. 未解決／不可解（要監視）

  1. sell_flow=None, samples=0 が残る回あり
    　→ tradeテープ購読の起動・シンボル・dedup・送信直前取得を再点検（200/300ms A/Bで samples≥4 を確保）。
  2. cross2 で cross_too_narrow（再発ガード）
    　→ 判定は凍結値 cross_ticks_at_send、優先度固定、EXPIRE debug に出力。
  3. 恒等式のドリフト（再発リスク）
    　→ sent基準検証、送信例外の reject 記録、inflight_gauge の±対称＆負値監視。

5. 運用ゲート（Go/No-Go）

（腕別・10分窓）

  • Go：fill ≥ 0.50 ∧ ev_net_5m > 0（目標 +3bps）∧ timeout/orders < 0.10 ∧ staleness95 ≤ 100ms ∧ no_touch ≤ 40%
  • No-Go：cross1はA/B 1ブロック強化（cum_bid×1.4 / sell_flow>0.70）→未達なら停止し、cross2＋ベースMM主脚へ

（24h Canary・全体）

  • 合格：avgEV_net ≥ +2〜3 bps 維持、SLO達成、inflight=0
  • 不合格：72hで avgEV_net ≤ 0（Markout基準）→ 常時テイカーはイベント限定に縮退

6. 次の60分（実行順）

  1. 計測・整合（10分）
    　- 恒等式（sent基準）常真／inflight末尾0／負値0／ラベル整合OK
  2. 撃つ前の実値化（25分）
    　- trade購読→short_trade_samples_200ms/_300ms が増えていること
    　- 送信直前の ORDER_DEBUG に sell_flow, samples が出る（None,0 以外）
    　- no_touch 閾値を腕別 p5/p95 で更新
  3. 腕別スモーク（25分）
    　- cross1：A/B（cum_bid×1.4 vs sell_flow>0.70）各1ブロック
    　- cross2：sell_flow>0.55 軽量導入
    　- Go/No-Go 判定→No-Go なら cross1停止、cross2＋ベースMMへ

7. 24h計画（現実解）

  • 主脚：cross2＋ベースMM（±1〜1.5tick、在庫上限、フロー>0.75で片翼縮小）
  • イベントテイカー限定：清算・板圧縮・外部指標トリガー
  • ダッシュ常設：fill_rate, ev_net_5m, ev_markout150ms_5m, topk(expires_cause), attempted/sent, inflight_gauge

8. 分岐点（戦略見直し・切替）

  • cross1 が継続的に fill ≥ 0.50 未達 → 停止
  • 7日ローリングで AB勝ち腕無し（cross1/2 ≤ 0）→ ゲート再定義 or 戦略切替
  • no_touch>40% 継続 → イベントテイカー中心にシフト

9. すぐほしいログ（2–3本）

  • ORDER_DEBUG: sell_px / cum_bid_base / sell_flow,samples / stale_ms / experiment
  • EXPIRE context debug: cross_ticks_at_send / cause / Δack→done(ms)
  • 恒等式集計行（sent/fill/expire/reject/cancel/inflight）

ショート系bot:継続or切り替えポイント

判定

  • プロジェクトは捨てない。
    ただし 「常時 1–2tick のIOCテイカーを主脚にする路線」は退役。
  • 基軸はベースMM＋軽量裁定に切替え、**テイカーはイベント限定の“腕”**として残す。
  • 72時間の明確な可否ゲートを置いて、そこを切ったらテイカーは縮退・凍結。

なぜ（要点）

  • 測り／整合は一級品：EV/Markout/単位・ラベル・恒等式・WS回復まで土台は良い。捨てるには惜しい資産。
  • 戦略の地合い負け：常時テイカーは no_touch 優勢＆fill<50%（cross1=~40%、cross2=0%）。構造的に “触れない時間が長い”。
  • 改善余地は“撃つ前の密度”だが限界近い：ゲート強化で一時改善（17→40%）も、+手数料を超えるネットEVへ持続的に届く根拠がまだ弱い。

72時間の可否ゲート（これで決める）

  • 腕別10分Go：fill ≥ 50% かつ ev_net_5m > +3bps かつ timeout/orders < 0.10 かつ staleness95 ≤ 100ms かつ no_touch ≤ 40%
  • 24h合格：avgEV_net（Markout基準） ≥ +2〜3bps を維持、inflight=0、恒等式常真
  • 72hで未達 → 常時テイカーは凍結（イベント限定へ）

次にやること（48h実行計画）

  1. 主脚へ切替：ベースMM（±1〜1.5tick）＋在庫上限＋片翼自動縮小を起動。
    目標：+3〜5bps/10m の底上げ。
  2. テイカーはイベント限定に：清算・板崩れ・外部指標のみで発火（常時は止める）。
  3. cross1はラストA/B 1ブロックだけ：
    A) cum_bid_base ≥ 1.4×qty / B) sell_flow>0.70（samples≥4が前提）。
    → 未達なら停止。
  4. cross2は軽量ゲート：sell_flow>0.55 のみ追加で“触れる時だけ撃つ”。
  5. Tradeテープの“実動”を確認：送信直前ログに sell_flow=0.xx, samples≥4 が出るまで粘る（200/300ms A/B）。
  6. 自動停止を厳格化：日次 -Y USD または -X bps 達したら自動 disable_live。
  7. ダッシュ常設：fill率(腕別) / ev_net_5m / ev_markout150ms_5m / topk(cause) / inflight_gauge / invariant_ok

捨てる基準（明確化）

  • Markout基準の avgEV_net ≤ 0 が72h継続
  • AB 7日ローリングで勝ち腕なし（cross1/2とも≤0）
  • sell_flow実値化（samples≥4）が運用時間の≥70%で満たせない

上記に該当したら、常時テイカーは“きっぱり凍結”。コード資産は MM/裁定/イベントテイカー に再配置。

配分の勘所（時間/資金）

  • 開発リソース：MM/裁定 70%、イベントテイカー 20%、常時テイカー改善 10%（72hの間だけ）
  • 露出：Canary中は最小ロット・並列本数制限、inflight=0 で毎窓閉じる運用。

ひとこと

続ける価値は十分ある（土台が強い）が、主脚を間違えると時間が溶ける。
MM＋軽裁定で底EVを作り、テイカーは“当たる時だけ”撃つ腕へ。
72時間の数値ゲートで情緒なく判断する。

-Bot, 開発ログ