2026-07-22#

Google Sheets access in Connections#

Google Connections can now request spreadsheet read/write access explicitly when an agent needs it. The additional permission is optional and is not added to ordinary Google sign-in connections by default.

2026-07-21#

Добавлены обзор платформы и единое рабочее пространство Агента#

• На сайте появились страницы /platform и /en/platform с понятным описанием архитектуры, событий, запусков и состояния программ.
• Карточка Агента теперь собрана в единое рабочее пространство: работа, сборка, запуски, развёртывания, показатели и настройки находятся рядом, а визуальные сценарии продолжают открываться в привычном редакторе.

Обновлена безопасность зависимостей веб-приложения#

• Обновлены библиотеки обработки YAML, очистки HTML и шаблонов путей. Проверка зависимостей теперь завершается без обнаруженных уязвимостей.

Обновлена безопасность серверных зависимостей#

• Обновлены библиотеки обработки HTTP-запросов, шаблонов путей и работы с базой данных. Проверка зависимостей теперь завершается без обнаруженных уязвимостей.

2026-07-20#

Telegram-роутер запускает отдельные процессы из рабочего чата#

• Добавлен импортируемый Telegram-роутер с настраиваемыми командами, алиасами и аргументами, а также примеры двух дочерних процессов: AI-помощника и сравнения сайтов.
• Бот показывает статус набора ответа, сохраняет ответы внутри исходной темы forum-чата и не запускает команду повторно после редактирования сообщения.
• Короткие адреса вроде ya.ru можно передавать без схемы, а обычные сообщения без обращения к боту остаются без реакции.

Готовые примеры Telegram-команд с упоминанием бота#

• Добавлены два импортируемых графа: простой бот с командами ping/help и рабочий роутер для сравнения сайтов и запроса отчёта.
• Обработчики запускаются только при явном @mention бота; обычная переписка и команды без обращения не влияют на процесс. Список команд, алиасы и аргументы настраиваются в самом графе.

Пустой For each корректно завершает запуск#

• Если входной список For each пуст, процесс теперь выполняет ноль итераций и успешно завершается без ошибочного запуска дочерних нод.
• Шаблоны текущего элемента больше не вычисляются вне контекста итерации.

2026-07-17#

Telegram-аккаунты работают как отдельный источник команд#

• В редакторе появились отдельные ноды для входящих сообщений обычного Telegram-аккаунта, текстового ответа и отправки документа.
• Аккаунт закрепляется за выбранным Runner-X, сохраняет непринятые события при перезапуске или временной недоступности платформы и не реагирует на свои же сообщения.
• Поддержаны команды /compare и /report, прямое подключение и Telegram- совместимые proxy; в интерфейсе раннеров видны состояние подключения и очереди доставки.

Команды из сообщений теперь настраиваются в процессе#

• Новая универсальная нода распознаёт команды из канонического события любого мессенджера: названия, алиасы и аргументы задаются прямо в редакторе процесса.
• Доступны типизированные URL, числа, флаги, списки значений, необязательные параметры и оставшийся текст; неизвестные команды могут вернуть автоматически сформированную подсказку.
• Входящие Telegram-сообщения приводятся к общему формату с упоминаниями, ответами, чатами и отправителями, а выполнение parser-ноды поддерживается на выбранном раннере.

Раннеры устойчивее восстанавливаются после задержек запуска#

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

Навигация по агентам и подключения стали нагляднее#

• Из карточки запуска теперь можно сразу вернуться к схеме связанного агента, а в меню агента появился быстрый переход к его детальной странице.
• Индикатор агента показывает публикацию в Test или Production и пульсирует, пока агент выполняет запуск; при переключении агентов схема автоматически центрируется.
• Подключения получили цветные иконки провайдеров, а создание собственных раннеров теперь явно помечено как возможность тарифа Enterprise.

Публикациями можно управлять прямо на схеме агента#

• Кнопка публикации показывает, активна ли выбранная версия в Test и Production, и позволяет отдельно снять публикацию в каждом режиме.
• В новой модалке доступен таймлайн публикаций с версиями, статусами и параметрами выкладки.
• Ручной запуск теперь доступен только для выбранной опубликованной версии и больше не запускает другую активную ревизию незаметно для пользователя.

Заголовок схемы агента стал компактнее#

• На канвасе теперь отображаются имя агента и номер открытой версии в чипе, окрашенном по результату валидации.
• Кнопка возврата к отдельному списку ревизий убрана из toolbar, поскольку история версий уже доступна прямо на канвасе.

PDF с удалённых раннеров можно отправлять в Telegram#

• Telegram-ноды теперь принимают PDF и другие файлы, сохранённые удалённым раннером, без повторного формирования отчёта.
• Файл передаётся в Telegram напрямую из защищённого хранилища по временной ссылке, а процесс продолжает выполняться на выбранном раннере.

2026-07-16#

Надёжное завершение выгрузки файлов с удалённых раннеров#

• PDF-отчёты и другие файлы теперь сохраняют проверочную сумму в файловом хранилище, поэтому система может подтвердить загрузку и продолжить процесс.
• Уже сформированный файл можно повторно выгрузить после обновления без повторного запуска тяжёлой ноды.

У JavaScript-нод теперь один понятный JSON-выход#

• Объект из return { ... } становится прямым выходом ноды без дополнительной обёртки result, поэтому следующие ноды используют обычные пути вроде report или routingPlan.
• Логи и технические метрики выполнения остаются в диагностике и больше не смешиваются с данными процесса.
• Уже опубликованные процессы со старыми путями result.* продолжают работать во время перехода на единый формат.

Полноэкранная схема агента#

• Агенты теперь открываются сразу в полноэкранном редакторе схемы; для нового агента нормально отображается пустой канвас без автоматического сохранения.
• Сохранение и публикация доступны в одном toolbar, а предупреждение защищает несохранённые изменения при уходе или переключении версии.
• Запуски и история версий открываются поверх канваса: можно фильтровать запуски, смотреть их полные детали и переходить между связанными запусками, не покидая схему.

Исправлена выгрузка файлов с удалённых раннеров#

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

Готовый PDF-отчёт по визуальному сравнению сайтов#

• Добавлен импортируемый процесс, который снимает две страницы через Microlink, сравнивает их vision-моделью и формирует PDF с итогом, метриками, предупреждениями и ссылками на исходные страницы и скриншоты.
• Готовый PDF можно сразу отправить в указанный Telegram-чат как документ, без промежуточной загрузки в публичное файловое хранилище.

AI-ноды поддерживают лимит ответа новых моделей OpenAI#

• AI-ноды автоматически используют совместимый параметр ограничения ответа для GPT-5 и reasoning-моделей OpenAI.
• Одинаковое поведение действует при центральном исполнении и на удалённых раннерах.

Исправлен запуск JavaScript-нод на удалённых раннерах#

• code.javascript.run больше не застревает в очереди при подготовке изолированного исполнителя.
• Раннер сверяет опубликованный код с защищённой ссылкой и передаёт исходник только зашифрованному исполнителю.

Раннеры поддерживают шаблон с полным входным payload#

• Шаблоны {{trigger}} и {{item}} теперь передают весь объект запуска или текущей итерации одинаково при центральном и удалённом исполнении.
• Поставляемые процессы с AI-нормализацией входного payload больше не требуют перечислять каждое поле вручную.

Ошибки внешних сервисов на раннерах стали диагностируемыми#

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

Обновление раннеров подтверждается до завершения деплоя#

• Деплой новой версии Runner-X завершается только после того, как работающий управляемый раннер подтвердит точный образ и здоровый исполнитель нод.

Исправлен запуск нод с секретами и пользовательским кодом на раннерах#

• Раннер корректно подготавливает изолированные временные файлы с секретами и кодом до запуска ноды, сохраняя их только в памяти контейнера.
• Процессы с AI, интеграциями и JavaScript больше не останавливаются на этапе подготовки исполнительных данных.

Процессы запускаются на выбранном раннере без ручного дублирования разрешений#

• При публикации процесса выбранный раннер автоматически получает доступ только к секретам, подключениям и сетевым адресам, объявленным в ревизии.
• Политики раннера теперь нужны лишь для явной блокировки или дополнительного сужения доступа. Доменные проверки также корректно проходят безопасные переходы к авторитетным RDAP-сервисам.

Подключения можно разрешать для управляемых раннеров#

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

2026-07-15#

Маршрутизация жалоб переведена на стандартную JavaScript-ноду#

• Убрана отдельная устаревшая нода выбора адресатов. Процессы защиты бренда теперь используют версионируемые правила и справочник провайдеров внутри стандартной JavaScript-ноды, поэтому маршрутизацию можно менять новой ревизией процесса без выпуска специального backend-компонента.

Подготовка пакета жалобы по защите бренда#

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

Все ноды 1С выполняются на выбранном Runner-X#

• Получение списка и объекта, создание и изменение данных через 1С OData теперь выполняются в изолированной капсуле выбранного Runner-X без скрытого переноса в облачный обработчик.
• Адрес публикации вычисляется до запуска и ограничивается точным HTTPS-доменом и методом операции. Логин и пароль выдаются только конкретному запуску и не попадают в команду, результат или журналы.
• Для on-premise 1С разрешены явно настроенные приватные сети, но localhost и служебные адреса узла остаются закрыты. План переноса завершён: все 184 ноды имеют явное место исполнения, control-plane fallback отсутствует.

Все 13 операций amoCRM выполняются на выбранном Runner-X#

• Получение, список, создание и изменение лидов, контактов, компаний, задач и воронок amoCRM теперь выполняются в изолированной капсуле выбранного Runner-X без скрытого переноса в облачный обработчик.
• Токен amoCRM выдаётся только конкретному запуску и не попадает в команду, результат или журналы. Сетевой доступ ограничен точным доменом аккаунта и методом операции: GET для чтения, PATCH для изменения и POST для создания.
• Повторяемые изменения безопасно восстанавливаются после сбоя, а неизвестный результат создания не вызывает вторую запись. Из текущего плана осталось перенести только четыре ноды 1С.

PostgreSQL, MySQL, MongoDB и Redis выполняются на выбранном Runner-X#

• Ноды чтения и записи для PostgreSQL, MySQL, MongoDB и Redis теперь обращаются к базе из изолированного окружения выбранного Runner-X без скрытого переноса исполнения в облачный обработчик.
• Строка подключения выдаётся только конкретному запуску и не попадает в команду, результат или журналы. Доступ ограничен точным типом базы, адресами, портами и разрешённой операцией чтения либо записи.
• Приватные адреса локальной сети доступны для on-premise баз, но localhost, служебные адреса узла и попытки подменить маршрут завершаются явной ошибкой без control-plane fallback.

SQLite-запросы выполняются на локальной базе выбранного Runner-X#

• Ноды чтения и записи SQLite теперь выполняются в изолированной капсуле выбранного Runner-X без скрытого переноса в облачный обработчик.
• Путь к базе выдаётся только конкретному запуску и не попадает в команду, результат или журналы. Раннер подключает только отдельный каталог этой базы: для чтения — без права записи, для записи — с явно разрешённой записью.
• Выход за настроенный каталог, символьные ссылки, подключение второй базы и запись в произвольный файл завершаются явной ошибкой без control-plane fallback.

Workflow-письма и универсальные сообщения выполняются на выбранном Runner-X#

• Ноды email.send и message.send теперь обращаются к настроенному HTTPS сервису доставки из изолированной капсулы выбранного Runner-X без скрытого переноса отправки в облачный обработчик.
• Сетевой доступ ограничен точным разрешённым адресом и методом POST. Токен сервиса выдаётся только конкретному запуску и не попадает в результат или журналы.
• Статус универсального сообщения сохраняется централизованно и повторяемо, но сама отправка выполняется только на Runner-X. Неизвестный результат не приводит к повторной отправке.

ClickHouse-запросы выполняются на выбранном Runner-X#

• Ноды чтения и записи ClickHouse теперь обращаются к базе из изолированной капсулы выбранного Runner-X без скрытого переноса исполнения в облако.
• Строка подключения выдаётся только конкретному запуску и не попадает в результат. Сетевой доступ ограничен точным HTTP(S)-адресом ClickHouse, разрешённым в настройках исходящего трафика.
• Чтение принудительно остаётся read-only, а неподдерживаемый или приватный адрес завершается явной ошибкой без control-plane fallback.

Доменная разведка выполняется в регионе выбранного Runner-X#

• WHOIS/RDAP, DNS, IP/ASN, определение хостинга и CDN теперь исполняются через изолированную капсулу выбранного Runner-X без скрытого переноса в облако.
• DNS-запросы идут через защищённый DNS-over-HTTPS канал, а доступ к RDAP и внешним resolver'ам ограничен настройками исходящего трафика Runner-X.
• Неподдерживаемый DNS resolver завершается явной ошибкой без fallback.

AI-агент выполняет весь цикл и выбранные действия на Runner-X#

• OpenAI-агент теперь принимает решения и вызывает разрешённые интеграции в регионе выбранного Runner-X без скрытого переноса исполнения в облако.
• Каждое действие отдельно проходит действующие политики, согласования и защиту от повторного выполнения. Ключи подключений остаются внутри изолированного запуска и не попадают в результаты или журналы.
• Неподдерживаемое действие завершается явной ошибкой без control-plane fallback. На этом перенос всех верхнеуровневых AI-нод завершён.

RAG-ответы выполняются через выбранный Runner-X без скрытого fallback#

• Построение эмбеддинга и генерация итогового ответа теперь обращаются к OpenAI непосредственно из региона выбранного Runner-X.
• Поиск подходящих фрагментов остаётся в центральной векторной базе, но доступ к нему разрешён только подписанному активному запуску и не переносит AI-исполнение в облачный обработчик.
• Результаты поиска повторно проверяются по пространству, коллекции, модели и размерности. Ключ провайдера не попадает в API, результат или журналы.

Генерация изображений и работа с речью выполняются на выбранном раннере#

• Генерация изображений, синтез речи и распознавание аудио через OpenAI теперь выполняются непосредственно на выбранном Runner-X без скрытого переноса в облачный исполнитель.
• Изображения и аудио сохраняются как файловые артефакты: большие base64-данные не попадают в результат шага или журналы, а повторные ссылки на один файл не создают лишних загрузок.
• Для распознавания раннер получает доступ только к разрешённому адресу аудио и API провайдера. Ключ подключения выдаётся конкретному запуску и не попадает в результат.

Потоковая AI-генерация и создание видео выполняются на выбранном раннере#

• Потоковая генерация через OpenAI или YandexGPT теперь полностью обращается к провайдеру из региона выбранного Runner-X и сохраняет итоговый текст и расход токенов без скрытого переноса исполнения в облачный обработчик.
• Создание видео через OpenAI Sora, Google Vertex Veo и BytePlus Seedance запускает задачу провайдера на выбранном раннере и возвращает её статус и идентификатор. Региональные адреса берутся только из разрешённого подключения, а сетевой доступ ограничивается точными адресами провайдера.
• Ключи выдаются только конкретному запуску и не попадают в результат или журналы. Если подключение или сетевой адрес не разрешены, нода завершается ошибкой без control-plane fallback.

AI-чат, эмбеддинги и векторный поиск выполняются на выбранном раннере#

• AI-чат, создание эмбеддингов и подготовка запроса для векторного поиска теперь обращаются к модели непосредственно из региона выбранного Runner-X.
• История чата и векторные данные сохраняются централизованно и повторяемо, но обращения к AI-провайдеру не переносятся в облачный исполнитель.
• Доступ к OpenAI, YandexGPT или GigaChat выдаётся только конкретному запуску, а сеть ограничивается адресами выбранного провайдера. Без разрешённого подключения нода завершается ошибкой.

AI-модерация и анализ изображений выполняются на выбранном раннере#

• Проверка текста на нарушения и анализ изображений теперь могут обращаться к модели непосредственно из региона выбранного Runner-X.
• Для анализа можно использовать как URL, так и изображения пространства: доступ к файлу выдаётся только конкретному запуску на короткое время, а сеть ограничивается разрешёнными адресами OpenAI или GigaChat и источника изображения.
• Если подключение, файл или сетевой адрес не разрешены, нода завершится ошибкой и не перенесёт запрос скрыто в облачный исполнитель.

Текстовые AI-ноды выполняются на выбранном раннере#

• Генерация, классификация, извлечение данных и перевод теперь могут обращаться к модели непосредственно из региона выбранного Runner-X.
• Поддержаны собственные подключения OpenAI, YandexGPT и GigaChat. Ключ выдаётся только конкретному запуску, а сеть ограничена API выбранного провайдера.
• Если разрешённого подключения нет, нода завершится ошибкой и не перенесёт запрос скрыто в облачный исполнитель.

Slack, МойСклад и отправка жалоб выполняются на выбранном раннере#

• Сообщения Slack, создание заказов покупателей в МойСклад и отправка подготовленных жалоб теперь выполняются на выбранном удалённом раннере.
• Доступ к Slack, МойСклад или секрету сервиса доставки выдаётся только конкретному запуску, а сетевое соединение ограничено API и методом операции. Для доставки жалоб разрешается только заранее указанный адрес из политики раннера.
• При неизвестном результате операция не отправляется повторно, поэтому сбой не приводит к дублированию сообщения, заказа или жалобы. Скрытого возврата к облачному исполнителю нет.

Запись в SaaS-сервисы выполняется на выбранном раннере#

• Создание записей Airtable и страниц Notion, изменения Google Таблиц и Календаря, задачи GitHub и Яндекс Трекера, а также сообщения Avito теперь выполняются на выбранном удалённом раннере.
• Доступ к подключению или секрету выдаётся только конкретному запуску, а сетевое соединение ограничено API и методом нужной операции.
• Повторяемые изменения можно безопасно восстановить после сбоя. Для операций создания и отправки неизвестный результат не приводит к повторному внешнему действию; скрытого возврата к облачному исполнителю нет.

Отправка сообщений и платежные операции выполняются на выбранном раннере#

• Операции MAX, TBank, Telegram, Topvisor, VK, VK Teams, ЮKassa и Zadarma из текущего набора провайдеров теперь выполняются на выбранном удалённом раннере. Секрет и сетевой доступ выдаются только конкретному запуску и разрешённому API.
• Повторяемые операции используют ключ провайдера. Для остальных после начала внешнего вызова повторная отправка запрещена: раннер доставляет сохранённый результат, а неизвестный исход показывает отдельную ошибку вместо риска второго сообщения, платежа, возврата или звонка.
• Скрытого возврата к облачному исполнителю нет; неподдерживаемые ноды остаются закрытыми до появления проверенного executor pack.

Повторяемые изменения у провайдеров выполняются на выбранном раннере#

• Безопасные для повторного запуска операции Airtable, Notion, TBank, Telegram, Google Таблиц и Google Календаря теперь могут выполняться на выбранном удалённом раннере. Доступ к секретам и Google-связям выдаётся только конкретному запуску, а сеть ограничена API и методом операции.
• Политики, согласования, защита от повторов, аудит и учёт использования остаются в едином управляющем контуре. Операции отправки и создания, для которых повтор может вызвать второй внешний эффект, по-прежнему закрыты и не возвращаются скрыто к облачному исполнителю.

Чтение Airtable, Notion и маркетплейсов выполняется на выбранном раннере#

• Ноды чтения Airtable, Notion, Ozon, Wildberries и документов Диадок теперь могут выполняться на выбранном удалённом раннере. Секрет передаётся только конкретному запуску, а сетевой доступ ограничен API и методом нужного провайдера.
• Проверки политик, согласования, защита от повторов, аудит и учёт использования остаются в едином управляющем контуре; скрытого возврата к облачному исполнителю нет.

Отчёты Yandex Webmaster выполняются на выбранном раннере#

• Все ноды чтения и аналитических запросов Yandex Webmaster теперь могут выполняться на выбранном удалённом раннере. Доступ к Yandex выдаётся только конкретному запуску, а сетевое соединение ограничено API Webmaster и необходимым методом запроса.
• Проверки политик, согласования, защита от повторов, аудит и учёт использования сохраняются в едином управляющем контуре; скрытого возврата к облачному исполнителю нет.

Google Таблицы и Календарь читаются на выбранном раннере#

• Ноды чтения Google Sheets и событий Google Calendar теперь могут выполняться на выбранном удалённом раннере. Доступ к Google передаётся только для конкретного запуска и конкретной связи, а сетевой доступ ограничен API чтения Google.
• Ноды записи Google пока остаются недоступны для удалённого выполнения и не возвращаются скрыто в облачный исполнитель.

Проверки статуса платежей выполняются на выбранном раннере#

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

Удалён скрытый возврат выполнения с раннера в облако#

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

Шаблоны процессов одинаково работают на локальных и удалённых исполнителях#

• Исправили передачу результатов предыдущих шагов удалённым исполнителям: ссылки вида {{node_id.field}} теперь получают тот же контекст, что и при центральном выполнении, включая графы с несколькими ветками.

• Обновили OpenAI-каталог в AI-нодах: добавили семейство GPT-5.6, перевели генерацию изображений на GPT Image 2 и убрали снятые OpenAI DALL·E 3 и старую text moderation модель. Существующие текстовые процессы сохраняют выбранные модели без автоматической миграции.

Раннеры снова можно выбирать при публикации#

• Исправлен список целей выполнения: активный раннер теперь выбирается кликом при публикации ревизии.

Архивированные раннеры больше не остаются в списках#

• После вывода из эксплуатации последнего облачного раннера его общий пул исчезает из пространств пользователей. Новый раннер того же пула возвращает его без дублирования записей.

2026-07-14#

Агентов теперь можно архивировать из бокового меню#

• Действие в меню агента стало безопасным: агент исчезает из навигации, но его процессы, запуски, KPI и отчёты сохраняются.

Общие раннеры доступны во всех пространствах#

• Общие облачные раннеры теперь автоматически появляются во всех текущих и новых пространствах, а выведенные из эксплуатации больше не засоряют список.

Улучшена русская локализация новых полей#

• Новые настройки формата HTTP-ответа и путей изображений в PDF теперь отображаются с русскими подписями.

Две картинки в одном PDF#

• Добавлен готовый мини-процесс, который принимает две ссылки на PNG/JPEG, скачивает изображения и собирает единый PDF — по одной картинке на страницу.

2026-07-13#

Повышена стабильность удалённых раннеров#

• Устранено накопление служебных ресурсов у раннера во время ожидания новых шагов.

Исправлена стабильность запуска процессов#

• Процессы без удалённого раннера снова корректно начинают выполнение после запуска.

Исправлены фильтры по элементам массивов#

• Условия процессов теперь корректно проверяют значения по путям с индексом массива, например наличие первой DNS A-записи. Ветвление после таких фильтров больше не пропускает ожидаемую ветку.

2026-07-10#

• В ai.image.analyze поля URL изображений и SpaceAsset ID стали многострочными: одно изображение указывается на строку, порядок сохраняется.

• ai.image.analyze теперь умеет сравнивать несколько изображений через подключение GigaChat. Отдельная нода визуального сравнения удалена: такие сценарии собираются прозрачным графом из захвата изображений, vision-анализа и нормализации результата.

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

• Исправлен результат HTTP-ноды: сохранённое тело ответа теперь доступно следующим шагам как output.body по умолчанию, в том числе в уже созданных процессах без явно заданного ключа результата.

• В редакторе появилась отдельная группа «Поисковые системы»: serp.capture теперь выполняет самостоятельные поисковые запросы и возвращает нормализованную выдачу без привязки к конкретному бизнес-сценарию.

• В редакторе появилась нода «Вызвать процесс»: она позволяет переиспользовать уже опубликованный процесс текущего пространства, дождаться его завершения и продолжить основной граф с полученными результатами.

• Добавлен отдельный импортируемый процесс для визуального сравнения подозрительной и официальной веб-страниц с объяснимыми сигналами и рекомендацией ручной проверки пограничных результатов.

2026-07-09#

Браузерные ноды в палитре#

• В канвасе появилась категория «Браузер».
• Нода web.screenshot.capture теперь доступна в списке нод для сборки процессов.

Удобнее HTTP-запросы к внешним API#

• В external.http появились query-параметры без ручной склейки URL.
• Ответ внешнего API теперь можно положить в отдельный output key и использовать в следующих нодах.

2026-07-08#

Больше data-нод на удалённых раннерах#

Удалённые раннеры теперь поддерживают чистые data-shaping ноды для массивов и table envelope: data.array.reduce, data.table.build, data.table.select, data.table.pivot и data.table.concat.

Fan-out на удалённых раннерах#

Удалённые раннеры теперь поддерживают control.foreach в central-step режиме. Раннер возвращает тот же fanOut envelope, а control plane по-прежнему отвечает за создание downstream steps, join, traces и billing.

Рендер отчётов на удалённых раннерах#

Удалённые раннеры теперь поддерживают non-PDF report render ноды: report.table.render, report.chart.render, report.compose и report.export.

SEO-трансформации на удалённых раннерах#

Удалённые раннеры теперь поддерживают pure transform ноды seo.yandex_webmaster.query_report.rows и topvisor.report.metrics для обработки уже полученных provider snapshots.

Legacy trigger leases выключены по умолчанию#

Control plane больше не принимает /runner/triggers/leases/renew без явного legacy-флага REMOTE_RUNNER_LEGACY_TRIGGER_LEASES_ENABLED=true. Production cron execution должен идти через singleton control-plane scheduler и /runner/steps/*.

Legacy local-state heartbeat выключен по умолчанию#

API больше не сохраняет heartbeat-поля localCron, localRuns и localRunReports от удалённых раннеров без явного флага REMOTE_RUNNER_LEGACY_LOCAL_STATE_ENABLED=true. Для production runner pools ожидаемый путь остаётся central-step execution через /runner/steps/*.

Cron fire idempotency lookup#

Control plane теперь переиспользует уже созданный cron run для того же deployment, trigger node и scheduledAt. База дополнительно защищает этот ключ partial unique index-ом на runs, а insert race возвращается к уже созданному run без повторного startRun.

Cutover-check для managed runner migration#

Добавлена операторская команда runner:migration:cutover-check: она проверяет, что active prod deployments без targetId больше нет, а remote-only env-флаги выставлены явно перед отключением local API workers.

Cron scheduler fire locks#

Control plane теперь пишет durable lock на каждый cron tick перед созданием и стартом run. Если несколько scheduler-capable API replicas сработают на один cron fire, side effects выполнит только первая. CRON_SCHEDULER_INSTANCE_ID задаёт owner id этой singleton scheduler роли в логах и durable locks.

Аудит legacy runner config#

Добавлена команда npm run runner:legacy-config:audit: она проверяет API и runner env на включённые legacy runner-local graph/import флаги перед remote-only rollout.

У команды появился режим --remote-only, который дополнительно проверяет hard rollout env: local API step workers выключены, execution target обязателен, а local execution скрыт из app build.

Legacy imported runs скрыты из дефолтного списка#

/runs теперь по умолчанию показывает control-plane runs. Старые imported local-run rows доступны через source=remote_runner_imported или временный флаг REMOTE_RUNNER_LEGACY_IMPORTED_RUNS_VISIBLE=true.

Legacy local-run reporting требует явного флага#

Удалённый раннер больше не начинает импорт локальных graph runs только из-за legacy cron или interval-настройки. Для старого /runner/local-runs/report нужен явный OPORA_RUNNER_LEGACY_LOCAL_RUN_REPORTS_ENABLED=true; managed runner шаблоны держат этот режим выключенным.

Legacy runner-local endpoints помечены deprecated#

В OpenAPI /runner/local-runs/report и /runner/triggers/leases/renew помечены как deprecated compatibility endpoints. Новый production-путь для раннеров остаётся /runner/steps/*.

Legacy-импорт локальных запусков выключен по умолчанию#

Control plane больше не принимает /runner/local-runs/report без явного legacy-флага REMOTE_RUNNER_LEGACY_LOCAL_RUN_REPORTS_ENABLED=true. Обычные production-пулы раннеров должны работать через canonical runs и /runner/steps/*.

Первый батч gateway-нод на удалённых раннерах#

Удалённые раннеры теперь могут забирать часть AI/message gateway-нод и передавать их на исполнение существующему control plane contract без отдельного edge gateway: ai.generate, ai.classify, ai.extract, ai.translate, ai.moderate, message.send и telegram.message.send.

Публикация в нужный регион выполнения#

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

2026-07-03#

• Зафиксировали план появления кнопки обновления образа удалённого раннера: сначала image catalog, затем UI intent для update/rollback, затем отдельный host-side updater на VM, который реально подтянет образ и перезапустит контейнер с rollback при проблемах.

• EN: Documented the plan for the remote runner image update button: image catalog first, then UI update/rollback intent, then a separate VM host-side updater that pulls the image, restarts the container and rolls back on failure.

• У раннеров появилась политика образа на уровне конкретного target: promoted image, pinned digest или customer mirror. Pinned digest уже влияет на выдачу pull credentials и диагностику, поэтому отдельный раннер можно зафиксировать на конкретном digest без смены глобального promoted image.

• EN: Runners now have target-level image policy: promoted image, pinned digest or customer mirror. Pinned digest already affects pull credentials and diagnostics, so one runner can be locked to a specific digest without moving the global promoted image.

• На странице раннеров появился первый слой fleet readiness: регион, провайдер, теги, stale heartbeat, sync issues и cached bundle теперь видны прямо в таблице, а не только в diagnostics.

• EN: The Runners page now has the first fleet readiness layer: region, provider, tags, stale heartbeat, sync issues and cached bundle status are visible directly in the fleet table.

• В истории запусков теперь проще отделить обычные запуски от автономных запусков, которые были выполнены удалённым раннером и затем синхронизированы обратно в SUMMING. В деталях такого запуска видно, с какого target/worker он пришёл.

• EN: Run history now makes synchronized autonomous remote-runner runs easier to identify. Operators can filter them separately and see the target/worker origin on the run details page.

• История автономных запусков удалённого раннера стала понятнее: после синхронизации у импортированного запуска появляются timeline-события по старту, шагам, завершению и факту импорта.

• EN: Autonomous remote runner history is easier to inspect: synchronized imported runs now include timeline events for start, steps, completion and the import marker.

• Нода web.screenshot.capture теперь является единственной универсальной нодой для скриншотов страниц и возвращает нейтральный результат web.screenshot, без привязки к отдельному процессу защиты бренда.

• Автономные запуски удалённого раннера после синхронизации теперь попадают в обычную историю запусков и шагов. Это первый слой reconciliation: запуск виден как canonical run, а audit/billing будут добавляться отдельно.

• EN: Autonomous remote runner runs now appear in the regular run and step history after synchronization. This is the first reconciliation layer; audit and billing links will be added separately.

• В списке удалённых раннеров теперь сразу видно статус образа: актуален, устарел, custom override или неизвестно. Поиск по раннерам также учитывает image ref, канал, digest, версию и commit SHA.

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

• В диагностике удалённого раннера появился статус закешированного образа: теперь видно, какой образ раннер видит на VM и из какого cache-файла он был прочитан.

• Удалённый раннер теперь получает вместе с учётными данными для скачивания образа структурные данные о канале, digest, версии и commit SHA. Это первый шаг к управляемым обновлениям и откатам парка раннеров.

• Локальное исполнение удалённого раннера теперь умеет подставлять данные из предыдущих узлов графа в шаблоны, например {{check_api_health.status}}, при автономном запуске пакета графа.

2026-07-02#

HTTP-ноды#

• В external.http добавлен режим сохранения response body: полный body можно оставить как раньше, не сохранять вовсе или сохранять только первые байты. Это полезно для частых healthcheck-графов, где нужны статус и headers, но не повторяющийся HTML на десятки килобайт каждые 15 минут.

Раннеры#

• Колонка Capabilities в списке раннеров стала компактной: длинные списки теперь показываются в одну строку с ellipsis, а полный список доступен в tooltip при наведении или фокусе.

• Self-hosted runner стал устойчивее к большим локальным отчётам: крупные результаты шагов сохраняются локально на VM раннера как artifact-файлы, а в SUMMING отправляется компактная ссылка/сводка. Это должно убрать 500 на flush local-run reports после автономного запуска графа без потери локальных данных раннера; старые artifact-файлы удаляются вместе с вытесненными локальными run-записями.

• Исправлен systemd-шаблон для VM bootstrap: параметры restart limit перенесены в корректную секцию unit-файла, чтобы systemctl status opora-runner не ругался на StartLimitIntervalSec.

• В списке раннеров добавлено переименование: теперь можно быстро изменить отображаемое имя self-hosted runner без пересоздания токена или переустановки раннера.

Self-hosted runner: fan-out графы#

• Отчёты self-hosted runner о локальных fan-out запусках теперь сохраняют детали итераций, чтобы после восстановления связи было проще понять, какие элементы обработались и где была проблема.

• Self-hosted runner стал ближе к полноценному автономному исполнению графов: локальные запуски теперь поддерживают fan-out/foreach ветки и собирают результаты итераций в join-узле.

2026-07-01#

• Cloud-init для self-hosted runner теперь тоже использует собственный runner registry: VM получает временные pull credentials у SUMMING, скачивает image и умеет перезапуститься с cached image, если control plane временно недоступен.

• Команда установки self-hosted runner в UI больше не тянет образ из GHCR: она получает временные pull credentials у SUMMING и запускает image из собственного runner registry.

• Для self-hosted runner image подготовлена безопасная выдача временных pull credentials через SUMMING: GHCR остаётся внутренним каналом, а внешний registry используется только для runner.

• На странице раннеров появился diagnostics dialog: можно проверить heartbeat, sync bundles, outbox, local cron, local runs и ошибки self-hosted VM runner прямо из UI.

• Команда установки self-hosted runner в UI стала практичнее для VM: она сразу создаёт durable state, подключает локальный secrets.json и запускает контейнер с базовыми Docker-ограничениями.

• На странице раннеров появилась видимость автономных запусков: можно увидеть, сколько локальных run reports от self-hosted VM было принято, сохранено или отклонено после восстановления связи с SUMMING.

• Удалённый self-hosted runner стал автономнее: локальные завершённые запуски теперь могут быть переданы обратно в SUMMING после восстановления связи с сервером.

• Registry для self-hosted runner образов будет использовать существующий домен registry.summing.org, без отдельной новой доменной зоны на старте.

• Подготовили первый простой вариант собственного registry для self-hosted runner images: registry.summing.org можно поднять как отдельный production profile на S3-compatible storage.

• Удалённый self-hosted runner теперь ближе к автономному режиму: локальные cron-запуски включены по умолчанию для durable runner, условия и простые развилки графа исполняются локально, а отключённые ветки корректно пропускаются.

• Удалённый runner получил первый режим локального запуска графа: cron-trigger может выполняться на self-hosted VM из cached deployment bundle, с локальным durable журналом запусков.

• Удалённый runner стал устойчивее к повторам после рестарта: локально выполненные шаги фиксируются в durable execution journal и не запускаются повторно для той же попытки.

• Для self-hosted runner подготовили официальный Docker-образ и обновили команду установки: новые runner-хосты смогут брать готовый образ из registry, а не собирать его вручную.
• В настройках раннеров появилась управляемая policy для control-plane secret pull: можно включить выдачу секретов удалённому раннеру и ограничить её по node key, secret ref и имени секрета без ручного редактирования metadata.
• Зафиксировали локальные требования frontend-сборки: Vite/Rolldown теперь явно ожидает совместимую версию Node и одинаковую архитектуру Node и app/node_modules.
• Удалённый runner стал понятнее вести себя при недоступном control plane: уходит в degraded/backoff, не подменяет результат выполненного шага ложным fail-репортом и умеет держать control-plane secrets в in-memory TTL cache с очисткой через SIGHUP.
• Удалённый runner начал синхронизировать назначенные deployment bundle'ы: скачивает весь immutable graph bundle в память, ack'ает activation и готовит основу для будущего исполнения/secret prefetch на уровне всего графа.
• Для удалённого runner добавлен opt-in prefetch секретов всего графа: при включении раннер может прогреть in-memory cache секретами из текущего deployment bundle, при этом сервер проверяет bundle digest и policy target'а.
• Удалённый runner начал репортить состояние через heartbeat: какие deployment bundle'ы загружены, какие digest/runtime активны, сколько секретов prefetched и есть ли последние ошибки sync/prefetch.
• Удалённый runner начал исполнять шаги через локально загруженный graph bundle: перед запуском он сверяет deployment digest/runtime и node identity, а при отсутствующем или устаревшем bundle fail-closed вместо исполнения случайной конфигурации из claim response.
• Удалённый runner получил durable state directory: последние synced graph bundle'ы сохраняются на диске VM и поднимаются после рестарта или долгой недоступности control plane.
• Удалённый runner получил durable report outbox: если локально выполненный шаг не смог отправить complete/fail, report сохраняется на диске VM и ретраится без повторного исполнения шага.

2026-06-29#

Секреты удалённого раннера закрыты policy-gate#

• Control-plane выдаёт секреты self-hosted runner-у только если deployment target явно разрешил это в metadata policy. Можно ограничить доступ по типам node, ref-именам и backing secret names.

Удалённый раннер может получать секреты во время исполнения#

• Self-hosted runner теперь может запрашивать объявленные секреты у основного сервера во время выполнения шага, не сохраняя plaintext-секреты в bundle ревизии.

Удалённый раннер получил локальные секреты для HTTP#

• Self-hosted runner теперь может выполнять HTTP-шаги с локально настроенными секретами и шаблонами входных данных, не получая plaintext-секреты в bundle ревизии.

Удалённый раннер начал исполнять HTTP локально#

• Первый узкий срез MVP-4: remote runner теперь может выполнить простой external.http запрос из своей сети, чтобы обращаться к ресурсам, доступным только из инфраструктуры target.
• Секреты, OAuth connections, egress proxy и шаблоны пока намеренно не передаются на runner: такие шаги завершаются понятной ошибкой до появления runner-local auth.

Добавлен первый экран раннеров#

• В workspace появился раздел для удалённых раннеров исполнения: можно смотреть execution targets, создавать self-hosted runner и выбирать target при публикации ревизии.

Исправлен вход в Chrome#

• Исправили проблему автозаполнения Chrome на странице входа: отправка OTP и вход по паролю снова работают корректно при сохранённых учётных данных.

Браузерные ноды#

• Добавлена универсальная нода web.screenshot.capture для снятия скриншотов страниц через внешний browser capture service.
• Нода возвращает общий результат web.screenshot, поэтому её можно использовать не только в защите бренда, но и в QA, мониторинге и отчетах.

2026-06-28#

Единая основа для сайта и приложения#

• У сайта и приложения появилась общая основа для публичных адресов, API URL и профиля пользователя. Это помогает держать summing.org и summing.org/app/ одной продуктовой поверхностью без объединения проектов.

Сайт узнаёт вошедшего пользователя#

• На публичном сайте кнопка входа теперь может показывать имя уже вошедшего пользователя и вести сразу в приложение на summing.org/app/.
• Для гостей сайт остаётся прежним: статическая страница быстро открывается и показывает обычную кнопку начала работы.

Приложение переезжает на основной домен#

• Начали перенос приложения на summing.org/app/: публичный сайт остается статическим, а старый app.summing.org становится совместимым переходом на новый адрес.
• Обновили ссылки с лендинга, документации и писем входа так, чтобы они вели на новый путь приложения.

2026-06-27#

Удобнее работа с JSON#

• Обновили JSON-поля в настройках нод: теперь структуру можно просматривать и редактировать как дерево, а при необходимости переключаться в raw JSON.
• JSON-вывод в деталях запусков и других экранах стал более удобным для чтения больших вложенных объектов.

Защита входящих вебхуков#

• Добавили настройки защиты для webhook-триггеров: лимиты по IP или по всему endpoint'у и honeypot-поле для публичных форм.
• Для форм можно принимать подозрительные запросы без запуска процесса, чтобы не тратить квоты и не провоцировать повторные отправки.

Безопаснее вход и восстановление доступа#

• Усилили защиту паролей и восстановления доступа: старые сессии теперь аккуратно отзываются после смены или сброса пароля.
• Добавили дополнительные лимиты на повторные попытки входа и восстановления, чтобы лучше защищать рабочие пространства от перебора.

Открытая история обновлений#

• Добавили публичную страницу «Что нового» на сайте SUMMING.
• Подготовили публикацию коротких публичных обновлений в Telegram после успешных релизов.