Contrarian Regime Switch¶
EA0045_Contrarian_Regime_Switch_v1.0 ／ ⚠️ FAILED — 生成失敗・修正失敗・BT不合格
ワンライナー
Contrarian Regime Switch
基本情報¶
| 項目 | 値 | 項目 | 値 | |
|---|---|---|---|---|
| シンボル | USDJPY | エントリー種別 | mean_cross | |
| 時間足 | H1 | エグジット | fixed_sl | |
| 方向 | both | 主要インジケータ | — |
🧬 DNA 4軸¶
| primary_style | entry_mechanism | regime_target | position_logic |
|---|---|---|---|
meta | mean_cross | any | fixed_sl |
📊 バックテスト結果¶
判定: ❌ FAIL ／ 期間: — 〜 —
| PF | 損益率 | 勝率 | 最大DD | シャープ | 取引数 |
|---|---|---|---|---|---|
| 1.78 | +4.11% | 42.9% | 6.00% | 0.42 | 10 |
📝 仕様書 / Specification¶
🇯🇵 クリックで展開（日本語版）
Research EA Spec: Contrarian Regime Switch¶
EA Identity¶
- EA name: REF0502_01_Contrarian_Regime_Switch_v1
- Symbol: USDJPY
- Timeframe: H1
- 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]) > slopeThresholdwhere slopeThreshold is a small positive value (e.g. 0.0001 * _Point). DO NOT define isBearishRegime asfastMA[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 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 asfastMA[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 requiringbullishRegime == truefor BUY entry, and ifbullishRegimeis defined as slope-based, this is logically sound. However, if the regime filter is interpreted as requiring the OPPOSITE regime (e.g., bearish regime for contrarian BUY), thenbullishCross && !bullishRegimewould create a time-dependent contradiction: a bullish cross (fastMA[1] > slowMA[1]) occurring while slow SMA slope is still negative (bearish regime) is theoretically possible but rare and creates a narrow window. The spec's emphasis on 'Regime MUST be independent' and the warning about inverse conditions suggests the implementer must be extremely careful to NOT accidentally invert the regime condition. The spec does not explicitly state the regime polarity for entry, creating ambiguity that could lead to zero trades if regime is inverted. - Fix: Explicitly state: 'For BUY entry, require bullishRegime == true (slope-based, independent of fastMA/slowMA). For SELL entry, require bullishRegime == false.' Alternatively, if contrarian intent requires opposite regime, state: 'For contrarian BUY, require bullishCross AND bullishRegime == false, but only if slowMA slope reversal is confirmed within N bars to avoid stale regime state.' Clarify regime polarity in entry condition.
- WARNING: Exit logic states 'Regime exit (faster): if slowSMA slope reverses past zero threshold, close before reverse cross.' This creates a potential race condition: if slowSMA slope reverses (becomes negative) on the same bar that fastMA is still above slowMA, the regime exit triggers. However, the entry condition requires fastMA[1] > slowMA[1] && fastMA[2] <= slowMA[2], meaning entry occurs only on the cross bar. If regime exit fires on the very next bar (bar[0]) due to slope reversal, the position is held for only 1 bar. More critically, if slope reversal happens BEFORE the reverse cross (fastMA < slowMA), the position is closed by regime exit, but the entry condition for the next trade may not fire if the regime is now bearish and the next cross is a bullish cross (which would require bullishRegime == true). This creates a scenario where the EA exits trades but cannot re-enter until regime stabilizes, potentially leading to extended no-trade periods. The spec does not clarify whether regime exit overrides the reverse cross exit or vice versa, and whether regime reversal prevents re-entry on the same bar.
- Fix: Define regime exit priority: 'Regime exit fires only if position has been held > N bars (e.g., 5 bars) to avoid whipsaw. Alternatively, regime exit is disabled if reverse cross is imminent (fastMA within 0.5*ATR of slowMA). Clarify: after regime exit, can re-entry occur on the same bar if cross signal is present, or must regime stabilize for 1+ bars first?'
- WARNING: Filters section lists 'Contrarian safety filter: disable after consecutive false signals' but does not define what constitutes a 'false signal' or how many consecutive false signals trigger the disable. If this filter is implemented as a hard stop (e.g., after 3 consecutive losing trades, stop trading for N bars), it could interact with the entry logic to create extended no-trade periods. Additionally, the spec states 'Regime filter: any regime confirmation' without specifying whether this means 'any regime is acceptable' (no filter) or 'regime must be confirmed in a specific direction'. If 'any regime' means no regime filter is applied, then the 'Contrarian safety filter' becomes the only gating mechanism, and its undefined behavior could lead to unpredictable trade frequency.
- Fix: Define: 'Consecutive false signals = N losing trades in a row (e.g., N=3). After N consecutive losses, disable entry for M bars (e.g., M=24 H1 bars = 1 day). Resume entry when regime confirmation is re-established or after M bars elapse, whichever is first.' Clarify 'any regime confirmation' as either 'no regime filter applied' or 'regime must be bullish for BUY, bearish for SELL'.
- WARNING: Regime filter polarity is ambiguous: 'any regime confirmation' does not specify whether BUY requires bullishRegime==true or bullishRegime==false (contrarian). Spec emphasizes regime independence but does not explicitly gate entry on regime direction. Implementation must clarify this before coding.
- WARNING: Exit logic mentions 'Regime exit (faster)' but does not define the priority order if both regime exit and reverse cross exit conditions are true on the same bar. This could cause unexpected early exits or missed exits.
- WARNING: Contrarian safety filter is mentioned but not formally defined. Its interaction with entry logic and regime filter is unclear. If this filter disables entry for extended periods, it could cause zero-trade windows.
- WARNING: Spec warns against defining isBearishRegime as fastMA[1] < slowMA[1] but does not explicitly state how bullishRegime should be used in the entry condition. Implementer must infer: 'BUY requires bullishRegime==true' from context, but this is not stated as a hard rule.
- WARNING: Time exit condition 'close if held more than InpMaxBars (default=72 H1 bars)' could interact with regime exit and reverse cross exit to create ambiguous exit priority. Clarify which exit takes precedence.
- WARNING: Optimization envelope states 'If no trades: loosen entry confirmation first, then session restriction, then ATR threshold.' This suggests entry confirmation may be tightened during optimization, which could exacerbate the regime polarity ambiguity if not carefully managed.
- WARNING: Backtest acceptance criteria mention 'OOS trade count is too low; first loosen entry filters before optimizing profit targets.' This implies entry filters may be overly restrictive, which combined with undefined regime polarity could result in zero trades in OOS testing.
🇬🇧 Click to expand (English version)
Research EA Spec: Contrarian Regime Switch¶
EA Identity¶
- EA name: REF0502_01_Contrarian_Regime_Switch_v1
- Symbol: USDJPY
- Timeframe: H1
- 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]) > slopeThresholdwhere slopeThreshold is a small positive value (e.g. 0.0001 * _Point). DO NOT define isBearishRegime asfastMA[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]ANDisBearishRegime = 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.,
bullishRegimeoruptrend) 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 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 asfastMA[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 requiringbullishRegime == truefor BUY entry, and ifbullishRegimeis defined as slope-based, this is logically sound. However, if the regime filter is interpreted as requiring the OPPOSITE regime (e.g., bearish regime for contrarian BUY), thenbullishCross && !bullishRegimewould create a time-dependent contradiction: a bullish cross (fastMA[1] > slowMA[1]) occurring while slow SMA slope is still negative (bearish regime) is theoretically possible but rare and creates a narrow window. The spec's emphasis on 'Regime MUST be independent' and the warning about inverse conditions suggests the implementer must be extremely careful to NOT accidentally invert the regime condition. The spec does not explicitly state the regime polarity for entry, creating ambiguity that could lead to zero trades if regime is inverted. - Fix: Explicitly state: 'For BUY entry, require bullishRegime == true (slope-based, independent of fastMA/slowMA). For SELL entry, require bullishRegime == false.' Alternatively, if contrarian intent requires opposite regime, state: 'For contrarian BUY, require bullishCross AND bullishRegime == false, but only if slowMA slope reversal is confirmed within N bars to avoid stale regime state.' Clarify regime polarity in entry condition.
- WARNING: Exit logic states 'Regime exit (faster): if slowSMA slope reverses past zero threshold, close before reverse cross.' This creates a potential race condition: if slowSMA slope reverses (becomes negative) on the same bar that fastMA is still above slowMA, the regime exit triggers. However, the entry condition requires fastMA[1] > slowMA[1] && fastMA[2] <= slowMA[2], meaning entry occurs only on the cross bar. If regime exit fires on the very next bar (bar[0]) due to slope reversal, the position is held for only 1 bar. More critically, if slope reversal happens BEFORE the reverse cross (fastMA < slowMA), the position is closed by regime exit, but the entry condition for the next trade may not fire if the regime is now bearish and the next cross is a bullish cross (which would require bullishRegime == true). This creates a scenario where the EA exits trades but cannot re-enter until regime stabilizes, potentially leading to extended no-trade periods. The spec does not clarify whether regime exit overrides the reverse cross exit or vice versa, and whether regime reversal prevents re-entry on the same bar.
- Fix: Define regime exit priority: 'Regime exit fires only if position has been held > N bars (e.g., 5 bars) to avoid whipsaw. Alternatively, regime exit is disabled if reverse cross is imminent (fastMA within 0.5*ATR of slowMA). Clarify: after regime exit, can re-entry occur on the same bar if cross signal is present, or must regime stabilize for 1+ bars first?'
- WARNING: Filters section lists 'Contrarian safety filter: disable after consecutive false signals' but does not define what constitutes a 'false signal' or how many consecutive false signals trigger the disable. If this filter is implemented as a hard stop (e.g., after 3 consecutive losing trades, stop trading for N bars), it could interact with the entry logic to create extended no-trade periods. Additionally, the spec states 'Regime filter: any regime confirmation' without specifying whether this means 'any regime is acceptable' (no filter) or 'regime must be confirmed in a specific direction'. If 'any regime' means no regime filter is applied, then the 'Contrarian safety filter' becomes the only gating mechanism, and its undefined behavior could lead to unpredictable trade frequency.
- Fix: Define: 'Consecutive false signals = N losing trades in a row (e.g., N=3). After N consecutive losses, disable entry for M bars (e.g., M=24 H1 bars = 1 day). Resume entry when regime confirmation is re-established or after M bars elapse, whichever is first.' Clarify 'any regime confirmation' as either 'no regime filter applied' or 'regime must be bullish for BUY, bearish for SELL'.
- WARNING: Regime filter polarity is ambiguous: 'any regime confirmation' does not specify whether BUY requires bullishRegime==true or bullishRegime==false (contrarian). Spec emphasizes regime independence but does not explicitly gate entry on regime direction. Implementation must clarify this before coding.
- WARNING: Exit logic mentions 'Regime exit (faster)' but does not define the priority order if both regime exit and reverse cross exit conditions are true on the same bar. This could cause unexpected early exits or missed exits.
- WARNING: Contrarian safety filter is mentioned but not formally defined. Its interaction with entry logic and regime filter is unclear. If this filter disables entry for extended periods, it could cause zero-trade windows.
- WARNING: Spec warns against defining isBearishRegime as fastMA[1] < slowMA[1] but does not explicitly state how bullishRegime should be used in the entry condition. Implementer must infer: 'BUY requires bullishRegime==true' from context, but this is not stated as a hard rule.
- WARNING: Time exit condition 'close if held more than InpMaxBars (default=72 H1 bars)' could interact with regime exit and reverse cross exit to create ambiguous exit priority. Clarify which exit takes precedence.
- WARNING: Optimization envelope states 'If no trades: loosen entry confirmation first, then session restriction, then ATR threshold.' This suggests entry confirmation may be tightened during optimization, which could exacerbate the regime polarity ambiguity if not carefully managed.
- WARNING: Backtest acceptance criteria mention 'OOS trade count is too low; first loosen entry filters before optimizing profit targets.' This implies entry filters may be overly restrictive, which combined with undefined regime polarity could result in zero trades in OOS testing.
免責事項
本EAは自動生成された検証用コードです。実運用可否はご自身で検証してください。
関連用語¶
— SPONSORED —