Устранение мёртвого кода и реанимация бэктест-движка

[xsa-dev]

Устранение мёртвого кода и реанимация бэктест-движка

Контекст (что сейчас в репо)

При аудите src/lib.rs выяснилось, что публичный API библиотеки — это скелет из 4 модулей:

• backtest → только FundingPayment (16 строк)
• unified_data → Position, OrderRequest, OrderResult, энумы
• risk_manager → RiskManager с проверкой размера позиции + генерацией SL/TP (без daily-loss / leverage / drawdown / trailing — хотя README их обещает)
• optimization → рабочий генетический алгоритм (GeneticOptimizer, Genome, FitnessEvaluator)

При этом в src/ лежит ~20 осиротевших файлов, не объявленных ни в одном mod (и потому не попадающих в сборку библиотеки):
data.rs, indicators.rs, strategies.rs, unified_data_impl.rs, mode_reporting.rs,
funding_report.rs, csv_export.rs, errors.rs, trading_mode.rs, migration.rs,
real_time_data_stream.rs, real_time_monitoring.rs, live_trading.rs (54 КБ), live_trading_safety.rs,
paper_trading.rs (43 КБ), api_docs.rs, utils.rs, risk_manager_new.rs (пустой), data_tests.rs,
плюс вся папка src/tests/* (десятки файлов) — cargo test прогонит только mod basic.

README / CHANGELOG / PUBLISHING описывают продукт в ~20× больше реального API
(HyperliquidData, HyperliquidBacktest, live/paper trading, monitoring-сервер, «>90% coverage»).
Коммит fix-main-branch-build-issue просто урезал lib.rs до скелета, чтобы cargo build проходил.
Версии рассинхронизированы: Cargo.toml=0.1.2, README=0.1.1, CHANGELOG/PUBLISHING=0.1.0.
В Cargo.toml висит мёртвая тяжёлая зависимость ethers = "2.0" (и rs-backtester, hyperliquid_rust_sdk,
serde, tokio), которые живым кодом не используются (только chrono, thiserror, rand).

Часть 1 — Устранение мёртвого кода (Уровень 0)

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

• Удалить осиротевшие файлы из src/ (перечислены выше), либо подключить их в дерево модулей, если они нужны движку (см. Часть 2).
• Почистить Cargo.toml от неиспользуемых зависимостей (ethers, rs-backtester, hyperliquid_rust_sdk, serde, тяжёлый tokio). Оставить только то, что реально используется.
• Привести README / CHANGELOG / PUBLISHING / docs к реальному API. Убрать обещания функций, которых нет. Либо реализовать их (Часть 2), либо документировать как roadmap.
• Синхронизировать версии (Cargo.toml / README / CHANGELOG) — выбрать одну (0.1.2).
• Включить рабочие тесты в сборку; удалить мёртвые src/tests/* или подключить.
• Подтвердить: cargo build и cargo test проходят чисто на минимальном наборе deps.

Часть 2 — Реанимация работы над движком (Уровень 1)

Цель: превратить скелет в честный минимальный бэктестер с GA-тунингом (то, что описано в README, но реально работающее).

• Реальный бэктест-движок на исторических свечах с учётом funding (accrual по времени, а не разово).
• Подключить существующий indicators.rs (SMA/EMA/RVol) и data.rs (загрузка свечей) — код уже написан, просто не в дереве модулей.
• Реалистичные метрики: win-rate, max drawdown, profit factor, Sharpe — в духе эмпирического подхода.
• Завязать GeneticOptimizer на реальный бэктест-fitness вместо синтетического (сейчас ga_optimize гоняет synthetic evaluator — переобучение на фиктивную функцию).
• Комиссии maker/taker, slippage, funding по часам — на втором этапе.
• Сборка движка должна обходиться без тяжёлых SDK-зависимостей (загрузка свечей через лёгкий HTTP к Hyperliquid API, либо из CSV/фикстур в тестах).

Приоритет

1. Часть 1 (чистка) — обязательно, малый объём, снимает «vaporware»-статус.
2. Часть 2 (движок) — основная ценность; начать с подключения indicators.rs/data.rs + честный BacktestEngine.

Замечание по ресурсам

Локальная срема ограничена (RAM ~1.1 GB available, диск ~7.7 GB free после чистки).
Полная сборка с ethers/rs-backtester/hyperliquid_rust_sdk рискует OOM — отсюда требование
собирать движок на лёгком наборе зависимостей.