Как подготовить торгового робота к распространению: от стратегии до пакета для пользователей в XTester

На вашем компьютере стратегия компилируется и проходит исторический тест. Теперь её нужно передать человеку, который не видел проект и не знает, какие настройки вы меняли вчера. Что ему отправить? Как объяснить первый запуск? И как убедиться, что в архив попал именно проверенный вариант?

В XTester Studio для этого предусмотрен мастер «Свой лаунчер (White Label)…». Он собирает отдельное приложение Launcher со стратегией, нужной средой исполнения и оформлением автора. Получатель открывает приложение конкретного робота. Редактор Studio для обычной работы с ним не требуется.

Дальше разберём подготовку такого выпуска: что зафиксировать до сборки, какие изменения разрешить пользователю и что проверить в готовом архиве. Описание возможностей опирается на справку XTester для 1.0.0-preview.1 с отметкой «Проверено: 2026-11-04». Описанные возможности сверены со справкой; конкретного робота для этой статьи мы не собирали и не запускали.

1. Выберите версию, которую действительно готовы передать

Представим обычную ситуацию: вы подготовили одну стратегию и хотите отдать её коллеге для знакомства. Начните с одного выбранного компьютера и одной конфигурации. Так проще увидеть, чего не хватает получателю, пока вы ещё не обещали поддержку нескольких систем.

Перед открытием мастера сохраните исходники, проверьте компиляцию и выполните бэктест. Сверьте инструмент, таймфрейм, параметры, начальные средства и профиль. Упаковка не проверяет качество торговой идеи.

К этому моменту полезно составить короткую запись о версии:

• какие правила реализованы и в каких файлах;
• на каких данных и за какой период выполнена проверка;
• какие параметры, издержки и условия моделирования использовались;
• какие ограничения и незавершённые проверки остаются.

Это сопровождение автор готовит сам. Не рассчитывайте, что мастер восстановит историю ваших решений по названию проекта.

Если нужна первая проверка самой установки, в справке есть учебный бэктест First Check. Его код обрабатывает бары и пишет журнал, но не отправляет заявки. Такой пример помогает проверить запуск и данные. Работу торговых правил собственного робота придётся проверять отдельно.

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

2. Решите, что пользователь сможет менять

В пакет можно включить выбранные профили запуска и назначить профиль по умолчанию. Он должен входить в этот набор. Для инструмента, таймфрейма и параметров предусмотрены три политики:

Политика	Что получает пользователь
Fixed, «Задано разработчиком»	Зафиксированное значение
Choice, «Выбор из списка»	Выбор из разрешённых вариантов
Editable, «Пользователь может изменять»	Редактирование с допустимыми границами там, где они заданы

Допустим, вы проверяли стратегию только для одного инструмента. Оставьте его фиксированным. Если хотите разрешить другой таймфрейм, сначала выясните, как с ним работает код, и укажите границу выполненной проверки. Само появление значения в списке ещё ничего не говорит о качестве результата.

Отдельно решите, может ли получатель создавать свои профили. Чем больше свободы вы даёте, тем яснее должно быть описание поддерживаемых конфигураций. Замок у поля объясняет ограничение интерфейса, но не заменяет эту договорённость.

Ограничения настроек также не делают исходный код закрытым. В текущем формате исходники стратегии входят в пакет.

В мастере выбирают профили и задают, какие значения сможет менять получатель. Скриншот из справки XTester 1.0.0-preview.1. Фрагмент; оригинал сохранён в приложенных материалах. Источник.

3. Добавьте оформление и проверьте, что вы раскрываете

Задайте имя робота, его версию, сведения о разработчике, логотип и HTTPS-ссылку на поддержку. Укажите собственный номер версии робота отдельно от версии Studio. По нему получатель и автор должны понимать, о каком наборе кода и настроек идёт речь.

Перед сборкой просмотрите исходники и дополнительные файлы. В них могут остаться вручную вписанный ключ, рабочий адрес сервиса или другие сведения, которые вы не собирались распространять. Секреты из защищённого хранилища не превращаются в ключи получателя, но это не скрывает секрет, который автор сам записал в открытый файл.

White Label меняет оформление приложения. Он не создаёт автоматически лицензионную защиту, закрытый код или доверенную цифровую подпись. Поле «Разработчик» задаёт только отображаемое имя. Сертификат издателя оформляется отдельно.

Есть и конкретная граница оформления: по текущей справке внешний значок macOS-пакета .app остаётся от XTester, хотя имя и сведения приложения меняются. Логотип внутри окна и значок приложения в системе нужно проверять отдельно.

4. Проверяйте результат каждой платформы

Выбор ОС и архитектуры в мастере означает запрос на сборку. Для каждой цели нужен подходящий полноценный шаблон Launcher. Успех одной платформы не подтверждает, что другая тоже готова.

После сборки откройте build-report.json. В нём указаны фактические пути и результат каждой цели. Общий индикатор завершения не заменяет эту проверку.

Для Windows создаётся ZIP, для macOS и Linux используется TAR.GZ. Передавать нужно весь готовый архив либо полный каталог приложения: рядом с роботом необходимы ресурсы и среда исполнения. Отдельного EXE или файла стратегии недостаточно. Для macOS важно сохранить содержимое, структуру .app и права файлов, для Linux также нужны исполняемые файлы и скрипт запуска.

Затем проверьте именно тот архив, который собираетесь отправить, на подходящей ОС и архитектуре. Полезно распаковать его в отдельное место и пройти путь получателя без привычной папки разработки.

Успешная сборка и доверие операционной системы к приложению проверяются отдельно. В частности, после переименования macOS-приложения требуется корректная новая подпись. Не обещайте отсутствие предупреждений ОС только потому, что мастер завершил работу. Для проверки упаковки реальная торговля не требуется.

Результат сборки учебного робота в справке XTester. Проверка запуска на целевой системе остаётся отдельным шагом. Фрагмент; оригинал сохранён в приложенных материалах. Источник.

5. Пройдите первое открытие глазами получателя

При первом открытии приложение проверяет пакет и готовит рабочую копию проекта в пользовательской папке. Если не хватает поддерживаемых инструментов или библиотек, оно показывает список и запрашивает установку. Восстановлению зависимостей могут понадобиться интернет и настроенный системный менеджер пакетов.

Отказ от установки или закрытие окна прерывает подготовку. Это не успешный запуск. Поэтому в инструкции человеку стоит заранее объяснить, где закончилась распаковка и где началась подготовка среды.

После неё применяется обычный сценарий Launcher с подтверждением режима. Paper работает с виртуальным счётом и публичными рыночными данными, поэтому доступный источник данных всё равно нужен. Для LIVE требуются собственное подходящее подключение получателя и отдельные проверки ключей, аккаунта и допуска. Порядок первого открытия описан в справке.

Собранный пакет не подтверждает готовность стратегии к реальному счёту. Проверка первого открытия также не доказывает будущую доходность или устойчивость исполнения.

6. Отправьте пакет вместе с короткой инструкцией

Пользователю должно хватать сопроводительного текста, чтобы понять, что он получил и с чего начать. Мы рекомендуем подготовить такую карточку вручную:

Что указать	На какой вопрос отвечает
Название и версия робота	Какой выпуск у меня сейчас?
ОС и архитектура	Этот архив подходит моему компьютеру?
Способ распаковки и запуска	Что открыть после загрузки?
Требуемые компоненты и данные	Что может понадобиться при подготовке?
Профиль по умолчанию и разрешённые изменения	С каких настроек начать и что можно менять?
Условия выполненных проверок	Что автор действительно проверил?
Известные ограничения и поддержка	Куда обратиться и что пока не обещано?

Её содержание зависит от вашего проекта и выполненных проверок.

Сохраните у себя отправленный архив, запись о версии и отчёт сборки. Если получатель сообщает об ошибке, попросите назвать версию робота, ОС и архитектуру, точный текст ошибки и этап: распаковка, подготовка зависимостей или выбор режима. Для разбора сборки пригодится build-report.json. Это даёт гораздо больше, чем переписка вокруг фразы «у меня не запускается».

7. Новую версию тоже нужно подготовить к передаче

После изменения кода заново проверьте профили, зависимости и исторический результат, затем соберите и проверьте новый пакет. В сопровождении объясните, что изменилось и какие проверки повторены.

Не рассчитывайте, что отдельно переименованное приложение автоматически будет распознано как обновление прежнего робота. Сохранение идентичности пакета имеет значение. Переименование приложения не меняет подключения и лимиты общего биржевого аккаунта.

Подробные действия в интерфейсе и ограничения отдельных платформ собраны в руководстве по упаковке робота. Начните с одного адресата и проверьте весь путь передачи на своей стратегии.

Материал посвящён подготовке приложения к распространению. Он не является инвестиционной рекомендацией. Исторический тест, Paper и успешная сборка не гарантируют прибыль и не исключают потери средств при реальной торговле.