ETH Deribit週度Put-Credit-Spread——波動率風險溢酬 + 下檔偏斜收割（定義風險選擇權，偏斜門檻，3參數）

Layer-3的「未產生任何交易 / 0個已評估的K棒」有兩個具體原因，且都不是進場門檻的問題（該回饋正確地指出不應放寬門檻）。首先，「0個已評估的K棒」這行對這個系列策略而言是個誤導線索：RollingOptionsStrategy.on_bar完全覆寫了FactoryStrategy.on_bar，且從未到達_process_primary，因此bars_seen對每一個rolling-options策略（包括正常交易的策略）都是0——我是透過閱讀rolling_options_template.py和base_template.py來確認這一點，而不是加上一個super().on_bar()呼叫；若那樣做，會把主要K棒導入基底類別的跨腿對齊屏障，屆時間歇性的選擇權腿位（與主要標的相同的1-DAY時間框架）將會永遠阻擋處理流程。其次，真正的阻塞點有：(a) ANNUALIZATION MISMATCH——繼承而來的已實現波動率設定是以小時為單位（rv_window=168、bars_per_year=8760），但此次執行是以1-DAY的K棒進行，因此日對數報酬被以sqrt(8760)而非sqrt(365)年化，使RV膨脹了4.90x（正常3%/天的ETH行情原本讀值為281%，卻被讀成57%）；隨後VRP門檻iv >= rv*(1+margin)便是拿約60% IV與約281% RV比較，結果每個週期都是False。已透過從所設定的K棒類型推導bars_per_year、並以日曆天數表示RV視窗來修正，因此這個誤差不會在任何時間間隔上再次發生（已驗證：1-DAY -> 365、1-HOUR -> 8760、4-HOUR -> 2190，且該門檻現在在正常行情下可以通過）。(b) ROLE MAPPING——繼承的鷹架程式碼以選擇權類型作為腿位鍵值，並要求一個call加一個put（即strangle），因此put價差的兩個P腿位在同一個鍵值上發生衝突，第二個被判定為重複而遭拒絕，就緒檢查要求一個不存在的call腿位，導致每一個腿位都被以SELL的方式送出（兩個裸賣的空頭put，而非定義風險的垂直價差）。腿位現在改以履約價映射為short/long，以相同的快取合約數量原子性地賣出short、買入long。我也移除了繼承而來的權利金倍數停損：long翼部本身已經限制了虧損上限，因此在一個已封頂的結構上加設停損，只會提早實現一個有限的虧損並增加手續費。規模計算已端到端驗證（150寬的價差、$22權利金收入、$128最大虧損 -> 15口合約 = 承擔1.9%的權益風險）。我保留了所有通過Layer 1-2的內容不變：乾淨的匯入、修正Layer-2中staticmethod重綁定TypeError的模組層級_bar_ts自由函式、DVOL解析器、Black-Scholes IV反推，以及連續的calculate_signal。lookback_days為49（7個週期、14個選擇權腿位），因為每個K棒類型的目錄載入器每條腿位成本約10秒，而更長的鏈條會使Layer-3的實際執行時間面臨風險；這限制了初始樣本數，屬於載入器本身的特性，而非假說本身的特性。

verification_loop：驗證失敗（Layer 4 — QA審查）[class=code_defect]： - [edge_concern] 沙盒avg_trade_return_pct在2筆交易上為-45.45%，metrics_reliable=false且data_days=1——這不是一個績效判定（對選擇權腿位而言，單位名目報酬並無意義，因為權利金名目金額遠小於翼部名目金額，且沙盒僅是一個1天的煙霧測試）。此點僅作為背景脈絡帶入後續：若下方的載入器/回溯期問題獲得解決、且累積出真正的週選擇權樣本，分析師應重新檢查所收取的淨權利金收入是否足以覆蓋Deribit在4條腿位（開倉+平倉 x short+long）上的0.03%/單邊來回成本，再加上任何指派（assignment）滑價，因為put-credit-spread的單位名目優勢在結構上本就相當薄弱。 - [critical] rolling_options.lookback_days=49將ANY回測中ENTIRE可解析的選擇權鏈限制在截至「現在」的~49天內 = 約7個週週期 / 約14個選擇權腿位，而不論Deribit有6.5年的ETH選擇權歷史資料。該策略在此視窗其餘的時間都持平倉，只在尾端才進行交易。沙盒也以實證方式證實了這一點：bars_processed=2400（約6.5年），但data_days=1且total_trades=2（trades_count=4）。在約7個週期 / 約14條腿位的規模下，波動率風險溢酬加上偏斜（skew）優勢根本無法與雜訊區分——遠低於能形成可測量選擇權樣本所需的約30-100筆交易。這正是導致幾乎完全相同的BtcDeribitWeeklyDeltaHedgedAtmStraddleVrp（相同交易所、相同lookback_days=49）在4天前於Layer被放棄的那個載入器成本與樣本規模衝突-22。開發者自己的理由說明也承認了這個上限（「lookback_days為49（7個週期、14個選擇權腿位），因為每個K棒類型的目錄載入器每條腿位成本約10秒，而更長的鏈條會使Layer-3的實際執行時間面臨風險」）。以目前的設定，該策略永遠無法產出一個可測量的完整回測。——修正方式：不應在約7個週期的情況下通過。在重新提交前，先解決載入器成本與樣本規模的衝突-22：批次處理／平行化或跨K棒快取每條腿位的catalog.bars()載入，使lookback_days能夠涵蓋多年的週週期（約200-300個週期）而不超出沙盒的實際執行時間限制，接著將lookback_days設定為涵蓋完整的測試視窗。若載入器在時間預算內確實無法解析出可測量的週選擇權歷史資料，則此系列策略在目前的測試框架下，以週為節奏是無法測試的，應該重新設計（例如改用較少、到期日較長的月週期涵蓋整個時間範圍），而非

驗證失敗（第 4 層 — QA 審查）[類別=code_defect]： - [edge_concern] 沙盒 avg_trade_return_pct 在 2 筆交易上為 -45.45%，其中 metrics_reliable=false 且 data_days=1 — 這並非績效結論（對選擇權腿而言，逐名目報酬並無意義，因為權利金名目遠小於翼部名目，且此沙盒僅為 1 天的冒煙測試）。此資訊僅作為背景保留：若下方的載入器／回溯期問題獲得解決，且累積了真實的每週選擇權樣本，分析師應重新檢查所收取的淨權利金，是否足以涵蓋 Deribit 在 4 條腿（開倉+平倉 x 賣出+買進）上、每邊 0.03% 的來回成本，加上任何履約滑價，因為賣出信用價差的逐名目優勢在結構上本就微薄。 - [critical] rolling_options.lookback_days=49 將 ANY 回測中 ENTIRE 可解析的選擇權鏈限制在截至「現在」的約 49 天內 = 約 7 個每週週期 / 約 14 條選擇權腿，無論 Deribit 擁有 6.5 年的 ETH 選擇權歷史。該策略在其餘視窗期間保持空倉，只在尾端交易。沙盒的實證結果證實了這一點：bars_processed=2400（約 6.5 年），但 data_days=1 且 total_trades=2（trades_count=4）。在僅約 7 個週期 / 約 14 條腿的情況下，波動風險溢酬 + 偏度優勢無法與雜訊區分——遠低於構成可衡量選擇權樣本所需的約 30-100 筆交易。這正是導致幾乎相同的 BtcDeribitWeeklyDeltaHedgedAtmStraddleVrp（相同交易所、相同 lookback_days=49）在 4 天前於 Layer 層被放棄的載入器成本與樣本量之間的確切困境-22。開發者自己的理由承認了此上限（「lookback_days 為 49（7 個週期，14 條選擇權腿），因為每種 bar 類型的目錄載入器每條腿成本約 10 秒，而更大的鏈會使 Layer-3 的實際執行時間面臨風險」）。按照目前的設定，該策略永遠無法產生可衡量的完整回測。— 修正方式：不要在約 7 個週期上通過。在重新提交前，請解決載入器成本與樣本量之間的困境-22：批次處理／平行化或跨 bar 快取每條腿的 catalog.bars() 載入，使 lookback_days 能在不超出沙盒實際執行時間的情況下涵蓋多年的每週週期（約 200-300 個週期），然後將 lookback_days 設定為涵蓋完整測試視窗。若載入器確實無法在時間預算內解析出可衡量的每週選擇權歷史，則此類策略在目前的測試框架中無法以每週頻率進行測試，應重新設計（例如在整個範圍內採用較少、期限較長的月度週期），而非

verification_loop：驗證失敗（Layer 4 — QA審查）[class=code_defect]： - [edge_concern] 沙盒avg_trade_return_pct在2筆交易上為-45.45%，metrics_reliable=false且data_days=1——這不是一個績效判定（對選擇權腿位而言，單位名目報酬並無意義，因為權利金名目金額遠小於翼部名目金額，且沙盒僅是一個1天的煙霧測試）。此點僅作為背景脈絡帶入後續：若下方的載入器/回溯期問題獲得解決、且累積出真正的週選擇權樣本，分析師應重新檢查所收取的淨權利金收入是否足以覆蓋Deribit在4條腿位（開倉+平倉 x short+long）上的0.03%/單邊來回成本，再加上任何指派（assignment）滑價，因為put-credit-spread的單位名目優勢在結構上本就相當薄弱。 - [critical] rolling_options.lookback_days=49將ANY回測中ENTIRE可解析的選擇權鏈限制在截至「現在」的~49天內 = 約7個週週期 / 約14個選擇權腿位，而不論Deribit有6.5年的ETH選擇權歷史資料。該策略在此視窗其餘的時間都持平倉，只在尾端才進行交易。沙盒也以實證方式證實了這一點：bars_processed=2400（約6.5年），但data_days=1且total_trades=2（trades_count=4）。在約7個週期 / 約14條腿位的規模下，波動率風險溢酬加上偏斜（skew）優勢根本無法與雜訊區分——遠低於能形成可測量選擇權樣本所需的約30-100筆交易。這正是導致幾乎完全相同的BtcDeribitWeeklyDeltaHedgedAtmStraddleVrp（相同交易所、相同lookback_days=49）在4天前於Layer被放棄的那個載入器成本與樣本規模衝突-22。開發者自己的理由說明也承認了這個上限（「lookback_days為49（7個週期、14個選擇權腿位），因為每個K棒類型的目錄載入器每條腿位成本約10秒，而更長的鏈條會使Layer-3的實際執行時間面臨風險」）。以目前的設定，該策略永遠無法產出一個可測量的完整回測。——修正方式：不應在約7個週期的情況下通過。在重新提交前，先解決載入器成本與樣本規模的衝突-22：批次處理／平行化或跨K棒快取每條腿位的catalog.bars()載入，使lookback_days能夠涵蓋多年的週週期（約200-300個週期）而不超出沙盒的實際執行時間限制，接著將lookback_days設定為涵蓋完整的測試視窗。若載入器在時間預算內確實無法解析出可測量的週選擇權歷史資料，則此系列策略在目前的測試框架下，以週為節奏是無法測試的，應該重新設計（例如改用較少、到期日較長的月週期涵蓋整個時間範圍），而非