condor-strategy

🦅 CONDOR v4.0.1 — 1日に1回の最高のトレード

上位50資産。純粋なトレンド継続。最高水準のコンフルエンスのみ。1日1回のトレード。

v4.0.1（2026-05-18）— 保有資産の重複排除における競合状態の修正＋DSLの間隔調整

運用の信頼性を高めるためのパッチです。戦略上の見解に変更はありません。スコアリングに変更はありません。 ゲートに変更はありません。Bison v3.0.1 のパッチを直接移植し、Condor の判断ログで確認された 同じ競合ウィンドウ＋ポジション状態の不整合のバグクラスに対処します。

確認されたバグ。 2026-05-14 から 2026-05-17 にかけての Condor2（M193171）の監査で、連続4回の CONDOR_APEX HYPE LONG ENGINE_FAILURE が確認されました。すべて、HYPE がすでにランタイムのエグゼキューターに保有されている間に発行された HYPE LONG シグナルが原因でした。プロデューサーのオンチェーン held_assets チェックは、push_signal() が OK を返してから、次のティックで clearinghouseState が取得され、ポジションが反映されるまでの競合ウィンドウ中に漏れが生じます。Bison v3.0.1 で修正したものと同じバグクラスで、ここでも同じ修正を適用します。

修正1 — 最近のシグナルのキャッシュ（scripts/condor_config.py）。 record_signal(coin) は、プッシュが成功するたびに state/recent-signals.json へ {coin: epoch_seconds} を書き込みます。main() は候補の最良銘柄を選択した後、push_signal の実行前に was_recently_signaled(coin) を呼び出し、RECENT_SIGNAL_TTL_SEC（デフォルト240秒。一般的なALO の約定ウィンドウ＋次のティックまでの間隔の約4倍）以内にシグナルが発行された銘柄の出力をスキップします。スキップされた銘柄は、監査用にティックごとの出力へ DEDUP_SKIP の注記とともに記録されます。

修正2 — DSLの決済間隔を30秒から60秒に変更（runtime.yaml）。 Bison の監査で確認されたランタイムのポジション状態不整合バグ（決済成功から1～2ティック後に CLOSE_FEE_OPTIMIZED_FAILED "Reduce only order would increase position" エラーが発生）に対する防御的な緩和策です。Condor の決済側監査では、まだ同様の失敗は確認されていませんが、 このバグは全体に及ぶものです。予防的にここでも間隔を調整します。根本原因（ランタイム側のポジション状態同期）は ランタイムチームにエスカレーション済みです。このYAMLの変更は、下流での緩和策にすぎません。

この変更で修正されないもの。 DSLの状態とHLの状態が恒久的に同期しなくなる、実在しない孤立ポジションです。この種のバグ にはランタイム側での調整が必要です。プロデューサーにはDSLの状態を変更する権限がありません。

v4.0.0（2026-05-12）— 配管のみの移行

戦略上の見解に変更はありません。v3.4のスコアリングテーブル、ハードゲート、スコア連動型のサイズ設定ティア、DSLプリセットはすべてそのまま維持されています。6層の配管を切り替えました。

1. MCPトランスポート：mcporter サブプロセス（呼び出しごとにコールドスタートで2.5～5秒）から、senpi_runtime_helpers.SenpiClient.mcp_call() のインプロセスHTTPS（約280ms）へ。
2. シグナル発行：スキャナーは create_position を直接呼び出していましたが、プロデューサーは現在、ランタイムの /signals へ push_signal() でシグナルを発行します。ランタイムはLLMゲート付きの condor_entry アクションにより、FEE_OPTIMIZED_LIMITでポジションを開きます。スコアティアに応じたサイズ設定のため、シグナルデータから marginUsd と leverage を渡します。
3. 再入可能性：置き換えるv3のロックファイルはありません（Condor v3.xはプロデューサー側のロックなしでopenclaw cron上で実行）。producer_daemon がティックごとの scanner_lock を管理し、古いPIDを自動的に復旧します。
4. スケジューラー：openclaw cron（3分）から producer_daemon(interval_seconds=180) へ。長時間稼働するプロセスです。
5. リスクゲート：Pythonの MAX_POSITIONS、動的な1日あたりの上限（健全な状態なら1、-25%なら0）、決済後のクールダウン状態ファイルを、宣言型の risk.guard_rails に移行しました。state/trade-counter.json はv4.0では役目を終えています（レガシーログとの互換性のため last_entry_ts フィールドのみ維持し、クールダウンの適用はランタイムに移行）。
6. 決済手数料：DSLの決済注文をMARKET（テイカー、0.045%）からFEE_OPTIMIZED_LIMIT（メイカー優先、0.015%、ALOタイムアウト60秒、テイカーにフォールバック）に切り替えました。エントリーでは、v3.xの忍耐ルールに従って ensure_execution_as_taker: false を維持します。

⛔ エージェントに関する重要なルール

ルール1：インストール先は /data/workspace/skills/condor-strategy/

ルール2：プロデューサーはポジションを決済しません — DSLのみが決済します。

ルール3：ポジションは最大1つ（最高のトレードを1回）

ルール4：各セッション開始時にランタイムとデーモンを確認してください

ルール5：スコアリングやゲートのパラメーターを変更しないでください

ルール6：エントリーは24時間につき最大1回（ランタイムの max_entries_per_day=1）

ルール 7：決済後の120分クールダウン（ランタイム per_asset_cooldown_minutes=120）

ルール 8：ドローダウンが-25%に達したらHARD_STOPサーキットブレーカーを作動（ランタイム drawdown_halt_pct=25）

基本方針

トレンド継続のみを狙い、逆張りは一切しません。

Kodiakの生涯トップ3の勝ちトレード（すべてSOL、+$133 / +$87 / +$78）より：

「大きな方向性の変動を予測する最も強力な指標は、 4H、1H、15m、5mの価格モメンタムがすべて完全に同じ方向を向き、 さらにスマートマネーのリーダーボードでも、まったく同じ方向に 強い偏り（方向性の合意が65%超）を示していることです。」

WolverineのHYPEショートの事後分析（-$160の損失、2026-04-16）より：

「暴走する32%の貨物列車の前に立ちはだかり、1%の ミクロな戻りを狙ってしまいました。過去の勝ちトレードは、 大きなマクロの変化に逆らうのではなく、それに従っていました。」

Condorは、この両方の知見を必須条件として適用します。

必須条件（すべて満たす必要あり — 1つでも不成立ならそのアセットをスキップ）

1. XYZではなく、ステーブルコインでもない
2. OI > $1M USD（コンテキストを考慮した読み取り）
3. trader_count >= 50（シグナルの有効性）
4. 3TFの方向一致 — 4h_price、1h_price、15m SM velocityがすべてエントリー方向と一致し、それぞれが大きさのしきい値（4h ≥ 1.0%、1h ≥ 0.3%、15m velocity ≥ 0.1）をクリアすること
5. マクロトレンド条件 — エントリー方向と反対方向の |4h_move| > 10% の場合はブロック
6. エントリー方向のSM合意率 >= 70%（v3.4で調整）

スコアリング（最大約18ポイント、v3.4以降のMIN_SCORE = 12）

シグナル	ポイント
4hの値動き：>2%（+2）、>4%（+3）、>6%（+4）	1-4
1hの確認：>0.5%（+1）、>1%（+2）	1-2
15m SM velocity：>1.0（+1）、>2.0（+2）	1-2
3TF_ALIGNEDボーナス	+3
SM合意率：>=70%（+2）、>=75%（+3）、>=80% STRONGLY_TILTED（+4）	2-4
trader_count >= 100（DEEP_CONSENSUS）	+1
ファンディングがポジション方向に有利	+1
BTCマクロが確認（方向一致、>1.5%）	+1
ピーク時間帯（13-19 UTCまたは00-05 UTC）	+1

ポジションサイズ（スコア連動、レバレッジ上限10x）

スコア	レバレッジ	証拠金
11-12	10x	エクイティの50%
13-14	10x	エクイティの70%（HIGH）
15+（APEX）	10x	エクイティの80%

レバレッジは10xを超えないでください。 KodiakとWolverineの両方で、10xが実証上の上限であることが確認されました。これを超えると、手数料とヒゲへの脆弱性によって優位性が失われます。

レバレッジは strategy_get_asset_trading_limits を介して、アセットごとのHyperliquidの上限に自動的に制限されます。

プロデューサーはスコア区分に基づいて marginUsd を計算し、シグナルデータに含めます。LLMゲートはこれをそのままランタイムのペイロードに渡します。

DSLプリセット（ミッドベータのデフォルト、v3.3+/v3.4から維持）

仕組み	値	理由
hard_timeout	1440 min（24h）	1日1回のトレードを徹底
weak_peak_cut	DISABLED	v3.3：APEXの基本方針が形成されるには4～8時間必要。2時間で3%という設定では早すぎました。
dead_weight_cut	60 min	値動きがなければ終了
フェーズ1 max_loss	20%	WolverineのHYPEショートを損失に導いたのと同じ水準ですが、あれは逆張りでした。KodiakのSOLトレードではフェーズ1に達しませんでした。
フェーズ1 retrace	8%
フェーズ2 tier 1	+8% / 30% HWロック	KodiakのTier 1
フェーズ2 tier 2	+15% / 50%	Tier 2
フェーズ2 tier 3	+25% / 70%	Kodiakの#3決済ティア
フェーズ2 tier 4	+40% / 85%	Kodiakの#1/#2決済ティア
フェーズ2 tier 5	+60% / 90%	大勝ちトレードには無限トレールを適用
フェーズ2 tier 6	+100% / 94%	モンスター級の勝ちトレード

リスク条件（runtime.yaml の risk.guard_rails）

条件	設定	置き換え対象
max_entries_per_day	1	v3.xの動的な1日の上限
per_asset_cooldown_minutes	120	v3.xの POST_EXIT_COOLDOWN_MINUTES
daily_loss_limit_pct	15	新規（フリート標準）
max_consecutive_losses	3	新規（フリート標準）
cooldown_minutes（損失後）	120	新規（フリート標準）
drawdown_halt_pct	25	v3.xの get_dynamic_daily_cap() ハードストップ
drawdown_reset_on_day_rollover	false	フリート標準（Roachの教訓）

ハードコードされた定数（設定不可）

• MAX_LEVERAGE: 10
• MIN_OI_USD: 1,000,000
• MIN_TRADER_COUNT: 50
• XYZ_BANNED: true
• STABLECOINS_BANNED: USDT, USDC, DAI, USDE, FDUSD, TUSD, BUSD
• UNIVERSE_SIZE: 50

ユーザーとの会話における Claude セッションの厳格なルール

ユーザーとの会話における Claude セッションでは、次のツールを呼び出してはなりません。 create_position、close_position、edit_position、 ratchet_stop_add、ratchet_stop_edit、ratchet_stop_delete、 cancel_order、strategy_close、strategy_close_positions。

これらのツールは、プロデューサーデーモン（エントリーパス）と DSL ラチェットエンジン（エグジットパス）専用です。ユーザーとの会話におけるセッションは読み取り専用です。

オペレーター向けインストール

v3.4 からの新規インストールおよび移行コマンドについては、README.md を参照してください。

変更履歴

v4.0.0 (2026-05-12) — 配線のみの移行

ヘルパーをネイティブに利用する方式（senpi_runtime_helpers）に移行しました。戦略の論旨は v3.4 から一言一句そのまま維持されています。

v3.4 (2026-05-05) — ゲート調整の修正

• v3.2 で厳格化しすぎた結果、13 日間の取引がゼロになりました。MIN_SCORE 13→12、MIN_SM 75→70、MIN_15M_VELOCITY 0.2→0.1。

v3.3 — weak_peak_cut を無効化

• 3% ROE での 2 時間カットが、アペックス戦略の展開を先回りして妨げていました。

v3.2 (2026-04-22) — ゲートの厳格化（v3.4 で元に戻しました）

v3.1 (2026-04-16) — BTC のハードゲートを削除

• BTC のマクロな方向性の一致を、ハードゲートからスコア加点のみに変更しました（HYPE/HIP-3 のデカップリング）。

v3.0 (2026-04-16) — 全面書き換え

• 戦略の論旨を変更：マルチアセット戦略ピッカーから、単一ポジションのトレンド継続を狙うアペックス・スナイパーへ
• ユニバースを拡大：主要銘柄 4 種から、24 時間の取引高上位 50 の HL 資産へ
• 3TF_ALIGNMENT ハードゲートと MACRO_TREND_GATE を追加
• スコアに応じてサイズを調整し、レバレッジを 10 倍に厳格に制限
• Kodiak の SOL 勝ちトレードの決済ティアを基に DSL プロファイルを調整
• 1 日 1 回の取引を徹底

ライセンス

MIT — Senpi により構築（https://senpi.ai）。

スキルの帰属情報

戦略を作成する際は、呼び出しに skill_name と skill_version を含めてください。詳細については references/skill-attribution.md を参照してください。