コンテンツにスキップ

Contrarian Regime Switch

EA0047_Contrarian_Regime_Switch_v1.0 ／ 🧪 候補 — 生成済み・検証待ち

ワンライナー

Contrarian Regime Switch

基本情報

項目 値 項目 値
シンボル USDJPY エントリー種別 mean_cross
時間足 H4 エグジット fixed_sl
方向 both 主要インジケータ —

🧬 DNA 4軸

primary_style entry_mechanism regime_target position_logic
meta mean_cross any fixed_sl

📊 バックテスト結果

未実行

📝 仕様書 / Specification

🇯🇵 クリックで展開（日本語版）

Research EA Spec: Contrarian Regime Switch

EA Identity

  • EA name: REF0503_01_Contrarian_Regime_Switch_v1
  • Symbol: USDJPY
  • Timeframe:
  • Primary style: meta
  • Entry mechanism: mean_cross
  • Regime target: any
  • Position logic: fixed_sl

Research Thesis

Contrarian Regime Switch candidate generated from 1 research source(s). The strategy must preserve the source idea while keeping parameters broad enough to survive out-of-sample testing.

Source Evidence

  • [CONTRA] 「勝率90%」を謳う戦略はほぼ確実に マーチンゲール / ナンピン / 無SL のいずれか、中長期で破綻
  • [CONTRA] バックテストで「きれいな右肩上がり」はカーブフィッティングの兆候、実運用で逆転
  • [CONTRA] 「無敗のEA」「必勝EA」の商業売りは詐欺、本物は売らない
  • [CONTRA] 新しい指標の組み合わせより、既存戦略に「時間帯フィルター」追加の方が有効なことが多い

Tradable Spec

  • Entry logic: BUY entry: fast SMA (input default period=10) crosses above slow SMA (input default period=50) on confirmed bar[1] — condition: fastMA[1] > slowMA[1] && fastMA[2] <= slowMA[2]. SELL entry: fast SMA crosses below slow SMA — fastMA[1] < slowMA[1] && fastMA[2] >= slowMA[2]. CRITICAL — Regime MUST be independent from cross signal: define regime using slow SMA slope over 20 bars: bullishRegime = (slowMA[1] - slowMA[20]) > slopeThreshold where slopeThreshold is a small positive value (e.g. 0.0001 * _Point). DO NOT define isBearishRegime as fastMA[1] < slowMA[1] — that is the inverse of the cross condition and creates a logical contradiction (bullishCross AND isBearishRegime can never both be true on the same bar). ONE regime variable only: use EITHER slope-based OR price-vs-MA — never AND both together in the entry condition.
  • Exit logic: Exit trigger: reverse MA cross (fast SMA crosses back through slow SMA in opposite direction). Regime exit (faster): if slowSMA slope reverses past zero threshold, close before reverse cross. Hard stop: initial ATR-based SL (InpSLATR * atr[1], default=1.5) — fixed, not trailed. No fixed TP target — the cross itself manages the exit. Time exit: close if held more than InpMaxBars (default=72 H1 bars = 3 days) without exit signal.
  • Risk management: Fixed fractional risk per trade, no martingale, no grid expansion, max one position per symbol, and hard daily loss guard.
  • Regime filter: any regime confirmation
  • Invalidation condition: To be determined during testing or derived from logic

Filters

  • Spread and session filter
  • Minimum ATR activity filter
  • Contrarian safety filter: disable after consecutive false signals

Logic Independence Requirements

必須チェック（実装前に確認すること）:

  • エントリーシグナル変数とレジームフィルター変数は独立したデータ源または独立したlookbackから計算すること
  • 悪い例: bullishCross = fastMA[1] > slowMA[1] と isBearishRegime = fastMA[1] < slowMA[1] を AND 結合 → 同一バーで両立不可、取引ゼロになる
  • 正しいレジーム定義: slowMA[1] - slowMA[10] の傾き、上位足のMA方向、長い lookback（50本以上）の傾き
  • 全フィルターを AND 結合した時に、理論上発火できるバーが存在することをスケッチで確認すること
  • 逆張り戦略では「エントリー条件の否定 ≠ レジーム条件」になっているか必ず確認すること
  • RSI・BB・ATR など同一インジケーターを「シグナル源」と「フィルター源」の両方に使う場合、同じバーで矛盾する不等式を要求していないか確認すること
  • レジーム変数は1本のみ: bullishRegime (または uptrend 等) という bool 変数を1つ定義し、エントリー条件の AND に使うのはその1変数のみにすること。bullishRegime && regimeUp のように2本のレジーム変数を AND 結合することを禁止する。スロープ・価格位置・ADX など複数軸で判断したい場合は、それらを統合した1本の bool 変数にまとめてから AND に組み込むこと。

Optimization Envelope

  • Relaxable: confirmation thresholds, ATR activity threshold, session window, signal confirmation bars.
  • Not relaxable: stop-loss discipline, max one position, no martingale, no fixed historical price levels.
  • Initial optimization scope: 3-5 parameters only.
  • If no trades: loosen entry confirmation first, then session restriction, then ATR threshold.
  • If too many trades: strengthen regime filter and minimum signal distance.

Backtest Acceptance

  • Backtest at least 18 months with the latest 3 months held out.
  • Use walk-forward setting 6:2 when MT5 runner is available.
  • Reject if OOS/IS PF ratio is below 0.70 or if OOS PF min is below 1.10.
  • Reject if OOS trade count is too low; first loosen entry filters before optimizing profit targets.

Overfitting Controls

  • Keep each numeric parameter in a wide theory-backed range; do not tune to a single date range.
  • Limit optimization to 3-5 core parameters in the first pass.
  • Prefer regime filters with clear market meaning over curve-fitted thresholds.
  • Stop improving the candidate after repeated NO_TRADE/LOW_SAMPLE failures.

Learning Feedback

  • ledger: 1 prior strategy failure(s) for this DNA
  • ledger: 2 prior infra/incomplete run(s) for this DNA
  • ledger: improve: rerun backtest to get all WF windows; do not modify strategy until clean BT exists
  • ledger: improve: rerun the same candidate after repairing backtest artifacts
  • ledger: improve: inspect MT5 report generation before changing strategy logic

Implementation Guardrails

  • [META] [RISK] [CONTRA] MT5 Strategy Testerは同名EAのinput値をキャッシュすることがあり、mq5側のinputデフォルトを変更して再コンパイルしても、BTでは前回値が使われる場合がある。inputデフォルト変更の検証では、別EA名/別ファイル名にするか、tester.ini/ExpertParametersで明示的に値を渡し、Testerログの「started with inputs」を必ず確認する。 (.clinerules)
  • [RISK] [META] [CONTRA] 【部分決済後のコメント管理パターン】MQL5ではPositionModifyでコメントを変更できないため、TP1部分決済後の状態管理にコメントプレフィックスを使う設計は「二重部分決済」リスクを内包する。対策として: (1)グローバルなulong配列でTP1済みチケットを管理する、(2)部分決済後に残りを即クローズ→新コメントで再エントリーする、のいずれかのパターンを採用すること。 (.clinerules)
  • [META] HistorySelect(0, TimeCurrent()) は全取引履歴を走査対象にするため、長期運用や多数の取引がある口座ではパフォーマンスに影響する。連敗カウント等の直近履歴のみが必要な場合は、開始時刻を限定する（例: TimeCurrent() - 30243600）か、最後のチェック時刻を記録して差分走査にする。 (.clinerules)
  • [META] MQL5のOnTradeTransactionではDEAL_ENTRY_INOUTも処理対象に含めないと、ネッティング口座での約定イベントを捕捉できない場合がある (.clinerules)
  • [META] OnTradeTransactionでHistoryDealSelectを使用する際、DEAL_ENTRY_OUTとDEAL_ENTRY_INOUTの両方を処理することで、ネッティング口座とヘッジ口座の両方に対応できる。この2値チェックパターンは連敗カウント等の決済イベント処理の標準実装として有効。 (.clinerules)
  • [META] OnTradeイベントでHistorySelect(0, TimeCurrent())による全履歴スキャンは、取引履歴が長期化するとパフォーマンス劣化を招く。g_last_processed_dealに対応する時刻を別途保持し、HistorySelectの開始時刻を直近に絞り込むパターンが推奨される。 (.clinerules)
  • [META] OnTrade内のHistorySelectの時間範囲設計: HistorySelect(TimeCurrent() - N, TimeCurrent())のNが短すぎると、処理遅延や複数決済重複時に取りこぼしが発生する。最低でも300秒（5分）以上を推奨。 (.clinerules)
  • [META] [E2] bid/askの取得にSymbolInfoDouble(_Symbol, SYMBOL_BID/ASK)を使用しているが、その前にRefreshRates()を呼んでいない。CSymbolInfoクラスを使用していないため、最新レートの保証がない。 (.clinerules)

Story Package

  • Hook: AIが研究メモから自律発掘した「Contrarian Regime Switch」をEA化して検証。
  • Blog angle: 研究アイデアは本当にMT5で再現できるのか、OOSで崩れるかまで公開する。
  • Failure angle: 失敗時は NO_TRADE / LOW_SAMPLE / OVERFIT / HIGH_DD に分類して次の研究候補へ進む。

Spec Validation Warnings (auto-generated)

  • CONTRADICTION: Entry logic defines bullishCross as fastMA[1] > slowMA[1] && fastMA[2] <= slowMA[2]. Regime filter section states regime must be defined using slow SMA slope: bullishRegime = (slowMA[1] - slowMA[20]) > slopeThreshold. However, the spec explicitly warns: 'DO NOT define isBearishRegime as fastMA[1] < slowMA[1] — that is the inverse of the cross condition and creates a logical contradiction'. The critical guidance then states: 'bullishCross AND isBearishRegime can never both be true on the same bar'. While the spec correctly defines regime via slope (not via fastMA/slowMA comparison), the entry logic section does not explicitly state which regime condition gates the BUY entry. If the implementation interprets 'Regime filter: any regime confirmation' as requiring bullishRegime == true for BUY entry, and if bullishRegime is defined as slope-based, this is logically sound. However, the spec's emphasis on 'ONE regime variable only' and the warning about AND-combining regime variables suggests risk of misinterpretation during coding. The spec does not explicitly state: 'BUY entry requires fastMA[1] > slowMA[1] && fastMA[2] <= slowMA[2] AND bullishRegime'. Without this explicit gate, a coder might apply regime filtering inconsistently or apply contradictory regime logic.
  • Fix: Explicitly state in Entry logic section: 'BUY entry: fastMA[1] > slowMA[1] && fastMA[2] <= slowMA[2] AND bullishRegime (where bullishRegime = (slowMA[1] - slowMA[20]) > slopeThreshold)'. Similarly for SELL. Remove ambiguity by making regime gate explicit in the entry condition formula.
  • WARNING: Spec states 'Regime exit (faster): if slowSMA slope reverses past zero threshold, close before reverse cross.' This implies regime exit can trigger independently of the reverse MA cross exit. However, the spec also states 'No fixed TP target — the cross itself manages the exit' and 'Exit trigger: reverse MA cross'. If regime exit and reverse cross exit are both active, and regime slope reverses before the cross reverses, the position closes on regime exit. But if the cross reverses first, the position closes on cross exit. The spec does not define priority or mutual exclusivity. More critically, if slowSMA slope is used for both regime entry filter AND regime exit trigger, a scenario arises: (1) Position enters when bullishRegime=true (slope > threshold). (2) Slope gradually declines but remains > threshold. (3) Slope crosses zero threshold downward → regime exit triggers, position closes. (4) On the same or next bar, fastMA/slowMA cross reverses → reverse cross exit would trigger, but position is already closed. This is not a logical contradiction (exit can occur before reverse cross), but it creates a dependency: if regime exit fires frequently, the reverse cross exit becomes dormant, and the strategy's exit logic is dominated by slope reversals rather than MA crosses. The spec does not clarify whether this is intentional or a design flaw. If slope reversals are too frequent, trades may close prematurely, reducing profitability. However, this is a design ambiguity rather than a logical impossibility that prevents all trades.
  • Fix: Clarify exit priority: (1) Does regime exit override reverse cross exit, or vice versa? (2) If both are active, which fires first? (3) Define 'reverses past zero threshold' precisely: is it slope[1] > 0 && slope[2] <= 0, or a different lookback? (4) Consider whether slope reversals are frequent enough to dominate exit logic, and if so, whether this aligns with the strategy's intent.
  • WARNING: Spec mentions 'Contrarian safety filter: disable after consecutive false signals' in Filters section but does not define what constitutes a 'false signal' or how many consecutive false signals trigger disablement. This is a design gap that must be clarified before implementation.
  • WARNING: Spec states 'Regime filter: any regime confirmation' but does not explicitly define what 'any regime confirmation' means. Does it mean bullishRegime OR bearishRegime (i.e., any non-neutral regime)? Or does it mean regime filter is optional? Clarify whether regime filter is mandatory for entry or optional.
  • WARNING: Spec defines 'Invalidation condition: To be determined during testing or derived from logic'. This is incomplete. Invalidation conditions should be specified before backtest, not derived during testing, to avoid curve-fitting.
  • WARNING: Spec warns against AND-combining multiple regime variables (e.g., 'bullishRegime && regimeUp'), but does not explicitly state how many regime variables are defined in this EA. If only one (bullishRegime via slope) is used, this is compliant. If multiple are defined elsewhere, this warning applies.
  • WARNING: Entry logic uses bar[1] and bar[2] for cross confirmation, but Filters section mentions 'Minimum ATR activity filter' without specifying which bar's ATR is checked (ATR[1], ATR[2], or average). If ATR filter uses a different bar index than entry signal, ensure they are not contradictory (e.g., ATR[1] < threshold while close[1] breaks highest[N]).
  • WARNING: Spec states 'Hard stop: initial ATR-based SL (InpSLATR * atr[1], default=1.5) — fixed, not trailed.' This is clear, but spec also mentions 'Time exit: close if held more than InpMaxBars (default=72 H1 bars = 3 days) without exit signal.' If timeframe is not specified (Timeframe field is empty in EA Identity), the meaning of '72 H1 bars' is ambiguous. Clarify timeframe or define time exit in absolute seconds.
  • WARNING: Spec references 'Spread and session filter' in Filters section but provides no details on session window or spread threshold. These must be defined before implementation to avoid ambiguity.
  • WARNING: Learning Feedback section mentions '1 prior strategy failure(s) for this DNA' and '2 prior infra/incomplete run(s)'. This suggests the strategy has been tested before and failed. Spec recommends 'rerun backtest to get all WF windows; do not modify strategy until clean BT exists'. Ensure prior failures are resolved before implementation.
  • WARNING: Implementation Guardrails section includes multiple MQL5-specific warnings (MT5 input caching, partial close comment management, HistorySelect performance, OnTradeTransaction handling, bid/ask refresh). These are implementation notes, not logic contradictions, but they indicate the strategy is complex and requires careful coding. Ensure all guardrails are followed during implementation.
🇬🇧 Click to expand (English version)

Research EA Spec: Contrarian Regime Switch

EA Identity

  • EA name: REF0503_01_Contrarian_Regime_Switch_v1
  • Symbol: USDJPY
  • Timeframe:
  • Primary style: meta
  • Entry mechanism: mean_cross
  • Regime target: any
  • Position logic: fixed_sl

Research Thesis

Contrarian Regime Switch candidate generated from 1 research source(s). The strategy must preserve the source idea while keeping parameters broad enough to survive out-of-sample testing.

Source Evidence

  • [CONTRA] 「勝率90%」を謳う戦略はほぼ確実に マーチンゲール / ナンピン / 無SL のいずれか、中長期で破綻
  • [CONTRA] バックテストで「きれいな右肩上がり」はカーブフィッティングの兆候、実運用で逆転
  • [CONTRA] 「無敗のEA」「必勝EA」の商業売りは詐欺、本物は売らない
  • [CONTRA] 新しい指標の組み合わせより、既存戦略に「時間帯フィルター」追加の方が有効なことが多い

Tradable Spec

  • Entry logic: BUY entry: fast SMA (input default period=10) crosses above slow SMA (input default period=50) on confirmed bar[1] — condition: fastMA[1] > slowMA[1] && fastMA[2] <= slowMA[2]. SELL entry: fast SMA crosses below slow SMA — fastMA[1] < slowMA[1] && fastMA[2] >= slowMA[2]. CRITICAL — Regime MUST be independent from cross signal: define regime using slow SMA slope over 20 bars: bullishRegime = (slowMA[1] - slowMA[20]) > slopeThreshold where slopeThreshold is a small positive value (e.g. 0.0001 * _Point). DO NOT define isBearishRegime as fastMA[1] < slowMA[1] — that is the inverse of the cross condition and creates a logical contradiction (bullishCross AND isBearishRegime can never both be true on the same bar). ONE regime variable only: use EITHER slope-based OR price-vs-MA — never AND both together in the entry condition.
  • Exit logic: Exit trigger: reverse MA cross (fast SMA crosses back through slow SMA in opposite direction). Regime exit (faster): if slowSMA slope reverses past zero threshold, close before reverse cross. Hard stop: initial ATR-based SL (InpSLATR * atr[1], default=1.5) — fixed, not trailed. No fixed TP target — the cross itself manages the exit. Time exit: close if held more than InpMaxBars (default=72 H1 bars = 3 days) without exit signal.
  • Risk management: Fixed fractional risk per trade, no martingale, no grid expansion, max one position per symbol, and hard daily loss guard.
  • Regime filter: any regime confirmation
  • Invalidation condition: To be determined during testing or derived from logic

Filters

  • Spread and session filter
  • Minimum ATR activity filter
  • Contrarian safety filter: disable after consecutive false signals

Logic Independence Requirements

Mandatory check (must verify before implementation):

  • Entry signal variables and regime filter variables must be calculated from independent data sources or independent lookback periods.
  • Bad example: bullishCross = fastMA[1] > slowMA[1] AND isBearishRegime = fastMA[1] < slowMA[1] — these cannot both be true on the same bar, resulting in zero trades.
  • Correct regime definition: slope of slowMA[1] - slowMA[10], higher timeframe MA direction, or slope over a long lookback (50+ bars).
  • When all filters are AND-combined, sketch-verify that at least one bar can theoretically trigger.
  • For mean-reversion strategies, always verify that "negation of entry condition ≠ regime condition".
  • When using the same indicator (RSI, BB, ATR, etc.) as both "signal source" and "filter source", confirm you are not demanding contradictory inequalities on the same bar.
  • Single regime variable only: Define exactly one bool variable (e.g., bullishRegime or uptrend) and use only that one variable in the entry AND condition. Ban combining two regime variables with AND (e.g., bullishRegime && regimeUp). If you need to judge across multiple axes (slope, price position, ADX), merge them into a single composite bool variable before AND-combining.

Optimization Envelope

  • Relaxable: confirmation thresholds, ATR activity threshold, session window, signal confirmation bars.
  • Not relaxable: stop-loss discipline, max one position, no martingale, no fixed historical price levels.
  • Initial optimization scope: 3-5 parameters only.
  • If no trades: loosen entry confirmation first, then session restriction, then ATR threshold.
  • If too many trades: strengthen regime filter and minimum signal distance.

Backtest Acceptance

  • Backtest at least 18 months with the latest 3 months held out.
  • Use walk-forward setting 6:2 when MT5 runner is available.
  • Reject if OOS/IS PF ratio is below 0.70 or if OOS PF min is below 1.10.
  • Reject if OOS trade count is too low; first loosen entry filters before optimizing profit targets.

Overfitting Controls

  • Keep each numeric parameter in a wide theory-backed range; do not tune to a single date range.
  • Limit optimization to 3-5 core parameters in the first pass.
  • Prefer regime filters with clear market meaning over curve-fitted thresholds.
  • Stop improving the candidate after repeated NO_TRADE/LOW_SAMPLE failures.

Learning Feedback

  • ledger: 1 prior strategy failure(s) for this DNA
  • ledger: 2 prior infra/incomplete run(s) for this DNA
  • ledger: improve: rerun backtest to get all WF windows; do not modify strategy until clean BT exists
  • ledger: improve: rerun the same candidate after repairing backtest artifacts
  • ledger: improve: inspect MT5 report generation before changing strategy logic

Implementation Guardrails

  • [META] [RISK] [CONTRA] MT5 Strategy Testerは同名EAのinput値をキャッシュすることがあり、mq5側のinputデフォルトを変更して再コンパイルしても、BTでは前回値が使われる場合がある。inputデフォルト変更の検証では、別EA名/別ファイル名にするか、tester.ini/ExpertParametersで明示的に値を渡し、Testerログの「started with inputs」を必ず確認する。 (.clinerules)
  • [RISK] [META] [CONTRA] 【部分決済後のコメント管理パターン】MQL5ではPositionModifyでコメントを変更できないため、TP1部分決済後の状態管理にコメントプレフィックスを使う設計は「二重部分決済」リスクを内包する。対策として: (1)グローバルなulong配列でTP1済みチケットを管理する、(2)部分決済後に残りを即クローズ→新コメントで再エントリーする、のいずれかのパターンを採用すること。 (.clinerules)
  • [META] HistorySelect(0, TimeCurrent()) は全取引履歴を走査対象にするため、長期運用や多数の取引がある口座ではパフォーマンスに影響する。連敗カウント等の直近履歴のみが必要な場合は、開始時刻を限定する（例: TimeCurrent() - 30243600）か、最後のチェック時刻を記録して差分走査にする。 (.clinerules)
  • [META] MQL5のOnTradeTransactionではDEAL_ENTRY_INOUTも処理対象に含めないと、ネッティング口座での約定イベントを捕捉できない場合がある (.clinerules)
  • [META] OnTradeTransactionでHistoryDealSelectを使用する際、DEAL_ENTRY_OUTとDEAL_ENTRY_INOUTの両方を処理することで、ネッティング口座とヘッジ口座の両方に対応できる。この2値チェックパターンは連敗カウント等の決済イベント処理の標準実装として有効。 (.clinerules)
  • [META] OnTradeイベントでHistorySelect(0, TimeCurrent())による全履歴スキャンは、取引履歴が長期化するとパフォーマンス劣化を招く。g_last_processed_dealに対応する時刻を別途保持し、HistorySelectの開始時刻を直近に絞り込むパターンが推奨される。 (.clinerules)
  • [META] OnTrade内のHistorySelectの時間範囲設計: HistorySelect(TimeCurrent() - N, TimeCurrent())のNが短すぎると、処理遅延や複数決済重複時に取りこぼしが発生する。最低でも300秒（5分）以上を推奨。 (.clinerules)
  • [META] [E2] bid/askの取得にSymbolInfoDouble(_Symbol, SYMBOL_BID/ASK)を使用しているが、その前にRefreshRates()を呼んでいない。CSymbolInfoクラスを使用していないため、最新レートの保証がない。 (.clinerules)

Story Package

  • Hook: AI autonomously discovered "Contrarian Regime Switch" from research notes and converted it into an EA for verification.
  • Blog angle: Can a research idea truly be reproduced on MT5? We publish results all the way through to OOS decay.
  • Failure angle: Failures are classified as NO_TRADE / LOW_SAMPLE / OVERFIT / HIGH_DD and fed into the next research candidate pipeline.

Spec Validation Warnings (auto-generated)

  • CONTRADICTION: Entry logic defines bullishCross as fastMA[1] > slowMA[1] && fastMA[2] <= slowMA[2]. Regime filter section states regime must be defined using slow SMA slope: bullishRegime = (slowMA[1] - slowMA[20]) > slopeThreshold. However, the spec explicitly warns: 'DO NOT define isBearishRegime as fastMA[1] < slowMA[1] — that is the inverse of the cross condition and creates a logical contradiction'. The critical guidance then states: 'bullishCross AND isBearishRegime can never both be true on the same bar'. While the spec correctly defines regime via slope (not via fastMA/slowMA comparison), the entry logic section does not explicitly state which regime condition gates the BUY entry. If the implementation interprets 'Regime filter: any regime confirmation' as requiring bullishRegime == true for BUY entry, and if bullishRegime is defined as slope-based, this is logically sound. However, the spec's emphasis on 'ONE regime variable only' and the warning about AND-combining regime variables suggests risk of misinterpretation during coding. The spec does not explicitly state: 'BUY entry requires fastMA[1] > slowMA[1] && fastMA[2] <= slowMA[2] AND bullishRegime'. Without this explicit gate, a coder might apply regime filtering inconsistently or apply contradictory regime logic.
  • Fix: Explicitly state in Entry logic section: 'BUY entry: fastMA[1] > slowMA[1] && fastMA[2] <= slowMA[2] AND bullishRegime (where bullishRegime = (slowMA[1] - slowMA[20]) > slopeThreshold)'. Similarly for SELL. Remove ambiguity by making regime gate explicit in the entry condition formula.
  • WARNING: Spec states 'Regime exit (faster): if slowSMA slope reverses past zero threshold, close before reverse cross.' This implies regime exit can trigger independently of the reverse MA cross exit. However, the spec also states 'No fixed TP target — the cross itself manages the exit' and 'Exit trigger: reverse MA cross'. If regime exit and reverse cross exit are both active, and regime slope reverses before the cross reverses, the position closes on regime exit. But if the cross reverses first, the position closes on cross exit. The spec does not define priority or mutual exclusivity. More critically, if slowSMA slope is used for both regime entry filter AND regime exit trigger, a scenario arises: (1) Position enters when bullishRegime=true (slope > threshold). (2) Slope gradually declines but remains > threshold. (3) Slope crosses zero threshold downward → regime exit triggers, position closes. (4) On the same or next bar, fastMA/slowMA cross reverses → reverse cross exit would trigger, but position is already closed. This is not a logical contradiction (exit can occur before reverse cross), but it creates a dependency: if regime exit fires frequently, the reverse cross exit becomes dormant, and the strategy's exit logic is dominated by slope reversals rather than MA crosses. The spec does not clarify whether this is intentional or a design flaw. If slope reversals are too frequent, trades may close prematurely, reducing profitability. However, this is a design ambiguity rather than a logical impossibility that prevents all trades.
  • Fix: Clarify exit priority: (1) Does regime exit override reverse cross exit, or vice versa? (2) If both are active, which fires first? (3) Define 'reverses past zero threshold' precisely: is it slope[1] > 0 && slope[2] <= 0, or a different lookback? (4) Consider whether slope reversals are frequent enough to dominate exit logic, and if so, whether this aligns with the strategy's intent.
  • WARNING: Spec mentions 'Contrarian safety filter: disable after consecutive false signals' in Filters section but does not define what constitutes a 'false signal' or how many consecutive false signals trigger disablement. This is a design gap that must be clarified before implementation.
  • WARNING: Spec states 'Regime filter: any regime confirmation' but does not explicitly define what 'any regime confirmation' means. Does it mean bullishRegime OR bearishRegime (i.e., any non-neutral regime)? Or does it mean regime filter is optional? Clarify whether regime filter is mandatory for entry or optional.
  • WARNING: Spec defines 'Invalidation condition: To be determined during testing or derived from logic'. This is incomplete. Invalidation conditions should be specified before backtest, not derived during testing, to avoid curve-fitting.
  • WARNING: Spec warns against AND-combining multiple regime variables (e.g., 'bullishRegime && regimeUp'), but does not explicitly state how many regime variables are defined in this EA. If only one (bullishRegime via slope) is used, this is compliant. If multiple are defined elsewhere, this warning applies.
  • WARNING: Entry logic uses bar[1] and bar[2] for cross confirmation, but Filters section mentions 'Minimum ATR activity filter' without specifying which bar's ATR is checked (ATR[1], ATR[2], or average). If ATR filter uses a different bar index than entry signal, ensure they are not contradictory (e.g., ATR[1] < threshold while close[1] breaks highest[N]).
  • WARNING: Spec states 'Hard stop: initial ATR-based SL (InpSLATR * atr[1], default=1.5) — fixed, not trailed.' This is clear, but spec also mentions 'Time exit: close if held more than InpMaxBars (default=72 H1 bars = 3 days) without exit signal.' If timeframe is not specified (Timeframe field is empty in EA Identity), the meaning of '72 H1 bars' is ambiguous. Clarify timeframe or define time exit in absolute seconds.
  • WARNING: Spec references 'Spread and session filter' in Filters section but provides no details on session window or spread threshold. These must be defined before implementation to avoid ambiguity.
  • WARNING: Learning Feedback section mentions '1 prior strategy failure(s) for this DNA' and '2 prior infra/incomplete run(s)'. This suggests the strategy has been tested before and failed. Spec recommends 'rerun backtest to get all WF windows; do not modify strategy until clean BT exists'. Ensure prior failures are resolved before implementation.
  • WARNING: Implementation Guardrails section includes multiple MQL5-specific warnings (MT5 input caching, partial close comment management, HistorySelect performance, OnTradeTransaction handling, bid/ask refresh). These are implementation notes, not logic contradictions, but they indicate the strategy is complex and requires careful coding. Ensure all guardrails are followed during implementation.

免責事項

本EAは自動生成された検証用コードです。実運用可否はご自身で検証してください。

EA1000 一覧に戻る

関連用語

🚀 FXおもしろラボからのお知らせ

AI が自動生成する FX 朝刊シグナル＆コスト 80% 削減の裏側を公開する教材を準備中です。

🎓 UO 教材（準備中） 📊 Discord シグナル（準備中）
— SPONSORED —