BTC Deribit मासिक ATM सस्ते-vol regime में Long Straddle, प्रवेश पर Delta-Neutral (Cross-Venue: DERIBIT Options + BINANCE Perp realized-vol signal source के रूप में, जब IV rank कम हो और AND realized vol बढ़ रहा हो तब vol खरीदें, कठोर premium stop, लगभग 12-20 trades/year)

Deribit BTC मासिक ऑप्शनों पर एक LONG-VOLATILITY विकल्प रणनीति, जिसे जानबूझकर फ़ैक्टरी की मौजूदा शॉर्ट-वोल पुस्तिका (ETH मासिक आयरन कंडोर) और अत्यधिक लॉन्ग-ओनली, लॉन्ग-बीटा पोर्टफ़ोलियो (84.2% long_only, 73.9% BINANCE USD-M) के OPPOSITE SIGN के रूप में रखा गया है। यह एक साथ तीन कम-प्रतिनिधित्व वाले कोटा वर्गों को पूरा करती है: ऑप्शन वेन्यू (DERIBIT 3.7% बनाम >=15% लक्ष्य), क्रॉस-वेन्यू (6.9% बनाम >=15%), और नॉन-लॉन्ग-ओनली एक्सपोज़र। ट्रेड एक साधारण ATM STRADDLE है — Deribit BTC पर 1 निकटतम-मासिक ATM कॉल + 1 निकटतम-मासिक ATM पुट खरीदना, जो शुरुआत में लगभग डेल्टा-न्यूट्रल होता है और इसलिए दिशा पर नहीं, वोलैटिलिटी पर शुद्ध दाँव है। अहम बात यह है कि इसे परपेचुअल लेग से NOT डेल्टा-हेज नहीं किया जाता: पिछली 'BTC Weekly Delta-Hedged Short Strangle' लगातार रीहेजिंग के हिसाब-किताब के कारण हुए 300s स्मोक-टेस्ट टाइमआउट में सत्यापन के दौरान विफल हो गई थी। यहाँ Binance परपेचुअल का उपयोग ONLY realized volatility के केवल-पठन संकेत स्रोत के रूप में किया जाता है (BTCUSDT.BINANCE 1H बार), इसे कभी ट्रेड नहीं किया जाता; इसलिए प्रति-बार काम O(1) रहता है और सभी IV/RV श्रृंखलाएँ __init__ में पहले से arrays में गणना करके bisect से देखी जाती हैं। बाज़ार-स्थिति गेट: क्रिप्टो का वोलैटिलिटी रिस्क प्रीमियम ON AVERAGE सकारात्मक है (इसीलिए शॉर्ट-वोल पुस्तिकाएँ मौजूद हैं), इसलिए बिना शर्त लॉन्ग-स्ट्रैडल का थीटा क्षय निश्चित है। एज का उपयोग केवल सशर्त टेल में किया जाता है: ONLY तब प्रवेश करें जब निहित वोलैटिलिटी अपने इतिहास के सापेक्ष CHEAP हो AND realized volatility पहले से बढ़ रही हो — यही वह विशिष्ट व्यवस्था है जिसमें VRP उलट जाता है और IV को ऊपर की ओर RV का पीछा करना पड़ता है। आवृत्ति कम है (लगभग हर मासिक एक्सपायरी चक्र में एक संभावित एंट्री, ~12-20 ट्रेड/वर्ष), होल्डिंग 5-20 दिन की है, इसलिए ~0.06% RT Deribit शुल्क उस स्ट्रैडल P&L की तुलना में नगण्य है जो प्रीमियम के पूरे प्रतिशत अंकों में बदलता है।

Iteration 9 लेयर-3 की “No trades produced” विफलता को ठीक करता है, बिना किसी वोलैटिलिटी सीमा को छुए, क्योंकि कुछ भी बदलने से पहले मैंने वास्तविक डेटा पर गेट को मापा: deribit_dvol BTC + BTCUSDT 1-DAY क्लोज़ पर कोड की गई शर्तों को रीप्ले करने पर, iv_rank<=0.30 वैध बारों में से 45.5% पर सक्रिय होता है, rv7/rv30>=1.15 26.2% पर, iv<=1.30*rv7 49.0% पर, और 3-तरफ़ा संयुक्त शर्त 1,988 बारों में से 188 पर (9.5%)। एज सक्रिय होता है; उसे बस निष्पादित होने की जगह नहीं मिली — lookback_days 270 केवल 9 मासिक चक्रों तक उपलब्ध था और हर चक्र (expiry-30d) पर केवल 5 दिनों के लिए खुला था, और क्रमिक ट्रेड रीप्ले उस संयोजन के लिए ठीक 0 प्रविष्टियाँ देता है। lookback_days को 365 तक बढ़ाने (12 चक्र, 24 ऑप्शन बार प्रकार — ~600s के ऑप्शन-रन वॉल-क्लॉक से कम; 540d/36 legs पर यह वर्ग इसके बजाय टाइमआउट से विफल होता है) और entry_window_days को 20 तक बढ़ाने से सैंडबॉक्स विंडो में 3 प्रविष्टियाँ मिलती हैं (2025-08-28, 2026-06-02, 2026-07-14; iv_rank 0.06-0.10, rv अनुपात 1.27-1.36 — ये सभी वास्तव में सस्ते-IV/विस्तारित-RV टेल में हैं)। क्योंकि विस्तृत विंडो में स्ट्राइक तय होने के बाद स्ट्रैडल में प्रवेश संभव हो जाता है, इसलिए मैंने उसे ढीला करने के बजाय परिकल्पना को PROTECT करने वाले दो सुरक्षा नियम जोड़े: min_dte_days=10 (जीवन के 10 दिनों से कम शेष होने पर नया स्ट्रैडल कभी न खोलें) और atm_drift_max=0.15 (ऐसे चक्र को अस्वीकार करें जिसकी स्ट्राइक स्पॉट से इतनी दूर खिसक गई हो कि वह लगभग डेल्टा-न्यूट्रल न रहे); 3 प्रविष्टियाँ देने वाले रीप्ले में दोनों शामिल थे। तीसरा बदलाव: निरंतर लॉन्ग-वोल स्कोर को सक्रिय करने के लिए अब हर प्राथमिक बार पर calculate_signal(bar) चलाया जाता है (‘0 evaluated bars’ डायग्नोस्टिक) — प्राथमिक बार अब भी super().on_bar() से NOT गुजरते, जो बेस का बिना शर्त शेड्यूल लूप चलाकर, रेजीम गेट की परवाह किए बिना हर महीने स्ट्रैडल खरीदता। लेयर 1 का स्थैतिक विश्लेषण पास होता है (errors=0) और मॉड्यूल कंपाइल होता है। बाकी सब iteration-8 कोड से बाइट-दर-बाइट समान है: वही इम्पोर्ट, प्रति बार वही O(1) मेमोइज़्ड मेट्रिक्स, वही स्पष्ट rv_instrument_id चयन, वही संयुक्त प्रीमियम स्टॉप, कोई अंडरलाइंग/स्मोक फ़ॉलबैक नहीं। विश्लेषक के लिए ईमानदार सावधानी: सशर्त टेल प्रति वर्ष लगभग 3 योग्य मासिक चक्रों का समर्थन करता है, परिकल्पना के 12-20 का नहीं — यह छोटे नमूने का परिणाम होगा, और ट्रेड गढ़ने के लिए गेट ढीला करने के बजाय मैं यही रिपोर्ट करना पसंद करूँगा।

verification_loop: सत्यापन विफल (Layer 4 — QA समीक्षा) [class=hypothesis_mismatch]: - [edge_concern] Sandbox (smoke test, 4 trades) में win_rate 0.25 और total_return के साथ avg_trade_return_pct -6.49% दिखता है, जो लगभग पूरी तरह एक असामान्य रूप से बड़े लाभ (avg_win 4446 बनाम avg_loss 684; return_skew 6.58, kurtosis 48.5) से बना है। सकारात्मक-VRP regime में long-straddle का अपेक्षित स्वरूप यही है — अधिकांश cycles में premium घटता है और कभी-कभार होने वाला vol expansion उन सबकी लागत चुका देता है। Conditional-tail gate साल में केवल ~3 योग्य cycles देता है (developer ईमानदारी से बताता है कि hypothesis का '12-20 trades/year' अनुमान परिमाण के एक क्रम से बहुत अधिक है), इसलिए full-history का कोई भी परिणाम बहुत छोटा sample होगा और उसे कुछ भाग्यशाली/दुर्भाग्यपूर्ण expansions से अलग पहचानना कठिन होगा। केवल परामर्श — analyst को edge का आकलन full history पर करना चाहिए, इस smoke test पर नहीं। - [critical] Hypothesis और config के बीच timeframe का विरोधाभास (Layer 1.5 ने चिह्नित किया)। Hypothesis स्पष्ट रूप से 'BTCUSDT.BINANCE 1H bars' को realized-vol signal source और roll clock बताता है, लेकिन config.bar_type BTCUSDT.BINANCE-1-DAY-LAST-EXTERNAL (1-DAY) है। यह मामूली नहीं, महत्वपूर्ण अंतर है: 1-DAY bars पर code rv_short_hours=168 / rv_long_hours=720 को केवल 7 और 30 दैनिक returns में बदलता है (bar_hours=24.0), जो hypothesis में निर्दिष्ट 168/720-sample hourly estimator की तुलना में बहुत मोटा RV estimator है — developer के अपने iteration notes पुष्टि करते हैं कि gate को 'BTCUSDT 1-DAY closes' पर replay किया गया। इसलिए बताया गया मुख्य तंत्र (rv7/rv30 expansion) hypothesis में वर्णित data frequency से अलग frequency पर गणना किया जाता है, जिससे उस signal का noise स्वरूप बदलता है जो strategy के edge trigger को IS करता है। (line 1) — समाधान: विरोधाभास दूर करें: या तो config.bar_type को BTCUSDT.BINANCE-1-HOUR-LAST-EXTERNAL पर सेट करें (और bar_hours=1.0 सेट करें ताकि annualization factor और bar-count conversions उसी के अनुसार हों और rolling_options timeframe सुसंगत रहे), या OR hypothesis text में संशोधन करके 1-DAY RV bars लिखें, यदि daily sampling ही अपेक्षित design है। दोनों में सहमति होनी चाहिए। - [warning] min_bars_required(self) framework method को override करता है (static-analysis base_shadow warning)। पुष्टि करें कि base template warm-up gating के लिए इस override का पालन करता है, न कि अपने implementation पर निर्भर रहता है; यदि इसे अनदेखा किया जाता है, तो पहली entry evaluation से पहले RV long-window warm-up (rv_long_bars+5) लागू नहीं हो सकता। (line 215) — समाधान: जाँचें कि FactoryStrategy/RollingOptionsStrategy वास्तव में इस override को call करता है या नहीं; यदि नहीं, तो len(rv_source) > rv_long_bars पर entries को आंतरिक रूप से gate करें (code पहले से _realized_vol में यह बचाव करता है, इसलिए जोखिम कम है)।

सत्यापन विफल (Layer 4 — QA समीक्षा) [class=hypothesis_mismatch]: - [edge_concern] सैंडबॉक्स (स्मोक टेस्ट, 4 ट्रेड) में win_rate 0.25 और total_return के साथ avg_trade_return_pct -6.49% दिखता है, जो लगभग पूरी तरह एक असामान्य बड़े लाभ (avg_win 4446 बनाम avg_loss 684; return_skew 6.58, kurtosis 48.5) के कारण है। सकारात्मक-VRP व्यवस्था में लॉन्ग-स्ट्रैडल का यही अपेक्षित रूप है — ज़्यादातर चक्र प्रीमियम गंवाते हैं और वोलैटिलिटी का दुर्लभ विस्तार उन सबकी भरपाई कर देता है। सशर्त-टेल गेट से साल में केवल ~3 योग्य चक्र मिलते हैं (डेवलपर ईमानदारी से परिकल्पना के '12-20 ट्रेड/वर्ष' को वास्तविकता से परिमाण के एक क्रम से अधिक बताता है), इसलिए पूरे इतिहास का कोई भी परिणाम बहुत छोटा नमूना होगा और उसे कुछ भाग्यशाली/अभाग्यशाली विस्तारों से अलग पहचानना कठिन होगा। केवल सलाह — विश्लेषक को एज का आकलन पूरे इतिहास पर करना चाहिए, इस स्मोक टेस्ट पर नहीं। - [गंभीर] परिकल्पना और कॉन्फ़िगरेशन के बीच टाइमफ़्रेम का विरोधाभास (Layer 1.5 द्वारा चिह्नित)। परिकल्पना स्पष्ट रूप से 'BTCUSDT.BINANCE 1H bars' को realized-vol संकेत स्रोत और रोल घड़ी बताती है, लेकिन config.bar_type BTCUSDT.BINANCE-1-DAY-LAST-EXTERNAL (1-DAY) है। यह महत्वपूर्ण है, केवल दिखावटी नहीं: 1-DAY बारों पर कोड rv_short_hours=168 / rv_long_hours=720 को केवल 7 और 30 दैनिक रिटर्न में बदलता है (bar_hours=24.0); यह परिकल्पना में निर्दिष्ट 168/720-नमूना प्रति-घंटा आकलक की तुलना में कहीं अधिक मोटा RV आकलक है — डेवलपर के अपने iteration नोट्स पुष्टि करते हैं कि गेट को 'BTCUSDT 1-DAY क्लोज़' पर फिर से चलाया गया था। इसलिए बताई गई मूल युक्ति (rv7/rv30 विस्तार) परिकल्पना में वर्णित आवृत्ति से अलग डेटा आवृत्ति पर गणना की जाती है, जिससे उस संकेत के शोर का स्वरूप बदल जाता है जो रणनीति के एज ट्रिगर को IS करता है। (पंक्ति 1) — सुधार: विरोधाभास सुलझाएँ: या तो config.bar_type को BTCUSDT.BINANCE-1-HOUR-LAST-EXTERNAL पर सेट करें (और bar_hours=1.0 सेट करें ताकि वार्षिकीकरण गुणक और बार-गणना रूपांतरण उसी के अनुसार हों, और rolling_options टाइमफ़्रेम को एकसमान रखें), OR परिकल्पना का पाठ बदलकर 1-DAY RV बार बताएँ, यदि दैनिक सैंपलिंग ही अभिप्रेत डिज़ाइन है। दोनों का मेल होना चाहिए। - [चेतावनी] min_bars_required(self) फ़्रेमवर्क मेथड को ओवरराइड करता है (स्थैतिक-विश्लेषण base_shadow चेतावनी)। पुष्टि करें कि बेस टेम्पलेट वॉर्म-अप गेटिंग के लिए इस ओवरराइड को मानता है, न कि अपनी कार्यान्वयन-विधि पर निर्भर रहता है; यदि इसे नज़रअंदाज़ किया जाता है, तो पहली एंट्री जाँच से पहले RV लंबी वॉर्म-अप अवधि (rv_long_bars+5) लागू नहीं हो सकती। (पंक्ति 215) — सुधार: जाँचें कि FactoryStrategy/RollingOptionsStrategy वास्तव में इस ओवरराइड को कॉल करता है या नहीं; यदि नहीं, तो len(rv_source) > rv_long_bars पर आंतरिक रूप से एंट्रियों को रोकें (कोड _realized_vol में पहले से ही बचाव के तौर पर ऐसा करता है, इसलिए जोखिम कम है)।

सत्यापन विफल (Layer 4 — QA समीक्षा): - परिकल्पना की मूल एंट्री शर्त अब लागू नहीं है: iv_rank_max को 0.40 -> 0.55 तक बढ़ाया गया, जिससे ABOVE-MEDIAN निहित वोलैटिलिटी को 'सस्ता' माना जाता है। _iv_rank_at rank = np.mean(window <= cur) की गणना करता है, यानी पीछे की 180-दिन की DVOL विंडो में वर्तमान मान के बराबर या उससे कम मानों का अनुपात; इसलिए परिभाषा से ही रैंक [0,1] पर लगभग समान रूप से वितरित है। ivr <= 0.55 का गेट लगभग 55% दिनों को स्वीकार करता है — अब आधे से अधिक इतिहास 'सस्ती IV' के रूप में योग्य है। परिकल्पना स्पष्ट करती है कि यह गेट एज IS करता है: 'क्रिप्टो का वोलैटिलिटी रिस्क प्रीमियम ON AVERAGE सकारात्मक है ... इसलिए बिना शर्त लॉन्ग-स्ट्रैडल का थीटा क्षय निश्चित है। एज का उपयोग केवल सशर्त टेल में किया जाता है: ONLY तब प्रवेश करें जब निहित वोलैटिलिटी अपने इतिहास के सापेक्ष CHEAP हो'। 55वें परसेंटाइल पर वोलैटिलिटी खरीदना सशर्त टेल नहीं है; यह लगभग बेतरतीब ढंग से वोलैटिलिटी खरीदने जैसा है, जिसे परिकल्पना निश्चित घाटे वाला बताती है। यह शर्त के अर्थ को बदल देता है, केवल उसकी मात्रा को नहीं। - ALL THREE बाज़ार-स्थिति गेट और एंट्री विंडो को एक साथ ढीला किया गया, और उसका तर्क इसके विपरीत कहता है। iteration 5 से तुलना करें: iv_rank_max 0.40 -> 0.55 (+37.5%), iv_over_rv_max 1.30 -> 1.60 (+23.1%), rv_expansion_min 1.05 -> 1.02 (5% के बजाय 2% विस्तार आवश्यक करता है), entry_window_days 5 -> 7 (+40%)। तर्क दो बार दावा करता है कि ऐसा नहीं हुआ: 'संकेत निर्माण, गेट, साइज़िंग या एग्ज़िट लॉजिक में कुछ नहीं बदलता — यह पूरी तरह डेटा-मात्रा का सुधार है' और 'संकेत निर्माण, बाज़ार-स्थिति गेट, साइज़िंग और एग्ज़िट लॉजिक अपरिवर्तित हैं।' इसे पढ़ने वाला विश्लेषक मानेगा कि गेट जस का तस है और नतीजे में आए ट्रेडों का श्रेय परिकल्पित एज को देगा। इसके अलावा, rv_expansion_min=1.02 अब निश्चित रूप से अप्रभावी है: मैंने पिछली समीक्षा में मापा था कि दैनिक सैंपलिंग पर 5-बार/20-बार RV अनुपात में ~38.9% सैंपलिंग शोर है, इसलिए 2% की सीमा शोर-पट्टी के भीतर गहराई तक आती है। - यह ढील बताए गए उद्देश्य के लिए कुछ नहीं करती और ऐसे बदलाव के साथ आती है, जो अन्यथा कोई ट्रेड नहीं देता — सत्यापन पास बनाने के लिए एज को ढीला करने का पैटर्न। यह iteration 300s टाइमआउट ठीक करने के लिए है; सीमा-मानों का बार-लोडिंग या डिस्पैच लागत पर कोई असर नहीं होता, इसलिए ढीले किए गए चारों पैरामीटरों में से कोई भी उस लक्ष्य की पूर्ति नहीं करता। वे जिस चीज़ के साथ परस्पर प्रभाव डालते हैं, वह है साथ में किया गया lookback_days कट 365 -> 150 (-58.9%), जिससे शेड्यूल लगभग 12 मासिक चक्रों से घटकर ~5 हो जाता है। लगभग 5 विंडो पर iteration-5 के गेट के साथ, शून्य-ट्रेड वाला Layer-3 विफलता संभावित परिणाम था; ढीले गेट उससे बचाते हैं। सैंडबॉक्स लगभग बिना शर्त एंट्री के अनुरूप है: data_days=2 पर लगभग 5 उपलब्ध चक्रों से 4 लेग-ट्रेड (2 स्ट्रैडल)। छह iterations में विंडो घटते हुए गेट लगातार अधिक अनुमेय बने हैं। - गेट को अलग रखकर भी, lookback_days=150 अनुकूलन का समर्थन नहीं कर सकता। इससे लगभग 5 मासिक एक्सपायरी हल होती हैं, और एक समय में एक स्ट्रैडल के साथ अधिकतम लगभग 5 ट्रेड हो सकते हैं। तीन वॉक-फ़ॉरवर्ड विंडो लगभग 50 दिन की होंगी (हर विंडो में दो से कम मासिक चक्र) और 15-दिन का होल्डआउट अवधि का 10% हिस्सा लेता है। इस आधार पर कोई IS/OOS अनुपात, PBO, या होल्डआउट Sharpe कोई जानकारी नहीं देता। - dvol_max_lag_hours = 1080 (45 दिन) तीन समीक्षाओं में अनसुलझा है। _iv_at अंतिम DVOL प्रिंट को उस सीमा तक फ़ॉरवर्ड-फ़िल करता है, जबकि ट्रेडिंग 30-DTE चक्र की है; इसलिए एंट्री का निर्णय IV पर हो सकता है, जो ऑप्शन के जीवनकाल से भी पुराना हो — इससे अभी की सस्ताई पर गेट लगाने का उद्देश्य विफल होता है और विस्तृत iv_rank_max के साथ खराब ढंग से परस्पर प्रभाव पड़ता है। BTC DVOL, आज के 2026-07-18 के मुकाबले 2026-06-11 पर समाप्त होता है। सहायक पुट-राइट्स में 10-दिन की सीमा है। - चार समीक्षाओं से चली आ रही समस्या: _straddle_pnl_pct बिना खुली पोज़िशन वाले किसी भी लेग को छोड़कर (continue) आगे बढ़ता है, None लौटाने के बजाय; इसलिए बंद/एक्सपायर हुआ लेग संयुक्त P&L को केवल बचे हुए लेग के आधार पर गणना करने देता है, जबकि docstring और परिकल्पना COMBINED दो-लेग प्रीमियम के प्रतिशत के रूप में -40% स्टॉप और +60% लक्ष्य परिभाषित करते हैं। अलग से, _equity_usd अब भी बैलेंस MAGNITUDE के आधार पर मुद्रा इकाई का अनुमान लगाता है ('if eq < 1_000.0: eq = eq * spot')।

verification_loop: सत्यापन विफल (Layer 4 — QA समीक्षा) [class=hypothesis_mismatch]: - [edge_concern] Sandbox (smoke test, 4 trades) में win_rate 0.25 और total_return के साथ avg_trade_return_pct -6.49% दिखता है, जो लगभग पूरी तरह एक असामान्य रूप से बड़े लाभ (avg_win 4446 बनाम avg_loss 684; return_skew 6.58, kurtosis 48.5) से बना है। सकारात्मक-VRP regime में long-straddle का अपेक्षित स्वरूप यही है — अधिकांश cycles में premium घटता है और कभी-कभार होने वाला vol expansion उन सबकी लागत चुका देता है। Conditional-tail gate साल में केवल ~3 योग्य cycles देता है (developer ईमानदारी से बताता है कि hypothesis का '12-20 trades/year' अनुमान परिमाण के एक क्रम से बहुत अधिक है), इसलिए full-history का कोई भी परिणाम बहुत छोटा sample होगा और उसे कुछ भाग्यशाली/दुर्भाग्यपूर्ण expansions से अलग पहचानना कठिन होगा। केवल परामर्श — analyst को edge का आकलन full history पर करना चाहिए, इस smoke test पर नहीं। - [critical] Hypothesis और config के बीच timeframe का विरोधाभास (Layer 1.5 ने चिह्नित किया)। Hypothesis स्पष्ट रूप से 'BTCUSDT.BINANCE 1H bars' को realized-vol signal source और roll clock बताता है, लेकिन config.bar_type BTCUSDT.BINANCE-1-DAY-LAST-EXTERNAL (1-DAY) है। यह मामूली नहीं, महत्वपूर्ण अंतर है: 1-DAY bars पर code rv_short_hours=168 / rv_long_hours=720 को केवल 7 और 30 दैनिक returns में बदलता है (bar_hours=24.0), जो hypothesis में निर्दिष्ट 168/720-sample hourly estimator की तुलना में बहुत मोटा RV estimator है — developer के अपने iteration notes पुष्टि करते हैं कि gate को 'BTCUSDT 1-DAY closes' पर replay किया गया। इसलिए बताया गया मुख्य तंत्र (rv7/rv30 expansion) hypothesis में वर्णित data frequency से अलग frequency पर गणना किया जाता है, जिससे उस signal का noise स्वरूप बदलता है जो strategy के edge trigger को IS करता है। (line 1) — समाधान: विरोधाभास दूर करें: या तो config.bar_type को BTCUSDT.BINANCE-1-HOUR-LAST-EXTERNAL पर सेट करें (और bar_hours=1.0 सेट करें ताकि annualization factor और bar-count conversions उसी के अनुसार हों और rolling_options timeframe सुसंगत रहे), या OR hypothesis text में संशोधन करके 1-DAY RV bars लिखें, यदि daily sampling ही अपेक्षित design है। दोनों में सहमति होनी चाहिए। - [warning] min_bars_required(self) framework method को override करता है (static-analysis base_shadow warning)। पुष्टि करें कि base template warm-up gating के लिए इस override का पालन करता है, न कि अपने implementation पर निर्भर रहता है; यदि इसे अनदेखा किया जाता है, तो पहली entry evaluation से पहले RV long-window warm-up (rv_long_bars+5) लागू नहीं हो सकता। (line 215) — समाधान: जाँचें कि FactoryStrategy/RollingOptionsStrategy वास्तव में इस override को call करता है या नहीं; यदि नहीं, तो len(rv_source) > rv_long_bars पर entries को आंतरिक रूप से gate करें (code पहले से _realized_vol में यह बचाव करता है, इसलिए जोखिम कम है)।