v0.4.3

[0.4.3] - 2026-09-24

Влияние: торговая логика · UI · данные. Меняется одно торговое правило, стоп по марже
бота 2. Схема продавца закрывает сделку, когда поддерживающая маржа проданных опционов достигает 60%
капитала счёта, а в 0.4.2 правило считало эту долю неверно и ошибалось в обе стороны: у первой сделки
живого прогона почти всё время показывало ниже настоящей, на срезе 23.09 выше (24.94% при настоящих
24.01%). Теперь оно видит ту же долю, что и счёт, поэтому на том же ходе рынка 0.4.3 может закрыть
сделку в другой момент, чем 0.4.2. Ещё стоп срабатывает при капитале ноль и ниже, а если закрыть
сделку не удалось, следующий тик решает заново, а не молчит до экспирации. Правило входа и размер
сделки прежние: фильтр по волатильности и наклон размера добавлены в движок выключенными.

В интерфейсе бота 2 карточка непрерывности показывает минуты, когда бот держал позицию без цены
перпа и хедж не мог исполниться, а карточка режима IV больше не выносит вердикт. В данных у леджера
бота 2 появилась строка blind, одна на такой эпизод, а у записи решения тика поле skip_reason.
Настройка ivEntryMaxRank из движка убрана: в старом профиле она просто не читается, миграции нет.

Бот 1 и сканер не затронуты: правки интерфейса касаются только карточек бота 2, а сканер из общих
правил схемы продавца зовёт только сборку настройки, размер по марже и зону продавца, и их поведение
прежнее. Остальное в выпуске это замеры и стенды схемы продавца, они запускаются из scripts/ и в
приложении не исполняются. Шесть книг охраны снялись побитово теми же.

• [BTC-Options] Бот считает слепоту хеджа и пишет её в леджер. 18 сентября аудит нашёл на
  живом прогоне 83.7 минуты, в которые бот держал позицию без цены перпа и хедж не мог исполниться:
  пять эпизодов, крупнейшие 36.0 минуты 05.09 и 38.3 минуты 15.09, оба от отказа биржи 503 ровно в
  09:00Z. Счётчик непрерывности показывал в это время два перерыва по 75-111 секунд совсем другого
  дня, потому что перерывом он считает пропуск ТИКА, а тики все эти минуты приходили исправно.
  Теперь слепой тик (структура открыта, цены перпа в снимке нет) считается отдельно от перерыва
  опроса, эпизод слепоты закрывается зрячим тиком и оставляет одну строку леджера типа blind с
  длительностью и числом слепых тиков, а решение цикла несёт поле skip_reason: SKIP при живом
  превышении полосы из-за отсутствия цены больше неотличим от SKIP внутри полосы. Строка на
  ЭПИЗОД, а не на тик: 36 минут при опросе раз в 15 секунд это 144 тика.

• [BTC-Options] Строка разрыва фандинга называет то, что было. Часы начисления стоят и
  когда приложения не было, и когда оно шло слепым, а строка funding-gap называла любой такой
  интервал «разрывом тиков». На живом прогоне это врало дважды. Теперь причину называет счётчик
  тиков с последнего оценённого начисления, а не догадка.

• [BTC-Options] Карточка непрерывности показывает слепоту и больше не прячется от неё.
  Карточка скрывалась как здоровая, если перерывов опроса нет, поэтому в те 83.7 минуты оператор не
  видел ни числа, ни карточки: покрытие было около 100%. Добавлены клетка «слепота хеджа» с числом
  слепых тиков, своя таблица эпизодов (начало, длительность, тиков вслепую, причина) и отдельный
  тег. Полоса покрытия красит слепые минуты штриховкой: сплошь зелёная полоса рядом с клеткой
  «слепота 36 мин» спорила сама с собой. Идущая прямо сейчас слепота видна живой строкой, не
  дожидаясь конца эпизода.

• [BTC-Options] Карточка режима IV перестала выносить вердикт чужой схемы. Она считала вход
  благоприятным, когда подразумеваемая волатильность у НИЗА своего суточного окна: суждение схемы,
  которая волатильность ПОКУПАЕТ (исходная Strategy One, длинный стрэддл). Живой бот её ПРОДАЁТ с 4
  сентября, то есть зелёный горел ровно наоборот. Признак favorable и настройка ivEntryMaxRank
  убраны из движка, карточка осталась наблюдением: те же числа, суждения нет. Вердикт не развернули
  намеренно: разворот утверждал бы «вход выгоден, когда IV у верха окна», а такого замера нет, и
  ближайший замер (22.09, пять лет) дал отрицательный ответ по обеим формам действия. Заголовок,
  метка и справка карточки переписаны на обоих языках, тест стережёт, что вердикт не вернётся молча.

• [BTC-Options] Фильтр по волатильности на входе схемы продавца замерен на боевой
  конфигурации и ОТКЛОНЁН. Живая цепочка открывает сделку, как только в окне срока 336-672 часа
  нашлась нога с нужной дельтой, и о волатильности не спрашивает вовсе, хотя результат продавца
  решает разница между проданной подразумеваемой волатильностью и той, что реализуется за время
  удержания. Замерены обе формы ответа на эту величину, критерий записан до первого прогона
  (протокол bot2-предрегистрация-фильтра-волатильности-2026-09-22.md, внутренний каталог проекта
  вне репозитория). Запрет входа:
  база 84 сделки ×4.12, все шесть клеток сетки порогов ниже (лучшая ×4.08), время вне рынка растёт
  с 0.5% до 21.9%, средняя сделка не двигается, то есть гейт отбирает те же сделки, просто меньше.
  Изменение размера: ни одна из 27 клеток не взяла планку, а клетки, обгоняющие базу, делают это
  пробитым потолком загрузки маржи (89-103% против 80%) и двумя ликвидациями счёта. Нулевой
  контроль постоянным множителем той же средней величины берёт тот же рост при пике маржи на 10-14
  процентных пунктов ниже и без ликвидаций: вклад самого сигнала 1.020 по медиане. Вывод устоял в
  обеих половинах записи и под тремя стрессами издержек. Отчёт:
  ОТЧЁТ-бот2-фильтр-волатильности-2026-09-22.md там же.

• [BTC-Options] Правило наклона размера от разрыва IV-RV добавлено в движок ВЫКЛЮЧЕННЫМ.
  sizeTiltMult и parseSizeTiltSpec в otmscan/sellhedge.js, дефолт sizeTilt: null, при нём
  ни одна ветка не исполняется и арифметика протяжки прежняя до бита, тем же приёмом, каким в
  схеме живёт выключенное правило досрочного выхода. Нужно затем, чтобы отрицательный вывод можно
  было перепроверить на новой записи или пересчитать после правки издержек: до августа такой вывод
  жил в проекте цитатой, которую перепроверить было нечем.

• [BTC-Options] Починена таблица автономного правила размера: с 28.08 она печатала шапку без
  единой строки. Ключ, под которым цепочка кладётся в память, и ключ, под которым таблица её
  оттуда достаёт, собирались в двух разных местах eval-accel.mjs. 28.08 вместе с замером
  досрочного выхода к первому приписали подпись правила, второй остался прежним, промах поиска
  гасился подстановкой пустого значения, и строка молча пропускалась. Второго ключа больше нет:
  строки цепочки лежат под собственным ключом варианта, а промах роняет прогон с ошибкой. На
  выбранные 26.08 константы X=45 cap=0.8 дефект не повлиял, их считали до его появления.

• [BTC-Options] Стенд eval-accel.mjs научился мерить фильтр: флаги --gate,
  --gate-sweep, --tilt, --tilt-sweep, столбцы «вне рынка» и «средняя сделка» в таблице
  размера, нулевой контроль постоянным множителем рядом с каждой клеткой наклона. Разбор условия
  гейта, сравнение и счётчик отклонённых входов зовутся из движкового hist-gate.js, второй
  реализации не заведено. Формула доли времени вне позиции вынесена туда же из
  hist-sellhedge.mjs: её печатают два стенда, а две копии одной формулы расходятся молча.

• [BTC-Options] Стенд продавца научился идти мелким кадансом, и часовая запись оказалась
  оптимистичной втрое. Полоса хеджа 0.03 BTC на контракт выбрана перебором по ЧАСОВОЙ записи, а
  живой бот переоценивает позицию раз в 15 секунд: часовая сетка не может дать больше 24
  пересечений полосы в сутки по построению. Ключ --fine подаёт протяжке наблюдённый путь индекса
  из кэша поштучных сделок (index_price на каждом принте), а волатильность и базис форварда
  по-прежнему берутся из часовой записи: полосу пересекает движение индекса, а греки меняются
  медленно. Дельта на мелком шаге ПЕРЕСЧИТЫВАЕТСЯ Блэком-76 от наблюдённого индекса, а не
  протягивается между часами: протяжка монотонна по построению, а перекладки создаёт ровно
  немонотонность внутри часа. Выход сделки оценивается часовым снимком, то есть той же ценой, что
  у часового прогона, поэтому между двумя прогонами меняется ТОЛЬКО хедж: статья «премия минус
  выкуп» в обоих 14811 до доллара.

  Что это показало на пяти годах при живой мейкерской ставке 0.015%: рост залога ×32.84 на часовом
  шаге против ×9.36 на настоящем, перекладок 5996 против 17842. Но подорожали не комиссии, а
  ГАММА: комиссии выросли на $2765, а сама нога хеджа упала с +35142 до +24267, то есть на $10875.
  Часовая сетка не видит внутричасовых разворотов, за которые короткий опцион платит, и потому
  показывает хедж лучше, чем он есть.

  Восстановление сверено с живой записью тиков: на окне сделки 2 оно даёт 634 перекладки против
  633 у бота и оборот 1.212 BTC на контракт в сутки против 1.187, а восстановленная дельта против
  дельты биржи на одних метках расходится на 0.00066 по медиане при суммарном движении
  шаг-к-шагу 41.57 против 39.91, то есть лишнего дрожания 4.2%.

  Цена: два новых стенда (hist-index-path.mjs разбирает 568 МБ принтов в таблицу пути один раз,
  hist-fine-band.mjs считает пересечения полосы для произвольной позиции), сетка стоимостей в
  --band-sweep дополнена живой ставкой 0.015%, просадка в ней читается там же, а не при нуле.
  Без ключа --fine ни одна новая ветка не исполняется: шесть книг охраны снялись побитово теми
  же, тестов 1177.

• [BTC-Options] Оценщик ускорения оборота тоже пошёл мелким кадансом, и заголовочный
  пятилетний рост боевой схемы уполовинился. eval-accel.mjs получил тот же ключ --fine, что и
  эталон, плюс ключ --band: полоса хеджа это константа схемы, и проверить её на БОЕВОМ правиле
  размера (автономная стресс-маржа X=45, cap=0.8) иначе было нечем, потому что у эталона правило
  размера другое. Протяжка мелкой сеткой добавлена обоим путям стенда, одиночной ноге и стрэнглу; у
  пары обе ноги считаются от одно...

v0.4.2

[0.4.2] - 2026-09-22

Влияние: UI - карточка бота 1 на «Обзоре» показывала одно число там, где их два: сумму по
всем позициям счёта, включая давно закрытые. Пока сделка одна, это и есть её результат, но рядом с
закрытой сделкой по строке нельзя было понять, зарабатывает бот сейчас: 22.09 на боевой машине
«Обзор» показывал -$6.12 при текущей сделке +$4.57. Теперь строка называет обе величины и каждую
своей подписью.

Торговая логика и P&L не тронуты ни одной исполняемой строкой. В выпуске два коммита: правка
интерфейса и правка текстов. Файлы движка в диффе есть, но изменены в них только комментарии
(fa/impact-curve.js, fa/slice.js), поэтому шесть книг охраны снялись побитово теми же, и
поведение обоих боевых трактов не сдвинулось. Данные профиля и настройки прежние, обновление
ничего не мигрирует.

• [Funding-Arb] Карточка бота 1 на «Обзоре» называет прибыль ТЕКУЩЕЙ сделки рядом с итогом
  счёта. Строка карточки показывала одно число, accountSummary, то есть сумму по ВСЕМ позициям,
  включая давно закрытые; кокпит вкладки Funding-arb показывает ОДНУ текущую сделку. Пока сделка на
  счету одна, это одно и то же число, и разницы не видно. Как только рядом появляется закрытая,
  числа расходятся на её результат: 22.09 на боевой машине «Обзор» показывал -$6.12 при текущей
  сделке +$4.57, и разница в $10.70 целиком принадлежала сделке, закрытой руками 18.09. Оба
  числа были верны, но с «Обзора» нельзя было понять, зарабатывает бот сейчас.

  Теперь при двух и более позициях строка называет обе величины и каждую своей подписью: «текущая
  сделка» и «счёт целиком, если закрыть». При одной позиции строка не меняется вовсе, потому что
  печатать одно и то же число дважды незачем. Позиция отбирается ТЕМ ЖЕ выражением, что и кокпит
  (tradeSelectedPosition), и берётся то же поле summary.netPnl: два экрана, называющие «текущей»
  разные сделки, были бы хуже одного экрана без числа. Это стережёт новый тест в fa-ui.test.js.

  Движок не тронут ни строкой: правка живёт в renderer/index.html и двух словарях. Шесть книг
  охраны снялись побитово теми же.

• [Funding-Arb] Оценка «плоская константа завышала удар в 8-100 раз» снята как непроверенная, на
  её месте замер. Диапазон стоял в шапках движка, в секции 0.4.1 этого файла, в отчёте фазы и в
  письме заказчику, но измерен не был: он выведен из «0.1-1.2 базисного пункта» задания фазы, а то
  пришло из шапки fa/sizing.js. Замер по снимку глубины от 19.09 (тикет $2500, 126 наблюдений, то
  есть 63 рынка на две стороны) даёт медиану 0.001 бп, ровно ноль у 57 наблюдений из 126,
  p95 2.63 и максимум 13.38. Константа берёт 10 бп и выше измеренного в 125 наблюдениях из 126,
  а отношение гуляет от x0.7 (единственный рынок, где константа НИЖЕ) до сотен тысяч на нулях
  при медиане x50. То есть «8-100» и занижает типичный случай, и умалчивает про случай, где
  константа мала; само «0.1-1.2 бп» не держится даже на BTC и ETH, где при $2500 выходит
  0.000-0.046 бп.

  Заменено везде, включая текст секции 0.4.1 выше. В шапке fa/sizing.js число НЕ тронуто: это
  чужая работа, восстановить, на чём оно мерилось, не удалось, и переписывать задним числом хуже,
  чем назвать открытым вопросом. Правка только в комментариях и текстах, поведение не тронуто.

v0.4.1

[0.4.1] - 2026-09-19

Влияние: торговая логика (бот 1) · P&L · UI · настройки/данные - бот 1 перестал
считать удар по рынку плоской константой 0.1% и берёт измеренную кривую глубины GMX. Константа
берёт 10 базисных пунктов, а измеренная величина на тикете $2500 это медиана 0.001 бп (ровно ноль
у 57 наблюдений из 126) при максимуме 13.38: константа выше измеренного в 125 наблюдениях из 126,
и вместе с ней завышен круг издержек, из-за чего правило отказывалось от рынков,
которые окупались бы: замер на 63 рынках при капитале $2500 даёт $840.30 нетто за год против
$775.84, то есть +$64.46. Круг сделки при $2500 стал около $6.3-6.9 вместо $8.75. Заодно
леджер перестал списывать своё число и книжит ровно тот круг, на котором принято решение.

Что увидит владелец открытой сделки при обновлении. Уже открытая позиция не трогается: её круг
списан и заморожен в момент входа. Изменится СЛЕДУЮЩЕЕ решение: круг подешевеет, и в состав
кандидатов вернутся рынки, которые прежний круг отсекал. В карточке издержек статья
«проскальзывание GMX» получила пометку, что правило входа и леджер её больше не берут, когда у
рынка есть измеренная кривая; само поле осталось редактируемым.

Клиенту, который стоит на 0.3.1. Обновление приведёт сразу сюда, минуя промежуточные версии,
поэтому для него действуют ЧЕТЫРЕ секции: 0.3.2 и 0.3.3 (они так и не публиковались), 0.4.0 и эта.
Главное из пропущенного: бот 1 перестал считать по пяти зашитым рынкам и собирает вселенную живым
отбором, плюс аудит механики 18.09 и починка его находок. Полный текст всех секций лежит в
CHANGELOG.md.

Проверено живьём на боевой машине 18.09 в 21:14Z: первое решение с кривой вошло в рынок,
которого в снимке нет вовсе (Avalanche, запасная кривая по ярусу ликвидности), круг сделки $6.32
вместо $8.75, и три числа сошлись между собой - круг правила в записи решения, списание позиции и
статьи в паспорте сделки.

Исправлено

• [Funding-Arb] Кривая удара GMX дошла до живого тракта. slice.js подавал в правило
  impact: { gmxNodes: [] }, и пустые узлы означали НЕ ноль издержки, а плоскую константу
  gmxImpact 0.1% из costs.js: пустая кривая выключает ветку hasGmxCurve в costAtSize, и круг
  считается по константе. Константа берёт 10 базисных пунктов, а измеренная величина на тикете
  $2500 это медиана 0.001 бп (ровно ноль у 57 наблюдений из 126) при максимуме 13.38, то есть
  константа завышала круг издержек почти везде. Цена, названная отчётом
  фазы 3: -$64.46 нетто за год на 63 рынках при капитале $2500 ($840.30 против $775.84), и она
  РОСЛА С ЧИСЛОМ РЫНКОВ, потому что завышенный круг отсекает ровно те рынки, где нетто и круг
  сопоставимы, - а вселенная как раз выкачена на полусотню.

  Измеренный снимок глубины (impact-gmx.json.gz, 63 рынка Arbitrum, 623 256 наблюдений за год)
  лёг в данные приложения src/engine/fa/data/, откуда его пакует electron-builder без правки
  конфигурации (files: ["src/**/*"]). Узлы приносит новый читатель fa/impact-curve.js, файл
  открывает main/impact-load.js: срез остаётся ЧИСТЫМ, как и был. Знак приводится в одном
  месте (Math.max(0, -(adverseBps ?? 0)), образец exit-lib.mjs loadCapacity): приведение
  дважды дало бы отрицательную издержку, то есть премию за собственный вход.

  Правила движка не тронуты ни строкой, и это проверено суммами: все шесть книг снялись ПОБИТОВО
  теми же (сверка прогонов до и после правки, sha256 совпали у каждой). Это и есть доказательство,
  что правка живёт в срезе, а не в правиле. Замер эффекта на трёх годовых фикстурах книгой правила
  входа против её же контроля --drop-rule impact-off: нетто $1354.79 против $1297.52 (+$57.27),
  круг издержек $240.84 против $283.28, профинансировано 16 решений из 33 против 14. Два рынка
  (ETH блок 3, BTC блок 9) плоская константа отвергала кодом below_fund_ratio, а с измеренной
  кривой они проходят.

• [Funding-Arb] Рынок, которого в снимке нет, получил НАЗВАННЫЙ запасной путь вместо молчаливой
  подстановки. Это не краевой случай: на живом составе фикстуры 16.09 снимок не покрывает
  16 инструментов из 51 (31%) - четыре рынка Avalanche (снимок снят по Arbitrum, и глубина рынка
  ETH на Avalanche это не глубина ETH на Arbitrum) и двенадцать листингов Arbitrum новее периода
  снимка (VVV, XMR, ZEC, XPL, SKY, AERO, HBAR, MET, PUMP, ICP, LIT, CC). Источник кривой каждой
  строки едет в live.gmxCurveSrc (market, tier, pooled, none), и молчаливого источника
  нет ни у одной.

  Обе ветки замерены методом исключения по очереди на тех 63 рынках, где правда известна
  (тикет $2500, 126 наблюдений, |ошибка| в бп за круг): запасной путь по ярусу ликвидности даёт
  медиану 0.07 (p95 2.58), по общему пулу 0.06 (p95 2.61), плоская константа - 10.00
  (p95 10.00). Константа переоценивает удар в 125 наблюдениях из 126. Ветка ОТКАЗА (код
  univ_no_impact_curve) отклонена замером: она сняла бы с вселенной те самые 31% инструментов,
  включая все рынки Avalanche и каждый новый листинг навсегда, то есть отменила бы фазу 3 тем
  незаметнее, чем дальше снимок от сегодняшнего дня. Ветка none оставлена достижимой и под тестом.

  Граница названа честно: запасная кривая это ЦЕНТР яруса, поэтому на тесных рынках она удар
  НЕДООЦЕНИВАЕТ - в ярусе D_<200k 15% наблюдений недооценены больше чем на 0.5 бп, худшее 13.22 бп;
  в ярусах A и B недооценки нет (максимум 0.07 и 0.74 бп). Новый листинг почти всегда тесный, то
  есть попадает ровно в тот ярус, где запас слабее всего. Это повод пересчитывать снимок, а не
  считать его вечным.

• [Funding-Arb] У снимка глубины появился срок годности, а у записи решения дата снимка и
  источник кривой каждого рынка. Возраст считается от КОНЦА ПЕРИОДА снимка, а не от дня съёмки:
  снимок снят 30.08, но посчитан по истории до 20.06, то есть в день рождения уже отставал от рынка
  на 71 сутки. Конец периода лежит в самом файле числом (meta.period), поэтому вбивать дату
  константой и следить, чтобы она не разъехалась с файлом, не нужно. Срок 180 суток, для
  нынешнего снимка это 17.12.2026. Он обоснован охватом: за 90 суток после конца периода живая
  вселенная набрала 13 имён Arbitrum, которых снимок не знает, и при том же темпе своя кривая
  рынка перестаёт покрывать хотя бы половину состава примерно на 170 сутки. Это ДОПУЩЕНИЕ: под ним
  одна скорость на одном промежутке, продолженная прямой, а второй механизм старения, дрейф глубины
  на покрытых рынках, не замерен ничем, потому что живьём удар не наблюдаем вовсе.

  После срока расчёт НЕ меняется, и это замер, а не смелость. Обе замены измерены и обе хуже:
  плоская константа ошибается в медиане на 10.00 бп против 0.07 у яруса, отказ рынку без своей
  кривой снимает 31% вселенной. Поэтому просрочка это сообщение: строка журнала на буте, флаг st
  в каждой записи решения и падение офлайн-смоука npm run smoke:impact кодом возврата. Неизвестный
  возраст считается просроченным, а не свежим.

  Запись решения понесла три новых числа: блок im с датой конца периода, возрастом снимка на
  час решения и флагом просрочки, плюс поле im с именем источника кривой у каждого рынка и
  каждого отказа. Без них круг издержек k в строке решения нечем объяснить задним числом: он
  посчитан либо по своей измеренной кривой рынка, либо по подстановке по ярусу, а по числам эти два
  решения неразличимы. Строка решения подорожала на 41 байт плюс 14 байт на рынок, решение одно в
  сутки, поэтому в таблице объёма сдвинулась одна сотая в клетке «63 рынка, опрос 1 мин»
  (35.66 МБ в сутки против 35.65). Правила движка снова не тронуты: шесть книг побитово те же.

• [Funding-Arb] Леджер бумажной сделки списывает круг ПРАВИЛА, а не свой. Правка кривой
  развела решение и учёт, и до неё они сходились: правило считает круг по измеренным кривым (удар
  GMX из снимка глубины и стакан Hyperliquid), а faOpenFromIntent списывал его по плоской модели.
  Замер на живой записи: правило посчитало $7.36, леджер списал $8.75, из них $2.50 статьёй удара,
  которую правило на том же рынке оценило в $0.00. На 27 кругах в год это до $67 издержек, которых
  нет, то есть величина того же порядка, что и весь выигрыш кривой $64.46: бот зарабатывал бы
  решениями, а отчитывался бы по другому числу.

  Теперь openPosition получает intent.costUsd, то самое число, на котором принято решение.
  Пересчёта здесь нет и быть не должно: вторая копия расчёта круга разошлась бы с первой на
  следующей же правке. Статьи для леджера строит новый breakdownForTotal (costs.js): комиссии и
  газ точные из модели, всё, что правило насчитало сверх них, это измеренное проскальзывание обеих
  площадок одной строкой. Сумма статей сходится с кругом по построению (до ошибки округления
  двоичной дроби, 9e-16 на круге $7.36), и это важно: интерфейс леджера показывает Σ детализации
  рядом с кругом целиком. Круг ниже комиссий разбивки не даёт вовсе, чтобы не выдумывать
  отрицательную статью: так честнее, чем смешивать два числа в одной строке.

  Заодно починено, что запись сделки ПЕРЕСЧИТЫВАЛА статьи из текущих настроек вместо того,
  чтобы документировать списанное. Это врало и до кривой: модель издержек редактируема, и правка
  между открытием и записью переписала бы историю. Теперь статьи берутся с позиции, где они
  заморожены в момент входа. Проверено живьём: правило $6.57, позиция $6.57, запись $6.57, статья
  проскальзывания $0.32 против плоских $2.50 до правки.

  Подпись статьи в леджере стала «проскальзывание обеих площадок»: она больше не про одну GMX.

Добавлено

• [Funding-Arb] Статья «проскальзывание GMX» в карточке издержек помечена как не работающая
  у правила входа. С появлением кривой эту статью берут не все потребители круга: costAtSize
  при живой кривой зануляет её и подставляет измеренное, а кривая сегодня есть у всех 54
  инструментов живого состава, то есть настроенное з...

v0.4.0

Влияние: торговая логика (бот 1) · P&L · UI · настройки/данные - выпуск раздаётся
клиентам, стоящим на 0.3.1, вместе с непубликованными 0.3.2 и 0.3.3, поэтому для них действуют ТРИ
секции: 0.3.2, 0.3.3 и эта. Главное здесь: бот 1 перестал считать по пяти зашитым рынкам и собирает
вселенную живым отбором (на снимке 18.09 это 50 рынков из 151 плюс пять имён запаса), и это теперь
поведение ПО УМОЛЧАНИЮ. Замер расширения от 16.09: те же правила и тот же капитал $2500 дают около
$40 в год на двух монетах и около $560 на полусотне имён. Плюс аудит механики 18.09 и починка его
находок: живой тракт исполнял не то правило, которое стерегут книги, и разница стоила 9.8% годового
нетто.

Что увидит владелец открытой сделки при обновлении. На первом кадансе после перехода правило
выхода сравнит её не с четырьмя альтернативами, а с полусотней, и может переложиться. Убытком это
не является: перекладка требует, чтобы нетто альтернативы перебило брутто удержания на полный круг
издержек. Но момент такого решения назначает обновление, а не рынок. Кому нужна ровно старая пятёрка
до закрытия сделки, ставит FA_UNIVERSE_APPLY=0.

Добавлено

• [Funding-Arb] Правило отбора вселенной рынков src/engine/fa/universe-scan.js (фаза 1 плана
  расширения от 2026-09-16). Чистая функция selectUniverse пересекает живой список рынков GMX с
  монетами Hyperliquid и отсекает по листингу, свободной ёмкости худшей стороны и доле нашего тикета
  в открытом интересе рынка. Каждый отвергнутый рынок несёт код отказа (univ_not_perp,
  univ_not_listed, univ_no_hl, univ_no_room, univ_oi_share, univ_too_young, univ_capped,
  univ_no_ticket), и сумма инструментов и отказов равна числу поданных рынков: молчаливого
  пропуска нет. Пороги живут замороженной константой FA_UNIVERSE_DEFAULTS, то есть решение
  владельца это значение, а не правка кода. Ключ инструмента <SYM>-<цепь>-<пул>: у GMX несколько
  рынков на один символ на одной цепи (у BTC на Arbitrum три, с открытым интересом $12.4 млн,
  $3.67 млн и $2934), и ключ по символу схлопнул бы их молча; существующие ключи ETH, BTC и
  ETH-Avax закреплены за адресами рынков и не меняются. На снимке 16.09 (147 рынков GMX, 178 живых
  монет биржи) при тикете $2500 порог 10% даёт 49 инструментов и 98 отказов, порог 100% даёт 84 и 63;
  снимки обрезаны в фикстуры test/fixtures/markets-info-*.json и hl-meta.json. Попутно замерено
  и заведено значениями, по умолчанию выключенными: ворота покрытия истории новые имена НЕ держат
  (самый молодой из 49 старше 216 суток, а долив баз закрывает 720 часов одним запросом), для этого
  есть порог возраста рынка minListingAgeDays; точное совпадение имён теряет четыре рынка, которые
  Hyperliquid котирует в тысячах штук (kPEPE, kSHIB, kBONK, kFLOKI), для этого есть пустая таблица
  псевдонимов hlCoinAliases, добавляющая при пороге 10% один рынок. Отбор НЕ ПОДКЛЮЧЁН:
  universe.js не тронут, автомат по-прежнему считает пять инструментов, книги побитово те же.

• [Funding-Arb] Снабжение живым списком вселенной под флагом FA_UNIVERSE_SCAN=1 (фаза 2 того же
  плана). Список рынков перестал быть зашитым: он собирается отбором на кадансе решения, переживает
  перезапуск в профиле (funding-arb-universe.json), и по нему идут снимки, наблюдение баз, стаканы,
  прогрев и долив кадров, панели и запись. Автомат при этом продолжает решать по ПЯТИ именам:
  срез правила входа остался на ALL_MARKETS, применение это фаза 3. При FA_UNIVERSE_SCAN=0
  поведение прежнее побитово - список становится ровно ALL_MARKETS, ни одного лишнего запроса и ни
  одного лишнего байта записи.
  Развод схем сделан правилом resolveUniverse: отбор возвращает РЫНКИ, приложение торгует
  ИНСТРУМЕНТЫ, и голая подстановка потеряла бы одноногую половину вселенной (ключей ETH-Arb и
  BTC-Arb отбор не выдаёт вовсе) и сменила бы схему ключу ETH-Avax с одноногой на двуногую, уведя
  кадры и летопись баз из-под него. Запас universe.js побеждает по ключу, схема ключа не меняется
  никогда, и новый рынок получает ТОЛЬКО двуногую схему: вся измеренная экономика расширения снята
  двуногой схемой по одному инструменту на имя, одноногая для новых имён не измерена вовсе. На
  снимке 16.09 это 49 рынков отбора, из них три под ключами запаса, то есть 51 инструмент приложения
  (48 двуногих и 3 одноногих).
  Удерживаемый инструмент ПРИКРЕПЛЁН к списку до закрытия сделки, а список поднимается с диска ДО
  ловушки сирот на буте: closeOrphanedPositions() закрывает позицию, чей инструмент не опознан, и
  при живом списке перезагрузка приложения закрыла бы живую сделку без единого решения правила.
  Запись снимка получила блок состава u (источник, число инструментов, пороги в силе и перепись
  отказов по кодам в каждой строке; полный перечень пар «ключ, код» только в строке пересборки).
  Объём при 51 инструменте и опросе раз в пять минут 5.85 МБ в сутки, то есть 2.14 ГБ в год: число
  3.66 МБ из плана относилось к 32 именам. Потолок пер-рыночных отказов на пульте поднят с 8 до 40 и
  дополнен переписью по кодам без потолка. Источники получили вторые выходы (markets у GMX,
  universe у Hyperliquid): приведение теряет isListed, listingDate и признак делистинга монеты,
  и отбор на приведённых строках отказал бы всем рынкам либо принял бы делистингованную монету за
  годную ногу хеджа.
  Стаканы переведены на каданс решения ТОЛЬКО на пустом слоте, и это поправка к плану по замеру:
  порог свежести стакана у правила входа 30 секунд, а событие и сторож залога решают вне каданса и,
  войдя в ветку решения, сдвигают метку решения безусловно, поэтому суточный каданс стаканов под
  открытой сделкой не отложил бы форсированное решение, а съел бы событие. Оба форсирующих условия
  требуют открытой позиции, поэтому правило точное: слот пуст - стаканы к решению, сделка есть -
  каждый опрос. Цена измерена и мала: 40 монет параллельно стоят 296-521 мс против 277 мс на двух.

• [Funding-Arb] Применение живого списка в срезе правил под флагом FA_UNIVERSE_APPLY=1 (фаза 3
  того же плана). Автомат перестал считать по пяти именам: срез правила входа и правила выхода
  берётся с живого списка. Флаг ПО УМОЛЧАНИЮ ВЫКЛЮЧЕН и требует включённого FA_UNIVERSE_SCAN
  (просьба применить без сбора не исполняется молча, а называется в журнале); при выключенном срез
  остаётся ровно ALL_MARKETS, и живой бут это подтвердил: снабжение видело 50 инструментов, срез
  оставался на 5. Складка среза вынесена из главного процесса в движок (src/engine/fa/slice.js) и
  там же под тестом на полусотне инструментов: проверять срез по копии складки значило бы проверять
  копию. Схема строки берётся у schemeOf, то есть второй точки правды о схеме больше нет.
  Приёмка ФОРМЫ, а не чисел, и это поправка к плану: план требовал воспроизвести офлайн-прогоном
  нетто $559.11 и 22 перекладки, но стенд воспроизводит их точно и о приложении не говорит ничего.
  Срез приложения отличается от среза стенда ПО ПОСТРОЕНИЮ - у стенда нет полей bookMissing и
  bookAgeSec (значит ворота стакана не работают вовсе), зато есть кривая удара GMX, которой у
  приложения нет, и имя рынка у него голый токен против ключа инструмента. Совпадение чисел
  означало бы, что срез приложения потерял ворота стакана, поэтому проверяется паритет формы:
  рынок со свежим стаканом даёт побитово ту же кривую, что и он же без живых ворот, а коды no_book
  и stale_book приходят только от ворот и взяться без них неоткуда.
  Удерживаемый рынок, не прошедший ворота данных, проверен отдельно: брутто удержания стакана НЕ
  требует вовсе (удар это издержка сделки, а не начисление), поэтому потеря стакана своей монеты
  удержание не ослепляет и сравнение не портит; теряется ровно одна возможность - перекладка в тот
  же рынок другим размером, и она отказывается честным кодом no_book.
  Живая трасса расчёта перестала копировать себя на каждом проверенном размере. Замер на данных
  стенда при капитале $2500: на 51 рынке решение стоило 3939 мс против 530 мс без трассы, то есть
  3.4 секунды синхронного простоя главного процесса, и это без учёта 2537 отправок снимка общим
  весом 294 МБ; на 63 рынках было 6481 мс. Трасса копится на месте
  (applyFaEntryTraceEvent), а наружу уходит отсоединённым снимком не чаще 200 мс: решение на 51
  рынке стоит 560 мс, отправок 3 общим весом 277 КБ. Записанная трасса от этого не теряет ни одного
  образца и сверена побитово со старым способом на 5, 32, 51 и 63 рынках.
  Журнал автомата получил строку состава решения: число рынков среза, годных по истории,
  профинансированных, стоимость решения в миллисекундах и перепись отказов по кодам. Печатается на
  решении, на смене исхода и на смене числа годных - последнее ради прогрева, в который исход не
  меняется ни разу, а срез растёт с нуля до полусотни.

• [Funding-Arb] Интерфейс на полусотне рынков (фаза 4 того же плана). Автомат с фазы 3 решает по
  полусотне, а вкладка писалась на пяти именах: живой замер дал 15 739 пикселей содержимого, из них
  7797 одна карточка расчёта. Стало 8734 и 1935, то есть вкладка вдвое ниже, а карточка расчёта
  вчетверо, и ни одно число с экрана при этом не ушло. Сделано четырьмя правками.
  Состав вселенной едет в набор и стоит строкой над сводкой оценки: источник списка, просмотрено
  и взято, пороги и перепись отказов ПО КОДАМ («доля интереса 56, нет на бирже 24» вместо сотни
  строк). Это единственное место, где до экрана доходят восемь кодов отбора: рынок, отсечённый
  отбором, в срез правила не попадает вовсе, и строки в сводке у него нет и быть не может, поэтому
  без состава перевод этих кодов описывал бы недостижимое состояние. Все восемь названы словами в
  обоих словарях, и сверка кодов с реестрами движка идёт теперь по ПЯТИ реестрам в обе стороны.
  Сводка оценки получила поиск по имени, порядок по нетто (это критерий самого правила входа),
  фильтр по исходу чипами с числами и свёртку хвоста: раскрыты первые десять строк плюс
  удерживаемый рынок, остальные по кнопке...

v0.3.1

Влияние: торговая логика (бот 2 и сканер) · P&L · UI · настройки/данные - выпуск накопил
212 коммитов после 0.3.0. У бота 2 сменилось правило размера сделки, уточнён учёт хеджа,
добавлены структура «стрэнгл продавца» и цепочка сделок, а маржинальный риск стал видимым
заранее, а не в момент подхода к ликвидации. Сканер получил слой записи рынка, греки из
подразумеваемой волатильности и режим «продажа»; три дефекта, из-за которых он не мог выдать
сигнал вообще, исправлены. Интерфейс получил переключатель языка RU|EN. Бота 1 затронула
только локализация, его торговая логика не изменилась ни одной строкой.

Про бота 2 отдельно, потому что это торговая логика и деньги. Размер сделки теперь выводит
движок, а не оператор: доля депозита deployPct в вооружении цепочки заменена стресс-правилом
(лоты подбираются так, чтобы маржа поддержания при движении спота на ±45% не превышала 80%
счёта). На профиле, где deployPct правили руками, размер входа ИЗМЕНИТСЯ. Поведение хеджа
изменится и при настройках по умолчанию, как только позиция по бессрочному фьючерсу набирается
или уменьшается несколькими сделками по разным ценам, то есть в обычной работе. Прежде движок в
такой позиции неверно считал и её дельту, и её прибыль, а при уменьшении промахивался мимо
собственной цели хеджа; теперь оба счёта точны. Дополнительно поведение меняется, если структура
открыта размером, отличным от калибровочного (полоса теперь масштабируется размером). Цифры в
журнале за прошлые сессии не пересчитываются: исправления действуют с момента обновления.

Про место на диске: записи сканера занимают порядка 80 МБ за трое суток непрерывной работы,
записи тиков бота 2 добавляются суточными файлами рядом с ними. Это новые файлы в профиле,
ранее их не было.

Добавлено

• [BTC-Options] Маржин-колл стал видимым и заблаговременным (ревизия 2026-08-25: живая сделка
  прошла пик 104.5% утилизации MM, а пятилетний замер дал зону ликвидации, MM от 100% equity,
  в 13 сделках из 84 при deployPct 0.70). Счёт движка теперь отдаёт оценку цены ликвидации
  liq_price_est (цена индекса, на которой MM догоняет equity; модель: внутренняя стоимость ноги
  плюс текущая временная, решается точно по кусочной линейности формулы Deribit) и запас в
  долларах mm_headroom_usd. Карточка «Маржа и риск» показывает строку «ликвидация (MM = equity)
  при BTC ≈ $X (+Y%)», запас и цветовые зоны бара утилизации (до 60% зелёная, 60-80 жёлтая, от
  порога алерта красная); чип бота 2 на «Обзоре» при утилизации от порога несёт «МАРЖА N%»
  вместо фазы - прежде алерт жил только внутри вкладки. Пересечение порогов 80% и 90% вверх
  пишет строку margin-alert в журнал операций (гистерезис 5 п.п.: строка на пересечение, а не
  на тик) и шлёт системную нотификацию. Карточка «Маржа и риск» переехала из секции гипотез в
  сетку живого результата парой к кокпиту (она показывает бумажный счёт, а стояла под шапкой
  «гипотеза» в последней трети страницы; таблица ног заняла полный ряд). Под баром утилизации -
  шкала пути цены «вход · ликвидация»: заполнение равно пройденной доле пути от индекса входа
  (новое поле структуры entryIndex; старые позиции читаются через entryUnderlying) к оценке
  ликвидации, зоны цвета те же; та же метка LIQ рисуется на графике payoff открытой структуры
  (на гипотезе-превью её нет - живой риск не смешивается с конструктором). Пятилетняя книга
  движка после правок побайтово та же - добавлена только наблюдаемость, ни одно решение не
  изменилось.
• [BTC-Options] Измерители маржинального пути в репозитории. npm run margin:path
  (scripts/margin-path.mjs): живой движок по записи, таблица «пик MM · сделок MM≥80/90/100%»
  по уровням deployPct (это она показала 244% пика при 0.70 и чистые пять лет только у 0.20),
  плюс режим --size-rule stress - замер правила размера от стресс-маржи (лоты от «MM при споте
  ×(1+X%) не выше cap·equity» вместо доли IM на входе; кандидат на замену deployPct). У эталона
  hist-sellhedge.mjs появился --liquidation: симуляция счёта с принудительным закрытием при
  MM от 100% equity на любом часе пути сделки, чтобы «×N за 5 лет» перестал быть условным
  (на записи 2021-2026 у $20k: ×14.1 вместо ×15.5, 13 ликвидаций). Протяжка walkSellTrade
  получила опциональный наблюдатель шага onStep - читает и не меняет (закреплено тестом
  «итог не меняется ни на бит»; без наблюдателя отчёты прежние до байта).
• [BTC-Options] Автономный размер продавца: лоты каждой сделки цепочки считает ДВИЖОК
  двухсторонним стресс-правилом (lotsByStressMargin в margin.js: максимум q, при котором
  maintenance-маржа на споте ×(1±45%) не превышает 80% счёта; модель марка та же, что у оценки
  цены ликвидации; продавца колла связывает верхняя сторона, пары - худшая из двух). Операторского
  числа deployPct в вооружении цепочки больше нет: билет передаёт правило, размер выводится из
  живых величин ног на каждом входе, отказ называет расчёт числом («MM при ±45% $X за лот против
  80% счёта $Y»). Константы 45/0.8 НЕ выбраны на глаз: сетка eval-accel --size-rule stress на
  пяти годах дала 45% как наименьший запас, при котором пик MM-утилизации записи не превышает 0.8
  у обеих схем (колл 76.6%, стрэнгл 73.9%) при нуле ликвидаций и росте, равном внутривыборочной
  калибровке deployPct (×2.48 против ×2.59 и ×4.12 против ×4.09); cap 1.0 даёт ликвидации почти
  во всех клетках; ±45% читается как «переживи повтор худшего наблюдённого хода» (январь 2023:
  +47% внутри сделки). Правило deploy живёт в движке дефолтом - им сняты книги сверок, и они
  побайтово те же; паспорт соответствия показывает действующее правило размера строкой. Прежний
  замерный stressLots из margin-path заменён вызовом движковой функции. Плюс автономный фолбэк
  цепочки стрэнгла: структурное отсутствие пары (нет пута в допуске при живом колле) открывает
  колл, и структура честно несёт kind sell-call - на пятилетней записи случай не встречался ни
  разу, это страховка живого рынка от зависания цепочки, а не изменение замера.
• [BTC-Options] Структура «стрэнгл продавца» (sell-strangle): колл 0.45 + пут 0.45 одной
  экспирации с одним перп-хеджем по НЕТТО-дельте пары - перенос кандидата из исследования
  «ускорение оборота» (при равном хвосте пик MM ≤ 0.8 пара даёт ×4.09 против ×2.59 у одиночного
  колла за пять лет, перевес держится при стрессах исполнения; механизм: корреляция дневных P&L
  ног 0.515 плюс маржинный пол пута). Отдельного исполнителя у пары НЕТ: правила пары живут в
  sellstrangle.js (очередь пар для санитарии §1.8 - вето любой ноги переключает пару целиком),
  строитель в structure.js, дальше та же ветка продавца - decideHedge по нетто-дельте с полосой
  0.03·q, залог суммой ног тем же legMargin, общий расчёт в экспирацию, та же цепочка перевхода
  (билет цепочки теперь вооружает и ВИД структуры; старые цепочки без него читаются коллом).
  В тулбаре бота 2 третья кнопка схемы «стрэнгл»; карточки гипотезы и цепочки называют обе ноги
  через «+». Сверка пятилетних книг «эталон против живого движка» для пары пройдена ЖЁСТЧЕ
  планки sell-call: 84/84 сделки совпали по инструментам, датам, лотам и зоне, итог разошёлся на
  1.15% (у sell-call 4.9%) и целиком в двух известных конвенциях (база фандинга, целые контракты
  перпа); обе книги базовой схемы после правок движка побайтово те же; живой смоук UI на реальном
  Deribit чист (13 проверок, включая честные отказы скважности окна и «за лот пары не помещается»).
  По умолчанию ничего не меняется: схема включается только тумблером, боевой прогон на mbp15 не
  переключён - решение отдельное.
• [OTM-Scanner] Инструментарий исследования «ускорение оборота» схемы продавца (2026-08-26),
  целиком офлайн - живые тракты ботов не тронуты, пятилетние книги базовой схемы после правок
  побайтово те же. Правило выбора ноги получило тип legType (дефолт колл; «P» существует для
  замеров, живой тракт его не передаёт), МтМ шага сделки вынесен в движок (stepMtm - одна
  формула на режим ликвидации эталона и офлайн-оценщик). Эталон умеет --leg C|P и --deploy,
  margin-path - окно срока --expiry через sellCfg. Новый модуль движка sellstrangle.js:
  правила стрэнгла продавца (пара «колл + пут одной экспирации», вход суммой ног, хедж по
  нетто-дельте; своей протяжки нет - walkSellTrade ведёт пару через составную цену). Новый
  вызывающий scripts/eval-accel.mjs: сравнение вариантов схемы ПРИ РАВНОМ ХВОСТЕ - размер
  каждого калибруется под пик MM-утилизации за запись не выше порога (по умолчанию 0.8), затем
  тенор, путы, стрэнгл и лестница экспираций меряются ростом, тиковой просадкой и корреляциями
  при одинаковом хвостовом риске; стрессы исполнения флагами --perp-fee/--exec/--spread-scale.
• [OTM-Scanner] Столбец «зона» в книге сделок и разрез --zones у эталона схемы продавца.
  Перечень гейтов отвечает на вопрос «что будет, если не входить в плохом режиме», а вторая
  половина цитаты в шапке sell-scan.js («худшая зона давала +2.71% залога за сделку против
  +4.93% в среднем при просадке 26.7% против 13.5%») спрашивает другое - сколько принесли сделки,
  открытые В НЁМ. Теперь считается и это: книга несёт зону входа каждой сделки, а --zones печатает
  разрез по зонам (сделок, доля, средняя, медиана, худшая, итог, просадка). Заодно правило зоны
  стало функцией sellerZone в sellhedge.js и вызывается ОБОИМИ трактами: прежде оно жило
  выражением внутри computeSellScan, то есть чип «зона продавца» в карточке сканера и строка
  отчёта были бы двумя написаниями одного сравнения. Поведение живого сканера не менялось ни на
  бит (то же сравнение, те же тесты); «нет данных» осталось отдельным значением, а не тихим
  зачислением в благополучную зону - в начале записи RV7d ещё не набрал недельное окно. Столбец
  добавлен и в книгу replay-sellhedge.mjs: формат книг обязан быть одним на обе стороны, иначе
  compare-books.mjs перестал бы сверять их построчно, а так сверка заодно проверяет, что движок и
  эталон видят один режим рынка (сверка за год: зона 16/16). Прог...

v0.3.0

[0.3.0] - 2026-07-30

Крупный выпуск: BotLab становится мультиботовой оболочкой. Второй бот «BTC-опционы» (бумажный
крылатый стрэддл с дельта-хеджем) и третий бот-таб «Сканер OTM» (только наблюдение: сигналы входа
по волатильности, без ордеров) выходят вместе со светлой темой оформления. Отдельный проход по
отказоустойчивости закрыл потери данных при внезапном завершении приложения и долгих перерывах в
работе машины.

Влияние: торговая логика · P&L · UI · настройки/данные - добавлены движок опционных структур
с дельта-хеджем и движок сигналов сканера OTM (оба бумажные/наблюдательные, реальные ордера нигде
не выставляются); интерфейс перестроен в оболочку с тремя вкладками, добавлена светлая тема.
Пресеты дедбэнда и выбор исполнения в BTC-опционах теперь реально управляют хедж-движком (ранее
выбор не покидал конструктор); структура, дожившая до экспирации, теперь рассчитывается
автоматически. Funding-arb получил фикс долгого перерыва в начислениях и честные строки лога
сна/пробуждения машины - его основная логика и P&L не изменены, существующие позиции и журнал
не затронуты.

Добавлено

• [App] Оболочка-переключатель модулей: верхние вкладки «Обзор · Funding-arb · BTC-опционы» и
  стартовый экран «Обзор» со сводкой по ботам (готовые модули, открытые позиции, суммарный P&L).
  Funding-arb вынесен в отдельный вид без изменения его логики; навигация - по паттерну
  WAI-ARIA tabs с полной поддержкой клавиатуры.
• [App] Светлая тема оформления: сегмент-переключатель в шапке - луна/солнце, активная тема
  подсвечена; выбор сохраняется в настройках и применяется до первой отрисовки окна - без вспышки
  при старте. Палитра «бумажный
  терминал» сохраняет идентичность тёмной: те же оттенки зон и семантики прибыль/убыток/нейтрально,
  контраст ключевых пар текст/фон не ниже WCAG AA; графики перерисовываются в цветах темы при
  переключении. Тёмная тема осталась прежней и по умолчанию.
• [BTC-Options] Новый бот «BTC-опционы»: крылатый стрэддл на линейных USDC-опционах BTC
  (длинные ATM колл и пут, короткие OTM-крылья, один экспиратор не позднее 3 дней) с дельта-хеджем
  инверсным перпетуалом BTC-PERPETUAL. Данные - публичный REST Deribit, только чтение, без ключей
  и без ордеров (paper); бумажный депозит по умолчанию 100 USD. Движок изолирован от funding-arb:
  отдельный IPC-мост и отдельные файлы состояния.
• [BTC-Options] Хедж-движок: триггеры дельта/цена/время, фильтр издержек (сделка только при
  ожидаемой выгоде не ниже λ·издержек), пауза в окне расчёта 08:00 UTC и в последние 30 минут перед
  экспирацией. Панель решения (ХЕДЖ / ПРОПУСК / ПАУЗА), разнесённый P&L (MTM опционов, реализованный
  хедж, комиссии, фандинг перпа, нетто), таблица четырёх ног с греками, диаграммы payoff и
  дельта-коридора, журнал операций с экспортом CSV/XLSX/JSON.
• [BTC-Options] Сравнение «хедж против без-хеджа»: параллельный теневой расчёт без перпа показывает,
  окупает ли хедж собственные издержки.
• [BTC-Options] Метрики прогона: Sharpe по цикловым доходностям, доля прибыльных циклов,
  максимальная просадка, число и средний размер хеджей; графики P&L-траектории с атрибуцией и
  справочной цены BTC с маркерами исполнения хеджей.
• [BTC-Options] Реальная маржа Deribit (стандартная маржа коротких ног, без неттинга): начальная и
  поддерживающая маржа, текущая и худшая утилизация, честный флаг превышения депозита и алерт
  поддерживающей маржи с порогом 80 %.
• [BTC-Options] Стресс-сценарии: сдвиги цены ±5 % и ±10 %, скачок IV ±25 vol, фандинг ×3 за горизонт;
  каждая строка помечена режимом оценки (мгновенный / на экспирацию / за горизонт), сдвиги цены
  дублируются метками на диаграмме payoff.
• [BTC-Options] Авто-конструирование: кнопка «Старт (авто)» сама выбирает ближайшую живую экспирацию
  (не позднее 3 дней, минуя предэкспирационное окно) и страйки по офсету; подтверждение - тем же
  тикетом. Структурированные пре-трейд проверки: блокирующие причины (минимальный лот, кратность
  шагу, блэкаут расчёта) запрещают открытие; предупреждение «начальная маржа больше депозита»
  открытие не блокирует - решение остаётся за пользователем.
• [BTC-Options] Сигнал входа по волатильности: источник опрашивает ATM-полосу (стрэддл и крылья
  ±5/10/15 %), IV-ранг считается по скользящему окну 24 часа, индекс DVOL кэшируется с 48-часовой
  историей; карточка «IV-режим · сигнал входа» отвечает, благоприятен ли вход сейчас.
• [BTC-Options] Свип параметров: честный реплей накопленной истории снапшотов через чистый движок по
  сетке «крылья × дедбэнд × ценовой триггер × λ» (108 комбинаций), ранжирование по Sharpe, отметка
  комбинаций, не помещающихся в депозит; двухшаговое применение лучших параметров к конструктору
  (открытая структура и её замороженные параметры не затрагиваются).
• [BTC-Options] Телеметрия REST-канала: замер круговой задержки и серверного времени биржи; штамп
  подключения показывает канал и RTT. WebSocket-транспорт оценён и отложен: REST не показывает
  давления на лимиты, шов источника оставлен готовым к замене.
• [OTM-Scanner] Подготовка обкатки S3b: суточная статистика обкатки в otm-scanner-telemetry.json
  (аддитивный ключ stats) - распределения значений всех условий чеклиста и экономики лучшего
  кандидата (издержки round-trip, минимальный капитал против депозита), доля тиков «нет кандидатов»
  (материал вопроса Д8 об окнах экспираций), счётчики рестартов/деградации/блэкаутов; отчёт-скрипт
  npm run report:scan - markdown-отчёт по воротам обкатки (вычислимость условий с поправкой Д8,
  pass-rate и вырожденность порогов, экономика, журнал сигналов, материал калибровки слота
  «Калиброванный»). Скрипт читает файлы профиля только на чтение и не ходит в сеть; PURE-движок
  не тронут, funding-arb и бот 2 не задеты.
• [OTM-Scanner] UI «Сканер» (фаза S3a): третья вкладка и карточка «Обзора» (в сводку позиций и
  P&L сканер не входит - позиций у него нет), зона «Сигнал OTM» (токен состояния с dwell/TTL/
  кулдаун/блэкаут-полосой, чеклист 14 условий У1–У14 tri-state «да/нет/н-д» с ядром У1+У10+У14,
  кандидаты σ-окна с вердиктами У9–У14, экономика сделки лучшего кандидата: факты гейта У14 плюс
  подписанная модельная аналитика P(ITM) и сценариев, журнал сигналов с полным CSV-экспортом),
  зона «Настройка и качество» (пресеты Дмитрий v1/v2.0 и слот «Калиброванный», редактор порогов
  с blur-валидацией и скретч-пресетом «Калиброванный*» для несохранённых правок, флаг события с
  пунктирной рекомендацией пресета, панель честности pass-rate с CSV, кластер качества данных с
  бюджетом GET/тик и авто-деградацией, канвас «RV против IV» с зоной недооценки и маркерами
  сигналов), автостарт опроса при первом показе вкладки (решение А4), обе темы, e2e-сценарий.
• [OTM-Scanner] Интеграция в main-процесс (фаза S2, живые данные без UI): собственный источник
  опроса Deribit (перп + ATM-пары near/far + крылья ±1σ + кандидаты σ-окна, пересборка набора при
  дрейфе спота 2%/ролловере/смене стороны; стаканы только финалистам, не более 2 на тик), кэши
  свечей 1h (бэкфилл 10 дней) / DVOL (базлайн 90 дней) / цепочки опционов, IPC-неймспейс scn:*
  с пушем scn:push и мостом window.scn (start/stop/refreshNow/настройки/пресеты/флаг события/
  экспорт журнала сигналов и pass-rate телеметрии в CSV/JSON), персист в изолированные файлы
  otm-scanner{,-settings,-telemetry}.json (ACTIVE-сигнал переживает рестарт; битые файлы
  карантинятся), авто-деградация каданса x2 при серии ошибок с автоматическим выздоровлением,
  счётчик GET на тик как доказательная база бюджета запросов, живой самотест SCN_SMOKE=1.
  Опрос живёт строго между start и stop - в простое ноль трафика. Funding-arb и бот 2 не задеты.
• [BTC-Options] Сверка расчёта экспирации с официальной delivery-ценой Deribit: строки расчёта
  теперь несут метаданные (страйки, размер), и как только биржа публикует delivery-цену дня,
  в журнал добавляется строка «сверка» с поправкой реализованного P&L (расчёт по снапшоту индекса -
  прокси; официальная цена - 30-минутный TWAP индекса перед 08:00 UTC). Работает и на буте, если
  приложение было закрыто в момент экспирации.
• [OTM-Scanner] Движок условий и сигнала (фаза S1, чистый и без UI): чеклист У1-У14 с tri-state
  вердиктами (да/нет/н/д/выкл), режимами инфо/гейт и гистерезисом; экономика сделки по фактам
  (комиссия 0.0003 индекса с кэпом 12.5% премии, спред по модели исполнения, breakeven,
  минимальный капитал, кэп размера от глубины); агрегатор «строгий И»/«скоринг» с жёстким ядром
  У1+У10+У14; жизненный цикл сигнала (дожим, TTL, инвалидация, кулдаун, заморозка в блэкаут,
  ревалидация после рестарта); sizing с честными отказами; телеметрия pass-rate (сессия +
  суточные вёдра UTC); контракт сигнала §8.1 заморожен фикстурой. 60 новых тестов.
• [OTM-Scanner] Фундамент данных (фаза S0): клиент свечей (get_tradingview_chart_data) и
  delivery-цен (get_delivery_prices) с живой верификацией форм ответов; модуль реализованной
  волатильности (RV7d/RV3d, σ1d, импульс за 24ч, EMA20) по закрытым часовым барам; пресеты порогов
  SCAN_PRESETS («Дмитрий v1», «Дмитрий v2.0», «Калиброванный-черновик») с валидацией настроек;
  отбор инструментов-кандидатов в σ-окне и окне экспираций; сетевой смоук npm run smoke:scan.
• [BTC-Options] Расчёт на экспирации: дожившая до экспирации структура автоматически
  рассчитывается по внутренней стоимости на цене индекса (приближение расчётной цены Deribit,
  зафиксировано в примечании строки журнала), перпетуал выравнивается, в журнале - событие
  «расчёт на экспирации». Ранее позиция замирала: ноги исчезали из данных, гейт греков падал,
  а переоценка показывала ложный ноль.
• [BTC-Options] Метрики прогона переживают следующую сделку: при закрытии или расчёте структуры
  сводка завершённого прогона замораживается; экспорт JSON и XLSX содержит метрики текущего и
  последнего завершённого прогонов (CSV остается чистой таблицей событий).
• [BTC-Options] Строка «гейт греков не пройден» в тикете называет инструменты, по которым не
  хватает данных; полный список и детали ошибок - в подсказке при ...

v0.2.0

Первый публичный выпуск. Приложение переименовано в BotLab и получило поддержку обновлений «по воздуху».
После переименования автоматически переносится каталог userData, поэтому позиции, журнал и настройки сохраняются. Торговая логика и расчёты не изменились.

Добавлено

• Поддержка обновлений из GitHub Releases. В заголовке приложения появилась кнопка с текущей версией и статусом обновления. Обновление скачивается только по запросу пользователя, устанавливается в фоновом режиме и требует лишь перезапуска приложения. Проверка новых версий выполняется при запуске и затем каждые 6 часов.

• После успешного обновления страница релиза автоматически открывается в браузере один раз. Из меню версии также доступны пункты «Что нового» и «Показать журнал».
• Добавлена проверка целостности скачанных обновлений. Перед установкой SHA-512 сверяется с манифестом релиза. При несовпадении установка отменяется.
• Раздел Help переработан и разделён на модули. Добавлена новая статья «Обновления приложения». Обновлены автоматические проверки покрытия справки и состояний системы обновлений.
• Настроен релизный процесс в GitHub Actions. Тег vX.Y.Z запускает тесты, сборку, подпись, нотарификацию и создание черновика релиза. Публикация выполняется вручную после проверки.

Изменено

• Приложение переименовано из Funding-Arb Paper Simulator в BotLab. Идентификатор приложения изменён. Начиная с этого выпуска название приложения, идентификатор и Team ID считаются постоянными, чтобы обеспечить корректную работу системы обновлений и цифровой подписи.

Исправлено

• Исправлено отображение заметок к релизу в окне обновлений. Ранее GitHub возвращал описание в формате HTML, поэтому пользователи видели HTML-теги вместо обычного текста.
• Исправлен релизный конвейер GitHub Actions. Тесты теперь запускаются через node --test, что устраняет проблему на Windows Runner, где предыдущая команда ошибочно воспринимала каталог test/ как модуль.

Известные ограничения

• В этом выпуске доступна только версия для Windows. Поддержка macOS появится в следующих релизах.
• Windows-версия пока не имеет цифровой подписи. При первой установке SmartScreen может показать предупреждение. В следующих релизах приложение будет подписано.
• Пользователям версии 0.1.0 необходимо вручную установить BotLab 0.2.0 и затем удалить старую версию. При первом запуске BotLab автоматически перенесёт позиции, журнал и настройки. Старый каталог данных останется на диске до удаления предыдущего приложения, что позволит при необходимости выполнить откат.