Roadmap¶

Это рабочая дорожная карта Whaler v42. Она фиксирует не обещания доходности, а инженерный путь от текущего исследовательского кандидата к безопасному боевому контуру.

Статус сейчас¶

На текущий момент есть:

• Decima-8 v42 как редкий s300-сенсор;
• s1800 phase как подтвержденный HTF-контекст;
• phase director с same-side close-if-profit;
• live runner и replay runner с общим путем данных;
• HTML/JSON/TSV мониторинг;
• dry-run inventory;
• публичная документация и отчеты;
• первые transfer-проверки на ETHUSDT.

Текущий главный результат BTCUSDT all-history:

period=2026-01-01..2026-05-30
signals=150
same_side=close-if-profit
trades=64
return=+34.14%
win=67.19%
profit_factor=2.324
max_drawdown=10.88%
fee=4 bps
entry_exposure=0.5

keep дал больше на бумаге:

return=+38.56%
trades=37
profit_factor=3.262

Но текущим практическим кандидатом остается close-if-profit, потому что он психологически и операционно понятнее.

Этап 1: наблюдение live¶

Цель: доказать, что live не расходится с offline replay.

Критерии:

• live работает без ручного вмешательства;
• s300 и s1800 buckets закрываются ожидаемо;
• Decima signals совпадают с replay на тех же данных;
• phase decisions совпадают с replay;
• inventory не теряет состояние;
• reconnects и feed health видны в HTML;
• нет неожиданных flips, duplicate orders или silent failure.

Минимальная длительность:

2-4 недели непрерывного paper/live наблюдения

Этап 2: parity audit¶

Цель: сделать сверку live vs offline replay обязательной процедурой.

Нужно:

• сохранить live raw/frames/signals/director;
• прогнать replay по тем же временным границам;
• сравнить сигналы, phase, decisions и inventory;
• вывести diff-отчет;
• отдельно отмечать расхождения из-за незакрытых buckets, reconnects и latency.

Ожидаемый артефакт:

live_replay_parity.html
live_replay_parity.json

Этап 3: risk layer¶

Цель: не дать хорошей стратегии умереть от плохого режима или технической ошибки.

Обязательные ограничения:

• max_daily_loss;
• max_weekly_loss;
• max_trades_per_day;
• max_consecutive_losses;
• cooldown после убыточной сделки;
• cooldown после profit take;
• запрет входа при мутной фазе;
• kill switch;
• ручной режим no_trade.

Следующий смысловой модуль:

margin_of_safety

Он должен требовать запас прочности по сигналу, фазе, цене, комиссии, шуму и состоянию позиции.

Этап 4: боевой order executor¶

Цель: отделить торговое решение от исполнения.

Контур:

director decision
  -> inventory intent
  -> risk gate
  -> order executor
  -> exchange order
  -> exchange position
  -> reconciliation

Executor не должен принимать стратегических решений. Он должен:

• исполнять только разрешенные intents;
• проверять reduce-only;
• проверять min notional и qty step;
• учитывать fee/slippage;
• сверять локальную позицию с биржей;
• не торговать при рассинхроне;
• писать audit log.

Этап 5: VPS production¶

Цель: стабильная инфраструктура.

Нужно:

• systemd unit или аналогичный supervisor;
• отдельные директории для logs/runs/state;
• ротация логов;
• мониторинг диска;
• мониторинг websocket reconnects;
• health page;
• alert channel;
• backup ключевых артефактов;
• отдельный read-only режим для публичных отчетов.

Этап 6: малый капитал¶

Цель: проверить исполнение, а не заработать максимум.

Правила:

• минимальный капитал;
• маленькая экспозиция;
• без плеча или с жестко ограниченным плечом;
• лимит дневной потери;
• ручной kill switch;
• ежедневная сверка orders/fills/position;
• отдельный отчет real_vs_paper.

На этом этапе главный вопрос:

совпадает ли реальный торговый контур с моделью?

Этап 7: расширение рынков¶

Цель: понять, является ли v42 BTC-специфичной или переносимой.

Приоритет:

BTCUSDT -> ETHUSDT -> крупные ликвидные пары

Для каждой пары нужны:

• level-v3 invariant 86400 frames/day;
• полный walk-forward;
• live-equivalent replay;
• проверка s1800 phase;
• отдельный same-side sweep;
• отдельный risk profile.

ETHUSDT уже дал положительный transfer, но слабее BTCUSDT:

return=+13.68%
trades=68
win=64.71%
max_drawdown=19.22%

Это аргумент за продолжение проверки, а не за немедленное масштабирование.

Этап 8: внешние партнеры¶

Кому может быть интересен проект:

• техническим партнерам по инфраструктуре;
• quant/research командам;
• инвесторам, которым понятен высокий риск early-stage;
• трейдерам, которым важна редкая событийная модель вместо HFT;
• биржевым/данным партнерам.

Что можно показывать:

• архитектуру;
• текущие отчеты;
• live мониторинг;
• replay parity;
• risk roadmap;
• историю решений директора.

Что нельзя обещать:

• гарантированную доходность;
• стабильность на всех рынках;
• готовность фонда;
• отсутствие просадок;
• мгновенную масштабируемость капитала.

Ближайшие задачи¶

Короткий список:

1. Продолжать live-наблюдение без ручного вмешательства.
2. Сверить live vs replay.
3. Доделать risk gates.
4. Доделать order executor в paper-first режиме.
5. Подключить production-сбор лидов.
6. Подготовить VPS production unit.
7. Сделать daily status page.
8. Продолжить ETHUSDT и другие крупные пары.

Главный принцип остается тем же:

не увеличивать риск быстрее, чем растет проверенность контура