M9d MOO→9:55 — Triple Audit

Функция new_grade() в build_m9d.py определяет грейды так:

def new_grade(s):
    if 5.5 <= s <= 11.5: return 'A+'     # medium scores = BEST
    elif 3.0 <= s < 5.5 or s >= 24: return 'A'  # low OR very high = second best
    elif 11.5 <= s < 24: return 'B'       # high scores = WORSE than A+!
    elif 1.0 <= s < 3.0: return 'B+'      # low = third best
    else: return 'SKIP'

Проблема: Скор 6.0 -> A+ (best), скор 15.0 -> B (worse), скор 25.0 -> A (second). Это U-образная зависимость. В здоровой модели БОЛЬШЕ скор = ЛУЧШЕ грейд. Немонотонная зависимость = классический признак переобучения на шум.

Что это значит: Модель "нашла", что средние скоры лучше высоких. Но это скорее артефакт данных — высокие скоры часто приходятся на extreme дни (earnings, news), где конкуренция за ликвидность и crowded trades убивают edge. Вместо понимания ПРИЧИНЫ, модель просто режет интервал.

Тест: Возьмите только score >= 0 и монотонный грейдинг. Если Sharpe падает значительно — overfit confirmed.

keep &= u.month != 4 — полное исключение апреля.

Проблема: Если апрель был худшим месяцем в training set, его исключение = подгонка под прошлое. Это классический "worst period exclusion". Можно так же исключить любой плохой квартал и получить лучший Sharpe.

Реальный вопрос: Есть ли structural reason почему апрель плох? (Tax-loss selling deadline? Earnings season start?). Если да — документируйте ПРИЧИНУ. Если нет — это data snooping.

Impact: ~21 торговых дней в году × 37 trades/day = ~777 trades. Исключая худший месяц, вы убираете ~3% самых плохих данных и Sharpe прыгает вверх.

Sharpe Ratio 8.84 означает, что стратегия зарабатывает 8.84 стандартных отклонений в год. Для сравнения:

Причины инфляции:

1. Множитель *16 = sqrt(256), но реально ~252 дня → инфляция ~0.8%
2. Множество мелких позиций ($500-$1500) = низкая std → высокий Sharpe
3. 37 trades/day = диверсификация сглаживает дневной P&L → std↓ → Sharpe↑
4. Compound 3x cap создает иллюзию стабильности в equity curve
5. Без slippage/spread каждый trade ≈ +$5-10 чистый profit

Реалистичная оценка: После корректировки на slippage (+5bps entry + 5bps exit = 10bps round-trip), market impact (еще 5bps на crowded names), и honest entry price → Sharpe ≈ 2-4. Это все еще отличная стратегия, но не "8.84".

В 01_data_builder.py:327:

bars_930.columns = ["open_930", "high_930", "low_930", "entry_930", "vol_930"]
#                                                       ^^^^^^^^^^
# entry_930 = CLOSE of 9:30 bar (т.е. цена в 9:30:59)
# open_930  = OPEN of 9:30 bar (т.е. цена в 9:30:00 = реальный MOO)

Есть fix_master_preopen.py который пытается исправить: m["entry_930"] = m["entry_open"]. Но:

1. В build_m9d.py используется entry_930 напрямую из parquet
2. Неясно, был ли fix_master_preopen.py запущен ДО создания universe_scored_v4.parquet
3. Если fix НЕ был запущен → каждый trade имеет 1-минутный lookahead

Magnitude: В первую минуту после MOO средний move = 5-15bps. На 30K trades это $2K-$7K бесплатного P&L в бэктесте. Может объяснять 10-20% общего P&L.

Как проверить:

import pandas as pd
u = pd.read_parquet('moo955_v2/universe_scored_v4.parquet')
# Если entry_930 == close of 930 bar:
diff = (u['entry_930'] - u['open_930']).abs() / u['open_930'] * 100
print(f"Median |entry-open|: {diff.median():.4f}%")
print(f"Mean |entry-open|:   {diff.mean():.4f}%")
# Если median > 0.02% → fix NOT applied, entry = close

Cost model в build_m9d.py:

BROKER_PS = 0.004    # broker per share
ECN_PS = 0.003       # ECN per share
FINRA_PS = 0.000166  # FINRA TAF
SEC_RATE = 0.0000278 # SEC fee

t['cost'] = t.shares * (BROKER_PS+ECN_PS+FINRA_PS)*2 + t['size']*SEC_RATE

Сравнение с config.py (используется в реалистичных бэктестах):

Missing cost per trade:

$1000 position × 15bps slippage+spread = $1.50 per trade. На 30K trades = $45,000 недоучтенных costs. Это 26% от заявленного PnL ($172K).

Для SHORT trades добавьте locate fee: ~$0.02/share × ~100 shares = $2/trade × 10K short trades = $20,000.

Итого недоучтено: ~$65K = 38% от PnL.

Самая опасная находка.

В коде есть ДВЕ версии entry price:

# Version 1 (01_data_builder.py:54):
entry = bar_930.iloc[0]["close"]  # = price at 9:30:59

# Version 2 (01_data_builder.py:327, vectorized path):
bars_930.columns = [..., "entry_930", ...]  # maps to "close" column

Обе версии используют CLOSE of 9:30 bar. fix_master_preopen.py существует для исправления, но:

1. Это ОТДЕЛЬНЫЙ скрипт, не часть pipeline
2. Его output: moo955_master_v2.parquet — но pipeline config указывает на moo955_master.parquet
3. Комментарий в scoring_v4_oos.py: "Fixed entry = open_930 — already done in master_v2" — значит fix СДЕЛАН, но нужно ВЕРИФИЦИРОВАТЬ в данных

Даже если fix applied для ret_955 расчета, в build_m9d.py есть второй lookahead:

u['gap_pm'] = (u.pm_close - u.prev_close) / u.prev_close * 100

Но direction в universe_scored_v4 был назначен по gap_pct из data builder:

# 01_data_builder.py:432-434
gap_pct = (entry_930 - prev_close) / prev_close * 100

# 01_data_builder.py:440
direction = "LONG" if gap_pct > 0 else "SHORT"

Если entry_930 = close_930, то direction определяется по цене 9:30:59, а не по pre-open gap! Stock может gap UP в PM, но close of 9:30 bar ниже prev_close → direction = SHORT. Это forward-looking direction assignment.