@retensy/mcp 0.20.0 → 0.21.1

package/skills/build-bot-funnel/reference/schema.md

@@ -1,479 +1,483 @@
-# Формат графа `retensy-bot-graph`
-
-## Контейнер импорта
-```json
-{
-  "format": "retensy-bot-graph",
-  "version": 1,
-  "name": "Название воронки",
-  "nodes": [ /* TgNode[] */ ],
-  "edges": [ /* TgEdge[] */ ],
-  "canvasMeta": {}
-}
-```
-При заливке через MCP в `update_graph` передаются только `nodes`, `edges`, `canvasMeta`, `name`.
-
-## Узел (TgNode)
-```json
-{ "id": "<uuid>", "type": "<NodeType>", "config": { ... }, "position": { "x": 0, "y": 0 } }
-```
-- `id` — валидный UUID (8-4-4-4-12), уникальный.
-- `position` — раскладка на холсте (слева направо: шаг x ≈ 420; ветки разносим по y).
-
-## Ребро (TgEdge) — «стрелка»
-```json
-{ "id": "<uuid>", "sourceNodeId": "<uuid>", "sourceHandle": "next", "targetNodeId": "<uuid>" }
-```
-`sourceHandle` — какой выход узла используется (см. ниже).
-- `id`, `sourceNodeId`, `targetNodeId` — **валидные UUID** (бэкенд десериализует их как `java.util.UUID`; короткая строка вроде `"m1"` → HTTP 400 при заливке). `id` уникален среди рёбер.
-
-## Типы узлов (NodeType) и их config
-
-### Триггеры (точки входа, корневые)
-
-#### Telegram / MAX
-- `TRIGGER_COMMAND` — `{ "isRoot": true, "command": "start" }` (команда без `/`). Первый — с `isRoot:true`.
-- `TRIGGER_CALLBACK` — `{ "matchMode": "EQUALS"|"STARTS_WITH", "value": "<callback_data>" }`
-- `TRIGGER_TEXT` — `{ "matchMode": "ANY"|"EQUALS"|"CONTAINS"|"REGEX", "value": "..." }`
-- `BROADCAST_FILTER` — режим рассылки (если есть — единственный триггер).
-- `TRIGGER_PAYMENT` («Оплата прошла») — в кассе владельца прошла оплата: ЮKassa или подключённые через
-  `connect_integration` CloudPayments, Robokassa, Т-Банк, Prodamus, bePaid (подтверждённая оплата этих касс
-  нормализуется к тому же виду).
-  `{ "minAmount": "1000", "descriptionContains": "курс" }` — оба фильтра необязательны.
-  **Ставь хотя бы один фильтр:** без них сценарий будет запускаться на КАЖДУЮ оплату в кассе.
-  В контексте: `{{payment.id}}`, `{{payment.amount}}`, `{{payment.status}}`,
-  `{{payment.description}}`, `{{payment.currency}}`, `{{payment.provider}}` (какая касса), плюс весь документ платежа
-  как `body`.
-  Запуск — один раз на платёж: повторные уведомления кассы о той же оплате сценарий не перезапускают. Сюда же приходит оплата счёта, пришедшая уже после `timeout` блока со счётом, — в диалоге того подписчика (пока бот выключен, оплата ждёт повтора ЮKassa).
-  - **Счёт выставлял бот** (действие `issue_invoice`) → подписчик определяется САМ: счёт
-    помнит его в `metadata` платежа. Прогон идёт в обычной сессии — можно прямо ставить
-    «Отправить сообщение» и «Добавить метку», указывать получателя и разбирать ответ кассы
-    не нужно. Это штатный способ «оплатил → выдать доступ», когда ждать в сценарии не хочется.
-  - **Оплата мимо бота** (ссылка из рассылки, счёт из кабинета ЮKassa) → получателя нет,
-    прогон headless: узлы отправки адресуй через `config.target`, либо пиши в CRM и таблицы.
-  ⚠️ Если оплату надо дождаться ПРЯМО в диалоге, триггер не нужен — веди ветку `paid`
-  от блока `ACTIONS` со счётом.
-- `TRIGGER_TG_EVENT` — любое событие Telegram, кроме обычного сообщения: вступил/вышел из канала,
-  реакция, буст, заявка в закрытую группу, ответ в опросе и т.п.
-  `{ "event": "<имя поля Update>", "filter": { ... }, "priority": 0 }`.
-  Рабочие `event` (бэкенд их размечает, остальные молчат): `message`, `edited_message`,
-  `callback_query`, `channel_post`, `edited_channel_post`, `chat_member`, `chat_join_request`,
-  `my_chat_member`, `message_reaction`, `message_reaction_count`, `chat_boost`,
-  `removed_chat_boost`, `poll`, `poll_answer`, `inline_query`, `chosen_inline_result`,
-  `shipping_query`, `pre_checkout_query`.
-  **НЕ работают** (Telegram их шлёт, но рантайм не разбирает): `business_*`, `chat_shared`,
-  `users_shared`, `write_access_allowed`, `purchased_paid_media` — такой триггер не сработает.
-  `filter` (все условия по И, пустое = не задано):
-  `{"status":"member"|"left"|"kicked"|…}` — только там, где есть `member.status`
-  (`chat_member`, `my_chat_member`); `{"chatId":"-1001234567890"}` — конкретный чат/канал
-  (сравнение строкой, id каналов не влезают в int), доступен у 12 событий с `chat`;
-  `{"text":"купить","textMode":"contains"|"equals"}` — только `message`/`edited_message`/
-  `channel_post`/`edited_channel_post`. У `poll`/`poll_answer`/`inline_query`/
-  `chosen_inline_result`/`shipping_query`/`pre_checkout_query` чата нет → фильтров тоже.
-  Бот должен быть админом канала/группы, иначе события оттуда не придут.
-- `TRIGGER_ANY_UPDATE` — `{}`, ловит ЛЮБОЙ апдейт. Приоритет самый низкий: срабатывает, только
-  если не подошёл ни один конкретный триггер. Удобен как «ничего не понял» / отладка.
-- `TRIGGER_WEBHOOK` — `{}`, точка входа сценария с источником WEBHOOK (не бот). Такие сценарии
-  создаются в вебе; у графа бота этот триггер не сработает.
-  - **Внешние события интеграции** — тот же `TRIGGER_WEBHOOK`, но с заполненными
-    `{ "provider": "<provider-ключ из integration_catalog, нижний регистр>", "connectionId": "<id из list_integrations>",
-    "event": "<events[].key нужного события из inbound.events того же provider в integration_catalog>" }`.
-    Без `provider`+`connectionId` узел — обычный вебхук с произвольным телом; с ними URL ингресса
-    (`integration_ingress_url`) ведёт на обработчик конкретного провайдера, и запрос принимается только
-    в формате, который он понимает (подпись/HMAC сервиса проверяется на бэке). Переменные события —
-    `{{body.<ключ>}}`, ключи и примеры — в `inbound.events[].vars` того же события каталога.
-    amoCRM шлёт пачку сущностей одним запросом (`leads[add][0..n]`, `leads[status]`, `contacts[add]`) — сценарий
-    запускается по КАЖДОЙ сущности отдельно (порядок: сделки добавлены → смена этапа → контакты), не только по первой.
-    `event: "<key>"` с `paymentSucceeded:true` (кассы ЮKassa/CloudPayments/Robokassa/Т-Банк/Prodamus/bePaid) помимо
-    этого же `{{body.<ключ>}}`-прогона ЕЩЁ запускает узел «Оплата прошла» ваших графов — headless (без чата)
-    либо в чате подписчика, если платёжную ссылку выдавало действие `*_link`/`issue_invoice` с привязкой
-    к нему. Тестовый/demo-платёж (`test_mode`/`demo_mode` в переменных) прогоняет только обычный вебхук —
-    «Оплата прошла» на нём не срабатывает.
-- `TRIGGER_SITE_FORM` — `{ "siteId": "<uuid сайта>", "formId": "<id формы>" }` — заявка с формы
-  опубликованного сайта владельца. `formId` пустой/нет = любая форма сайта. `siteId` обязателен
-  (`SITE_FORM_NO_SITE`), сайт должен быть свой (`SITE_FORM_FOREIGN_SITE`). Переменные: поля формы
-  `{{var.<имя>}}`, всегда `{{var.name}}`/`{{var.email}}`/`{{var.phone}}` (по имени поля, иначе по подписи),
-  UTM `{{var.utm_*}}`. Прогон без чата: узлы отправки — только с `config.target`. Работает и в сценарии
-  без бота (источник WEBHOOK — тогда `TRIGGER_WEBHOOK` не обязателен), и в сценарии бота; не для Instagram.
-- `TRIGGER_SCHEDULE` — `{ "cron": "0 9 * * 1-5", "timezone": "Europe/Moscow" }` — запуск сценария по расписанию:
-  cron из 5 полей (минута час день месяц день-недели), не чаще раза в минуту; зона по умолчанию `Europe/Moscow`.
-  Прогон **headless** (без чата): узлы отправки — только с явным `config.target`, действия, которым нужен
-  подписчик, пропускаются; время срабатывания — `{{schedule.at}}`. Запуски, пропущенные во время простоя сервиса,
-  не догоняются. Работает в опубликованном активном сценарии (бота или вебхук-сценарии). Журнал — `scenario_runs`.
-- ~~`TRIGGER_COMMENT`~~ — **мёртвый тип**: рантайм нигде не выставляет `event="comment"`, сработать
-  он не может. Убран из палитры редактора. Комментарии Instagram — `TRIGGER_IG_COMMENT`.
-
-#### Instagram (только для IG-ботов)
-IG-боты не поддерживают команды (`/start`). Вход — через взаимодействие с контентом или директ:
-- `TRIGGER_IG_DM` — `{ "isRoot": true, "keywords": "хочу, каталог" }` — входящее сообщение в Instagram Direct. Это дефолтный триггер нового IG-графа (бэкенд сеет его при создании). `keywords` (опц.) — список через запятую или с новой строки; **регистронезависимо, совпадение по вхождению (contains)**; пусто = любое сообщение.
-- `TRIGGER_IG_COMMENT` — `{ "isRoot": true, "keywords": "купить, цена" }` — комментарий к посту или Reel бота. `keywords` (опц.) — список через запятую или с новой строки; регистронезависимый contains; пусто = любой комментарий.
-- `TRIGGER_IG_STORY_REPLY` — `{ "isRoot": true, "keywords": "хочу, вопрос" }` — ответ на историю бота. `keywords` (опц.) — список через запятую или с новой строки; регистронезависимый contains; пусто = любой ответ.
-- `TRIGGER_IG_STORY_MENTION` — `{ "isRoot": true }` — упоминание бота в истории подписчика. **Текста нет → фильтрация по ключевым словам не применяется**; срабатывает на каждое упоминание независимо от содержимого истории.
-
-> **Разные слова — разные сценарии:** добавь **несколько триггеров одного типа** с разными `keywords`; бэкенд берёт **первый совпавший по порядку узлов**. Триггер-«ловушку» с пустыми `keywords` (ловит всё) ставь **последним** — иначе он заблокирует все нижестоящие ключевые слова.
-
-Для всех IG-триггеров реакция бота отправляется через Instagram Messaging API в течение **24-часового окна** после последнего входящего действия пользователя.
-
-### Сообщения
-- `SEND_MESSAGE` —
-  ```json
-  { "_title": "Заголовок узла", "parseMode": "PLAIN"|"HTML"|"MARKDOWN",
-    "text": "Текст сообщения",
-    "cards": [ { "id": "c1", "type": "text", "text": "Текст сообщения" } ],
-    "buttons": [ [ { "text": "Кнопка", "kind": "CALLBACK"|"URL", "value": "<url для URL; ПУСТО для CALLBACK>", "color": "", "track": true } ] ] }
-  ```
-  ВСЕГДА заполняй и `text`, и `cards[0].text` одинаково. `buttons` — массив рядов (каждый ряд — массив кнопок).
-  - **Медиа-карточки** (`cards[].type`): `text`, `image`, `video`, `audio`, `file`, `voice`, `videonote` (кружок), `gallery` (альбом 2–10 фото), `question` (вопрос). У медиа-карточки ссылка на файл лежит в поле `url` (у `gallery` — массив `urls`). Сам файл (фото/видео/документ) в графе НЕ хранится — только URL. Чтобы получить URL, сперва загрузи файл инструментом **`upload_file`** (`path` локального файла или `url` для перезаливки) — он кладёт файл в библиотеку **/bots/files** и возвращает публичный `url`; его и вставляй в карточку. Примеры: `{ "id":"c2","type":"image","url":"https://bots.retensy.com/media/botmedia/<id>.jpg","text":"подпись (опц.)" }`, видео/аудио/файл/`voice`/`videonote` — так же с `url`; галерея — `{ "type":"gallery","urls":["https://…","https://…"] }`. Уже загруженные файлы — `list_files`, удалить — `delete_file`. Лимит 50 МБ; типы: image/video/audio/pdf/zip/doc(x)/xlsx/pptx/txt (SVG нельзя).
-  - `parseMode:"HTML"` (дефолт редактора) — текст должен быть **безопасным Telegram-HTML**: разрешены только `b,strong,i,em,u,ins,s,strike,del,code,pre,a[href],tg-spoiler,br`. Любой другой тег/атрибут → ошибка публикации `HTML_NOT_SAFE`. Не уверен — ставь `PLAIN`.
-  - **Кнопки-выборы (`kind:"CALLBACK"`)**: `value` ОСТАВЛЯЙ ПУСТЫМ (`""`). Бот сам сгенерит `callback_data` вида `n:<id узла>:<индекс>`, а переход задаётся ребром `btn_N` от кнопки. **Непустой `value`** трактуется как legacy-`callback_data` для отдельного узла `TRIGGER_CALLBACK` (у такой кнопки ребра `btn_N` быть не должно) — если поставить `value` обычной кнопке-выбору, переход по `btn_N` **сломается** (нажатие → `NO_MATCH`).
-  - **Кнопки-ссылки (`kind:"URL"`)**: `value` = URL. Могут иметь `"track": true` — клики считаются, и на такой шаг можно сослаться из условия `LINK_CLICKED` (см. ниже).
-  - **`color`** (опционально, и у CALLBACK, и у URL) — только стили, которые рендерит Telegram (как в основном боте / pengrad `ButtonStyle`): `""`=по умолчанию, `"#2EA6FF"`=primary (синий), `"#34C759"`=success (зелёный), `"#FF3B30"`=danger (красный). Других цветов нет.
-  - **Режим «Вопрос» (`awaitReply: true`)** — сообщение задаёт вопрос и ждёт ответ (паркуется как `ASK_QUESTION`). Доп. поля: `"saveTo":"name"` (обязателен, `[a-z_][a-z0-9_]{0,63}`), `"inputKind":"TEXT"|"PHOTO"|"DOCUMENT"|"CONTACT"|"LOCATION"`, `"validator":"ANY"|"PHONE"|"EMAIL"|"REGEX"`, `"regex":"..."`, `"retryText":"..."`, `"maxAttempts":3`. Выходы — `valid` / `invalid` (как у `ASK_QUESTION`), плюс `btn_N` для кнопок.
-  - **Канал ответа Instagram (`igReplyChannel`, только для IG-ботов)** — `"comment"` (по умолчанию) — публичный ответ под комментарием; `"dm"` — личное сообщение автору комментария (Private Reply). `"dm"` срабатывает только в графе с `TRIGGER_IG_COMMENT` (нужен `comment_id`): Meta разрешает **1 ЛС на комментарий**, 24-часовое окно на private reply не распространяется. Чтобы ответить и публично, и в ЛС — поставь два шага: один с `"igReplyChannel":"comment"`, второй с `"igReplyChannel":"dm"`.
-- `SEND_PHOTO` — `{ "photoUrl": "https://...", "caption": "подпись (необязательно, ≤1024)", "igReplyChannel": "comment"|"dm" }` (`igReplyChannel` — только IG, см. `SEND_MESSAGE`). `photoUrl` можно получить через `upload_file`.
-
-### Логика / ветвление
-- `CONDITION` — проверка условий, выходы `yes` / `no`. `{ "match":"ALL"|"ANY", "conditions":[ { "kind":"...", "op":"...", "key":"...", "value":"..." } ] }`. `match:"ALL"` — все условия истинны; `"ANY"` — хотя бы одно. Полный список `kind`/`op`/полей — в разделе [«Условия CONDITION»](#условия-condition).
-- `BRANCH` — `{ "cases":[ {"id":"c1","label":"...","expression":"var.x=='a'"} ], "hasDefault": false, "abTest": false }`. Выходы: `case_<id>` (+ `default`).
-- `SWITCH` — развилка по ЗНАЧЕНИЮ, когда веток больше двух.
-  `{ "expression":"{{var.http_status}}", "cases":[ {"id":"v1","value":"200","label":"Успех"},
-  {"id":"v2","value":"404","label":"Не найдено"} ] }`. Выходы: `case_<id>` + `default` (есть всегда).
-  Выражение рендерится как шаблон (обычно просто `{{var.x}}`) и сравнивается со `value` каждого
-  случая **без учёта регистра и пробелов по краям**; первое совпадение выигрывает, иначе `default`.
-  Отличия: `CONDITION` — бинарное да/нет, `BRANCH` — случайный выбор (A/B), `SWITCH` —
-  детерминированный выбор по значению. Валидатор режет: пустое `expression`
-  (`SWITCH_NO_EXPRESSION`), нет случаев (`SWITCH_NO_CASES`), пустое `value` (`SWITCH_EMPTY_VALUE`),
-  повтор значения (`SWITCH_DUPLICATE_VALUE`), случай без ребра (`SWITCH_CASE_UNCONNECTED`).
-  Ребро на `default` необязательно.
-- `STOP_AND_ERROR` — `{ "message":"CRM не ответила: {{var.http_status}}" }`. Обрывает прогон и
-  помечает его в журнале как ошибочный (`FAILED`), шаг — `ok:false` с этим текстом. Выходов нет,
-  ничего подписчику не отправляет. Пустой `message` → «Сценарий остановлен с ошибкой».
-- `ASK_QUESTION` — вопрос со сбором ответа. `{ "promptText":"...","saveTo":"name","inputKind":"TEXT"|"PHOTO"|"DOCUMENT"|"CONTACT"|"LOCATION","validator":"ANY"|"PHONE"|"EMAIL"|"REGEX","regex":"...","retryText":"...","maxAttempts":3 }`. `inputKind` (по умолчанию `TEXT`) — что ждём в ответ (`CONTACT` → телефон: в Telegram показывается кнопка «Поделиться номером», в MAX/Instagram кнопки нет — номер вводится вручную и принимается как телефон на всех платформах; `LOCATION` → `lat,lon`, `PHOTO`/`DOCUMENT` → file_id). Выходы `valid` / `invalid`.
-- `END` — `{}` (конец ветки). **Не добавляй `END`**: ветка и так завершается на узле без исходящих рёбер; явный «конец сценария» бесполезен и убран из палитры редактора. Тип оставлен лишь для совместимости со старыми графами.
-
-### Тайминги
-- `DELAY` — пауза. Три вида (`kind`):
-  - **`FIXED`** («Отправить через»): `{ "kind":"FIXED", "durationSec": 86400 }` — `durationSec` в **секундах** (60 = 1 мин, 3600 = 1 час, 86400 = 1 сутки). Редактор также пишет `{ "kind":"FIXED", "duration": 24, "unit":"MINUTES"|"HOURS"|"DAYS" }` (минуты/часы/дни — чтобы не вбивать большие числа). Для генерации проще `durationSec`.
-  - **`TOMORROW`** («Отправить завтра»): `{ "kind":"TOMORROW", "time":"18:00" }` — завтра в указанное время `HH:mm` (МСК), относительно момента, когда пользователь дошёл до узла.
-  - **`UNTIL`** («Отправить в»): `{ "kind":"UNTIL", "isoTimestamp":"2026-06-25T15:00:00Z" }` — конкретный момент в ISO-8601. ⚠️ Рантайм читает только `isoTimestamp`; пары `isoDate`+`time` НЕ работают. Можно шаблон из переменной и смещение: `{ "kind":"UNTIL", "isoTimestamp":"{{var.slot_at}}", "offset":"-24h", "timezone":"Europe/Moscow" }` — «за сутки до записи» (`offset`: `-30m`, `+1d`, единицы s/m/h/d/w; дата без зоны читается в `timezone`, по умолчанию Москва). Момент уже прошёл → выход `late`, если ребро нарисовано, иначе шаг выполняется сразу (`snapshot.lateBy`). Шаблон не разобрался как дата → выход `error`.
-- `SCHEDULE` — `{ "isoDate":"2026-06-25", "time":"18:00", "timezone":"Europe/Moscow" }`. Выходы `scheduled` / `past`. `isoDate` может быть и ISO дата-временем или шаблоном (`"{{var.slot_at}}"`, тогда `time` не нужен) + `offset` как у `DELAY UNTIL`.
-- Прогон без пауз (между `DELAY`, `ASK_QUESTION`/`awaitReply`, ожиданием оплаты) ограничен **5 минутами**: дольше — рантайм обрывает его с ошибкой шага `run deadline exceeded` (прогон `FAILED`, пауза подписчика снята). Длинные цепочки `external_request` / `CALL_WEBHOOK` / `AI_REPLY` разноси `DELAY` — после паузы начинается новый прогон.
-- Массовый одинаковый момент срабатывания (`TOMORROW`/`UNTIL`/`SCHEDULE` у тысяч подписчиков одного бота) расходится постепенно: до 10 срабатываний на бота в секунду, время растёт с аудиторией (≈100 с на 1000 подписчиков, ≈17 мин на 10 000), другие боты не ждут. Не рассчитывай, что все получат сообщение в одну секунду.
-- Если Telegram вернул боту 429 (`retry after N`, пауза не дольше часа), срабатывания `DELAY`/`SCHEDULE` и рассылки этого бота (и по `BROADCAST_FILTER`, и прямые) ждут конца паузы; после такой паузы рассылка продолжается без потерь и без повтора уже доставленного. Это только про паузу 429: если сервис перезапустился посреди отправки, получатель, на котором её прервали, через ≤15 мин может получить рассылку (или прогон сценария) повторно. Ответ подписчику в живом диалоге отправляется сразу, без ожидания; если Telegram откажет снова, шаг уходит в ветку «Ошибка», если она проведена, иначе дальше по обычному выходу.
-- `AI_REPLY` при сбое провайдера (5xx, таймаут) уходит в `error` примерно через минуту — не рассчитывай на долгое ожидание ответа модели.
-
-### Состояние / действия
-- `SET_VARIABLE` (`{ "key":"name", "value":"..." }`), `ADD_TAG`/`REMOVE_TAG` (`{ "tag":"lead" }`), `FORMULA` (`{ "expression":"...", "saveTo":"name" }`)
-- `ACTIONS` — непустой пакет действий `{ "actions":[ { "kind":"...", ...поля } ] }`. Допустимые `kind` (иначе ошибка `ACTION_UNKNOWN_KIND`):
-  - **метки/автоворонки**: `add_tag`, `remove_tag`, `autoflow_add`, `autoflow_remove` — поле `tag` (`[a-z0-9_-]{1,64}`)
-  - **профиль**: `set_field` — `key` (`[a-z_][a-z0-9_]{0,63}`) + `value`; `subscribe`, `unsubscribe`
-  - **HTTP**: `external_request` — **основной способ сходить в чужой API**, те же поля и возможности,
-    что у узла `CALL_WEBHOOK`: `url` + `method`/`headersJson`/`bodyTemplate`/`timeoutMs` +
-    `saveStatusTo`/`saveBodyTo`/`extract`. Отличие одно: своих выходов у действия нет — сбой уводит
-    ВЕСЬ блок `ACTIONS` в его выход `error` (если ребро нарисовано; нет — идём по `next`), а
-    ветвиться по коду ответа надо следующим блоком `SWITCH`. **Платное действие** (как `CALL_WEBHOOK`):
-    на бесплатном тарифе публикация падает с `PREMIUM_NODE_FORBIDDEN`.
-    Ещё есть `subscriber_webhook` — `url` + `method`/`headersJson`/`bodyTemplate`
-  - **уведомления**: `notify` (`text`) — владельцу бота в бот уведомлений из его профиля (Telegram/MAX); не подключён → действие не удалось, блок уходит в `error`; `subscriber_email` (`email`,`text`)
-  - **передача оператору**: `agent_chat` (без полей) — «позвать человека»: диалог встаёт на паузу (бот и ИИ молчат, входящие копятся в «Диалогах»), владельцу уходит уведомление; без бота уведомлений действие помечается `NOT_CONFIGURED`, пауза всё равно включается. Вернуть боту — кнопка в «Диалогах» или MCP `dialog_handoff {active:false}`. В dry-run и headless-прогонах пропускается.
-  - **срок ответа оператора (SLA)**: `sla_check` — опц. `maxLevel` (0 — без потолка), `timezone` (для `sla_at`, по умолч. Europe/Moscow). Ставь первым в блоке `ACTIONS` после `DELAY` на срок ответа, ниже в том же блоке — эскалация (`add_tag`, `notify`). Оператор не писал в чат после `agent_chat` → `sla_breached`=`1`, `sla_level` +1, `sla_at` — ISO со смещением, действия блока выполняются; ответил / диалог у бота / тот же таймер повторно → `sla_breached`=`0`, остальные действия блока пропускаются. Новая передача — уровни с 1. Ветвиться дальше — `CONDITION` по `{{var.sla_level}}`.
-  - **запись на слоты** (календарь — `booking_calendar_create`/`booking_calendar_list`): `booking_slots` — `calendarId`, опц. `days` (1–62, по умолч. 7), `limit` (1–50, по умолч. 10), `saveTo` (по умолч. `slots`) → переменные `slots` (нумерованный список для сообщения), `slots_json`, `slots_count`; `booking_book` — `calendarId`, `slotAt` (по умолч. `{{var.slot_at}}`; можно номер из списка «2», ISO-время или подпись слота), опц. `slotsVar`, `name`/`phone` (по умолч. `{{var.name}}`/`{{var.phone}}`) → `booking_id`, `slot_at` (ISO с зоной — для напоминания `DELAY UNTIL {{var.slot_at}} offset -24h`), `slot_label`, `booking_status`; занятый слот → выход блока **`taken`** (если ребро нарисовано, иначе `error`); `booking_cancel` — `bookingId` (по умолч. `{{var.booking_id}}`), освобождает слот.
-  - **контакт заявки**: `lead_link_contact` — `phone`/`email` (по умолч. `{{var.phone}}`/`{{var.email}}`) → склейка с единым контактом владельца по телефону E.164 или email, `{{var.contact_id}}`.
-  - **платный доступ / подписки** (бот должен быть админом группы/канала): `invite_link_create` — персональная ссылка на одно вступление: опц. `expireHours` (по умолч. 24), `name`, `saveTo` (по умолч. `invite_link`), `send` (false — не отправлять), `text`; `invite_link_revoke` — `link` (по умолч. `{{var.invite_link}}`); `subscription_extend` — `period` (`1mo`, `30d`, `1y`, `2w`, `12h`), опц. `var` (по умолч. `sub_until`), `timezone` — продлевает от max(сейчас, текущий срок); `subscription_check` — опц. `var`, `saveTo` (по умолч. `sub_active`) → `true`/`false`; `yookassa_charge_saved` — рекуррентное списание по сохранённому способу оплаты: `connectionId` (ЮKassa), `amount`, `description`, опц. `paymentMethodId` (по умолч. `{{var.yk_payment_method_id}}`), `periodKey` (по умолч. `{{var.sub_until}}` — защита от двойного списания за период). Доступ продлевает не списание, а сценарий `TRIGGER_PAYMENT` → `subscription_extend`.
-  - **Meta Conversions API** (Integration Core): `meta_capi_event` — `connectionId`, `eventName` (Purchase/Lead/…), опц. `dealId`, `stage`, `eventId`, `email`/`phone` (сырые — хешируются SHA-256), `value`, `currency`, `actionSource`. Поля других провайдеров — в `integration_catalog` (`actions[].inputs`).
-  - **Integration Core: поля и переменные-результаты** (все — с `connectionId`; пустое/неверное обязательное поле → действие не вызывает сервис, блок уходит в `error`):
-    - `ydelivery_price` (Яндекс Доставка) — ВСЕ поля обязательны: `fromLat`, `fromLon`, `toLat`, `toLon`, `fromAddress`, `toAddress` (город, улица, дом — без квартиры/подъезда), `weightKg`, `lengthCm`, `widthCm`, `heightCm` (габариты упаковки в см, > 0, запятая допустима). Без адресов или габаритов — ошибка (заглушек нет). → `ydelivery_price`, `ydelivery_currency`, `ydelivery_eta` (ISO-дедлайн).
-    - `cdek_tariff` (СДЭК) — `fromCity`, `toCity`, `weightGrams`, `tariffCode` → `cdek_price` (только доставка), **`cdek_total_sum`** (итог с доп. услугами, 2 знака — его показывай клиенту), `cdek_days_min`, `cdek_days_max`; `cdek_order_status` — `cdekNumber` → `cdek_status`.
-    - `moysklad_find_product` — `search` → `moysklad_product_name`, `moysklad_product_price`, **`moysklad_product_id`**; **`moysklad_product_stock`** — остаток: `productId` (обяз., UUID товара/модификации, обычно `{{var.moysklad_product_id}}`), опц. `stockType` (`stock` по умолч., `freeStock`, `quantity`, `reserve`, `inTransit`) → `moysklad_stock` (товар без движений — `0`). Дальше — `CONDITION` по `{{var.moysklad_stock}}`.
-    - **`unisender_send_sms`** — одиночное SMS: `phone` (с кодом страны), `sender` (альфа-имя 3–11 символов, зарегистрированное в Unisender), `text` (до 1000 символов) — все обязательны → `unisender_sms_id`. `unisender_subscribe` → `unisender_person_id`.
-    - `rest_api_call` — в `body` (JSON) `{{var.x}}` сам ставит кавычки строкам; число или boolean в переменной уходит своим типом (`{"qty": {{var.qty}}}` → `{"qty": 5}`). Тип — по значению переменной, не по виду строки: введённый текст из цифр (телефон) остаётся строкой.
-  - **бот/шаг**: `stop_bot`, `delete_step_message`, `cancel_payment_subscription`
-  - **Google Таблицы (работает)**: `gsheets_send` — дописать строку-заявку в таблицу: `{ "kind":"gsheets_send", "googleEmail":"me@gmail.com", "spreadsheetId":"<id таблицы>", "sheetName":"Лист1", "cells":["{{from.first_name}}","{{var.phone}}","{{var.email}}"] }`. `cells` — значения по порядку (шаблоны), бот дописывает их строкой в конец листа. Google-аккаунт подключается В ВЕБЕ (`/bots` → у действия кнопка «Подключить Google»), НЕ через MCP — у пользователя уже должен быть подключён `googleEmail`. Нужны `googleEmail` + `spreadsheetId` + непустой `cells[]` (иначе `ACTION_GSHEETS_INCOMPLETE`).
-    Остальные четыре действия с таблицами тоже РАБОТАЮТ и тоже требуют `googleEmail` + `spreadsheetId`:
-    `gsheets_get` (`range` → `saveTo`), `gsheets_update` (`range`, `values[]`), `gsheets_write_cell`
-    (`cell`, `value`), `gsheets_read_cell` (`cell` → `saveTo`; пустая ячейка не ошибка — переменная станет `""`).
-  - **CRM и внешние системы — РАБОТАЮТ** (реальные HTTP-клиенты на бэкенде, не заглушки).
-    Всем им нужен **`connectionId`** — id подключения пользователя; без него действие падает
-    «не выбрано подключение». **Узнать id: инструмент MCP `list_integrations`** (отдаёт
-    `{id, provider, title, hint}`; сами креды не отдаются). Значения полей — шаблоны
-    (`{{var.x}}`, `{{from.first_name}}`).
-    - `amocrm_send` — создать сделку (+контакт): `connectionId`, `leadName`, опц. `price`,
-      `pipelineId`, `statusId` (числа), `contactName`, `phone`, `email`. Если все три контактных
-      поля после рендера пусты — сделка уходит без контакта. В переменные кладёт `amo_lead_id`
-      и `amo_contact_id` (если amo его вернул).
-    - `amocrm_update` — частичное обновление сделки: `connectionId`, `leadId` (обычно
-      `{{var.amo_lead_id}}`), плюс те же `leadName`/`price`/`pipelineId`/`statusId`. Пустой
-      `leadId` или отсутствие полей для обновления — отказ.
-    - `bitrix24_call` — любой REST-метод Битрикс24: `connectionId`, **`b24method`** (именно так,
-      не `method` — это имя занято HTTP-методом «Внешнего запроса»), `fields` — список пар
-      `{key, value}` (ключ вида `fields[TITLE]` разворачивается во вложенную карту),
-      `extract` — список `{path, saveTo}` для JsonPath-извлечения ответа в переменные.
-    - `getcourse_send` — добавить/обновить пользователя: `connectionId`, `email`, опц. `userName`,
-      `phone`, `groups` (CSV групп), `addfields` (карта доп.полей). Повторная заявка обновляет,
-      а не дублирует.
-    - `getcourse_order` — создать заказ: те же поля пользователя + `offerCode`, опц. `dealStatus`,
-      `dealComment`. В переменные кладёт `gc_deal_id`, если GetCourse его вернул.
-    - `yametrika_event` — офлайн-конверсия в Я.Метрику: `connectionId`, `idType`
-      (`ClientId`|`Yclid`, по умолчанию `ClientId`), **`idValue`** (обязателен после рендера —
-      пустой обрывает действие), опц. `target`, `price`, `currency` (по умолчанию `RUB`),
-      `dateTime` (unix-секунды, по умолчанию «сейчас»).
-  - **Единственное НЕ интегрированное действие**: `cancel_payment_subscription` —
-    принимается как no-op с пометкой `integration_not_connected`.
-  - **модерация группы**: `group_unban`, `group_kick`, `group_approve`, `group_decline`
-
-### Внешнее / прочее
-- `CALL_WEBHOOK` — `{ "url":"https://...", "method":"POST", "headersJson":"{\"X-Key\":\"…\"}",
-  "bodyTemplate":"{...}", "timeoutMs":5000, "saveStatusTo":"http_status", "saveBodyTo":"http_body",
-  "extract":[{"path":"$.id","saveTo":"crm_id"}] }`. Выходы `ok` (код 2xx) / `error` (код ≥ 400,
-  сетевая ошибка, таймаут, отказ SSRF-гарда). Если ребра `error` нет — прогон идёт по `next`.
-  - `timeoutMs` — на этот узел; 0/не задан = общий клиент (connect 5 с / read 7 с), иначе значение
-    прижимается к диапазону **500…30000 мс**.
-  - `saveStatusTo` / `saveBodyTo` — имена переменных для HTTP-кода и тела ответа целиком.
-    Пишутся ВСЕГДА, в том числе на `error`: при сетевой ошибке код `0` и пустое тело (чтобы в
-    переменной не осталось значение прошлого прогона). Тело длиннее 65 536 символов обрезается — как любое строковое значение переменной (список/объект длиннее, например из `extract`, не сохраняется); все переменные подписчика вместе с именами — до 262 144 символов, запись сверх лимита не сохраняется (переменная прежняя).
-    Это штатный способ разветвиться по коду ответа: `saveStatusTo` → `SWITCH`.
-  - `extract` — разбор JSON-тела по JsonPath в переменные (работает только на валидном JSON).
-- `AI_REPLY` — ответ модели. Два режима, переключатель — поле `mode` (`"simple"`/не задано, либо
-  `"agent"`). Узел без `mode` работает дословно как режим `simple` (обратная совместимость: в
-  проде живут графы без этого поля). **Оба режима платные** (`PREMIUM_NODES`): на бесплатном
-  тарифе публикация падает с `PREMIUM_NODE_FORBIDDEN`. Веб-редактор показывает поле
-  `quotaFallbackText` в инспекторе для ОБОИХ режимов (без подстановки `{{var.x}}` — уходит клиенту
-  как есть).
-
-  **`mode: "simple"`** (сегодняшнее поведение, без изменений):
-  `{ "systemPrompt":"Ты консультант магазина.", "userPromptTemplate":"Вопрос: {{last_text}}",
-  "sendToUser": true, "saveTo":"ai_answer", "quotaFallbackText":"Спросите менеджера" }`.
-  `userPromptTemplate` обязателен (пустой → выход `error`). `sendToUser:true` — отправить ответ
-  подписчику; `saveTo` — положить в переменную. Если месячный AI-бюджет тарифа исчерпан, узел НЕ
-  ошибка: отправляется `quotaFallbackText` (если задан) и сценарий идёт дальше по `next`. В этом
-  случае `saveTo` НЕ обновляется — переменная хранит значение прошлого прогона (или остаётся
-  пустой, если прогона ещё не было). Температура задаётся глобально на сервере — поле
-  `temperature` в конфиге рантайм не читает.
-
-  **`mode: "agent"`** — поиск по базе знаний + ветки-действия + память диалога на этом узле. Температура
-  агента своя, серверная (`botbuilder.ai.agent-temperature`, по умолчанию 0.3), `temperature` узла не читается
-  (спека `docs/superpowers/specs/2026-09-21-ai-agent-node-design.md`, раздел 10). У узла-агента
-  **нет выхода `next`** — вместо него именованные ветки ниже.
-  ```json
-  { "mode": "agent", "knowledgeBaseId": "<id базы знаний>", "strict": true,
-    "systemPrompt": "Ты консультант магазина. Отвечай по базе, вежливо и по делу.",
-    "actions": [ { "id": "order", "title": "Оформить заказ", "when": "клиент готов купить" } ],
-    "extract": [ { "variable": "phone", "description": "телефон клиента" } ],
-    "quotaFallbackText": "Спросите менеджера" }
-  ```
-  Необязательные числовые/флаговые поля и их дефолты (можно не указывать вовсе):
-  `directAnswer` (`false`), `directAnswerThreshold` (`0.88`), `minScore` (`0.35`), `topK` (`5`),
-  `maxContextChars` (`6000`), `historyTurns` (`6`).
-  - `knowledgeBaseId` — id базы знаний ЭТОГО владельца (иначе рантайм ведёт себя так, будто базы
-    нет). `strict` (по умолчанию `true`) — без базы в строгом режиме публикация падает с
-    `AGENT_NO_KNOWLEDGE_BASE`.
-  - **Без найденных в базе фрагментов агент уходит в `unknown` в ЛЮБОМ режиме** — если хитов нет
-    или лучший скор ниже `minScore`, до вызова модели дело не доходит вообще (нестрогий режим
-    агента без базы или без совпадений не «отвечает по общим знаниям», он так же уходит в
-    `unknown`). **Исключение — узел с непустым `actions[]`:** он и без фрагментов зовёт модель
-    (платно), чтобы та могла выбрать действие — «запишите меня на завтра» слов из базы не содержит;
-    её ответ без фрагментов в любом режиме (и в нестрогом) уходит в `unknown` — только действие. Узел только с
-    `extract[]` выходит рано, как раньше. `strict` решает только то, что делает модель, когда релевантные фрагменты уже
-    нашлись: в строгом режиме — отвечает исключительно по ним; без строгого режима — может
-    дополнить их общими знаниями модели, но не про цены/сроки/обещания — это всегда только из
-    базы и инструкции.
-  - `directAnswer` (по умолчанию `false`) — прямой ответ готовой парой вопрос-ответ БЕЗ обращения
-    к модели (бесплатно), когда совпадение по базе ≥ `directAnswerThreshold`. Пара ищется по вектору
-    своего вопроса, так что порог 0.88 проходят почти дословные формулировки. Работает только для
-    документов-пар вопрос-ответ (не для кусков файлов/сайта) — кусок PDF, отданный дословно,
-    выглядел бы поломкой.
-  - `minScore` — порог релевантности фрагмента для решения «есть о чём отвечать»; ниже — выход
-    `unknown`. `topK`/`maxContextChars` — сколько фрагментов брать и лимит символов контекста.
-    `historyTurns` — сколько реплик истории диалога передавать модели.
-  - `systemPrompt` — инструкция агента. Мягкая норма — **до 10 000 символов**: длиннее модель хуже
-    держит середину, и каждый ответ дороже. У бэкенда для этого нет отдельного предупреждения при
-    публикации (веб-инспектор просто красит счётчик символов) — только `validate.mjs` (этот
-    скилл) предупреждает об этом явно. Жёсткий потолок — **30 000 символов**
-    (`AGENT_PROMPT_TOO_LONG`, блокирует публикацию и у бэкенда, и у `validate.mjs`). Платформа
-    сама добавляет ПЕРЕД инструкцией служебный блок: защиту от инъекций/вытягивания инструкции
-    через реплики клиента, историю и фрагменты базы, запрет писать, что действие уже выполнено
-    (это делает сценарий, не модель), запрет обещать несделанное, и формат ответа под конкретный
-    мессенджер — **дублировать это в `systemPrompt` не нужно**.
-  - `actions[]` — ветки, которые выбирает сама модель по смыслу разговора: `id` (латиница/цифры/`_`),
-    `title` (человеческое название — без него запись целиком игнорируется рантаймом и валидатором),
-    `when` (опц., подсказка модели, когда применять). Каждому действию — своё ребро
-    `action_<id>`; повтор `id` → `AGENT_DUPLICATE_ACTION_ID`, отсутствие ребра →
-    `AGENT_ACTION_NOT_CONNECTED`.
-  - `extract[]` — переменные, которые агент сам заполняет из разговора: `variable`
-    (`[a-z_][a-z0-9_]{0,63}`, не `ai_summary` — оно зарезервировано), `description` (что искать).
-    Значение — **слова клиента, а не проверенный факт**. Кривая запись → `AGENT_BAD_EXTRACT`.
-  - При уходе в действие (`action_<id>`) агент сам готовит сводку разговора для менеджера —
-    без отдельной настройки, кладёт её в `{{var.ai_summary}}` (до 1500 символов, тоже слова
-    клиента, не проверенные данные).
-  - Выходы: `answered` (ответила модель — по базе, а без строгого режима ещё и общими знаниями),
-    `action_<id>` (по числу `actions[]`), `unknown` (не знает ответа — нет фрагментов выше
-    `minScore`, ветка не подключена не блокирует публикацию, только предупреждение
-    `AGENT_UNKNOWN_NOT_CONNECTED`, но диалог упрётся в тупик), `budget_exhausted` (месячный
-    AI-бюджет исчерпан, если ветка подключена), `error` (сбой модели/поиска, ИИ не настроен на
-    сервере, headless-вебхук — у агента нет собеседника — или исчерпан бюджет, а ветка
-    `budget_exhausted` не подключена). Прямой ответ (`directAnswer`) отправляется и идёт в выход
-    `answered`, как обычный ответ модели.
-  - **Исчерпание бюджета у агента — НЕ `next`** (такого выхода у узла нет): уходит в
-    `budget_exhausted`, если ветка подключена, иначе в `error`. `quotaFallbackText` (без
-    подстановки переменных) отправляется в обоих случаях, если задан. Это касается и
-    `directAnswer` — бесплатный прямой ответ тоже не сработает при исчерпанном бюджете месяца,
-    проверка бюджета идёт раньше поиска по базе.
-- `PAYMENT_LINK` — сообщение с кнопкой-ссылкой на оплату (сам платёж не проводит).
-  `{ "paymentUrl":"https://example.com/pay?user={{from.id}}", "description":"Оплатите подписку:",
-  "buttonText":"Оплатить" }`.
-- `YOOKASSA_PAYMENT` — узел оплаты. **В новых сценариях его не ставь**: выставление счёта — это
-  действие, поэтому оно живёт действием `issue_invoice` внутри `ACTIONS` (см. ниже), а узла больше
-  нет в палитре. Тип жив в рантайме только ради графов, где он уже стоит.
-- Действие **`issue_invoice`** внутри `ACTIONS` — настоящий счёт на **кассу владельца бота**
-  (деньги идут на его магазин, не на счёт сервиса) и, если нужно, ожидание оплаты.
-  `{ "kind":"issue_invoice", "connectionId":"<id подключения ЮKassa>", "amount":"990",
-  "description":"Доступ к курсу", "buttonText":"Оплатить", "timeoutMinutes":60 }`.
-  - `connectionId` **обязателен** — подключение из реестра с `provider=YOOKASSA`
-    (`list_integrations`). Нет его → `YK_NO_CONNECTION`. Касса обязана принадлежать владельцу
-    бота, чужой id рантайм отвергает.
-  - `amount` обязателен, > 0, можно шаблоном (`{{var.price}}`); `description` обязателен.
-  - **Выходы даёт БЛОК `ACTIONS`** (тем же приёмом, что и `error`): при наличии счёта у блока
-    появляются `paid` и `timeout`. Ключевое правило: **поведение зависит от того, протянул ли ты
-    ветку `paid`.**
-    - Ветки `paid` НЕТ → блок просто шлёт счёт и идёт по `next`, ничего не дожидаясь.
-    - Ветка `paid` ЕСТЬ → сценарий встаёт на паузу до подтверждения оплаты кассой; не дождался за
-      `timeoutMinutes` → уйдёт в `timeout`. Сообщения подписчика до оплаты (другие триггеры, ветки до END,
-      вопроса или задержки) ожидание не сбрасывают: `paid`/`timeout` всё равно сработают. Сбрасывает его только
-      пауза на ДРУГОМ счёте с веткой `paid` — тогда оплата прежней ссылки сценарий не продолжает.
-  - ⚠️ **Счёт обязан быть ПОСЛЕДНИМ действием в блоке** (`INVOICE_NOT_LAST`) и только один
-    (`INVOICE_DUPLICATE`). Причина: с веткой `paid` блок встаёт на паузу, а возобновиться с
-    середины списка движок не умеет — действия после счёта молча не выполнились бы.
-  - `timeoutMinutes` — 1…1440, по умолчанию 60. Имеет смысл только вместе с веткой `paid`.
-  - Переменные после шага: `{{var.payment_url}}`, `{{var.payment_id}}`.
-  - Повторный проход по счёту: пока попытка ЭТОГО шага жива (не оплачена, таймаут не сработал, другой счёт с
-    `paid` её не сменил) — та же ссылка (тот же платёж), даже если между проходами подписчик ушёл в другую
-    ветку; после оплаты или таймаута — новый счёт. Оплата, пришедшая после таймаута, ветку `paid` не продолжает, зато запускает сценарии владельца с `TRIGGER_PAYMENT` в диалоге этого подписчика (один раз на платёж; бот выключен — ЮKassa повторяет уведомление, запуск после включения бота) — для опоздавших заведи такой сценарий. Если таймаут был пропущен, пока бот был выключен, повторный проход сперва спрашивает ЮKassa: платёж оплачен — шаг сразу идёт по `paid` (нового счёта нет); статус не узнать — та же ссылка; не оплачен — новый счёт.
-  - Без ветки `paid` ожидания нет: каждый проход по такому счёту — новый платёж с новой ссылкой.
-  - Действие бесплатное (в отличие от `external_request`).
-  - ⚠️ Чтобы `paid` вообще срабатывал, владелец должен вписать адрес уведомлений из карточки
-    подключения в кабинет ЮKassa (событие `payment.succeeded`). Если этого не сделано, оплата
-    пройдёт, а сценарий будет молча ждать до таймаута — это не баг графа.
-  - Бот выключен в момент оплаты или проверка платежа не удалась (сбой ЮKassa, устаревший ключ в подключении) →
-    ЮKassa повторяет уведомление до суток; `paid` сработает на первом удачном повторе, если сценарий к тому
-    времени ещё не ушёл в `timeout`. Не удалось за сутки — сценарий по этой оплате не продолжится.
-- `CALL_WEBHOOK` — тоже платный узел, см. раздел «Внешнее / прочее». **В новых сценариях его не
-  ставь**: узла больше нет ни в палитре, ни в меню — внешний запрос собирается действием
-  `external_request` внутри `ACTIONS`. Тип живёт в рантайме только ради графов, где он уже стоит.
-- Действие `external_request` внутри `ACTIONS` — **тоже платное**, гейт тот же.
-
-## Лимиты тарифа, которые видит сборщик графов
-
-- **Блоков в сценарии.** Публикация падает с `NODE_LIMIT_EXCEEDED` (в тексте — сколько блоков в
-  графе и сколько даёт тариф). Ошибка на весь граф, `nodeId` пустой. Проверять нечем заранее:
-  число блоков берётся из `nodes[]`, лимит — из тарифа владельца.
-- **Число сценариев.** `create_graph`, `create_graph_from_template`, `clone_graph`, `copy_graph` и
-  создание сценария в вебе отдают **HTTP 402** `{error, upgradeUrl}`, когда лимит исчерпан.
-  Считаются сценарии, которые завёл человек; снимок публикации место не занимает.
-- **Переменные** (глобальные и на сценарий) тоже лимитированы тарифом — сама подсистема переменных
-  ещё не построена, поле лимита в тарифе уже есть.
-
-## Условия CONDITION
-
-Каждый элемент `conditions[]` — `{ "kind", "op", ...поля }`. Любая внутренняя ошибка условия = `false` (узел уходит в `no`).
-
-| `kind` | `op` (допустимые) | Поля | Что проверяет |
-|---|---|---|---|
-| `TAG` | `HAS`, `NOT_HAS` | `value` — метка `[a-z0-9_-]{1,64}` | есть ли у пользователя тег |
-| `VARIABLE` | `EQUALS`, `NOT_EQUALS`, `CONTAINS`, `NOT_EMPTY`, `EMPTY`, `GT`, `LT` | `key` — имя переменной `[a-z_][a-z0-9_]{0,63}`, `value` | значение переменной (`GT`/`LT` — числовое сравнение) |
-| `UTM` | `EQUALS`, `CONTAINS`, `NOT_EMPTY`, `EMPTY` | `key` ∈ `source`/`medium`/`campaign`/`content`/`term`, `value` | UTM-метку клика (`utm_<key>`), регистронезависимо |
-| `NAME` | `EQUALS`, `CONTAINS`, `NOT_EMPTY`, `EMPTY` | `value` | имя из профиля, регистронезависимо |
-| `EMAIL` | `EQUALS`, `CONTAINS`, `NOT_EMPTY`, `EMPTY` | `value` | email из профиля |
-| `PHONE` | `EQUALS`, `CONTAINS`, `NOT_EMPTY`, `EMPTY` | `value` | телефон из профиля |
-| `USERNAME` | `EQUALS`, `CONTAINS` | `value` | @username пользователя Telegram |
-| `SUBSCRIBED` | `SUBSCRIBED`, `NOT_SUBSCRIBED` | `key` — **числовой** id канала/группы (напр. `-1001234567890`); узнать числовой id подключённых каналов: `list_channels(botId)` | подписан ли пользователь на канал бота |
-| `LINK_CLICKED` | `CLICKED`, `NOT_CLICKED` | `key` — **`id` узла-шага** с отслеживаемой URL-кнопкой (тот же UUID, что у `SEND_MESSAGE`) | кликал ли пользователь по ссылке этого шага |
-| `CURRENT_DATE` | `BEFORE`, `AFTER`, `EQUALS` | `value` — дата `YYYY-MM-DD` | сегодняшнюю дату (МСК) |
-| `CURRENT_TIME` | `BETWEEN` | `value`, `value2` — время `HH:mm` | текущее время в интервале (через полночь — если `value`>`value2`) |
-| `DAY_OF_WEEK` | `IN` | `days` — массив из `MON`,`TUE`,`WED`,`THU`,`FRI`,`SAT`,`SUN` | день недели (МСК) |
-
-Для `NOT_EMPTY`/`EMPTY` поле `value` не нужно. `UTM` без `key` всегда `false`.
-
-**`SUBSCRIBED`** работает только если бот **админ** в канале/группе и канал «привязан» (бот узнаёт о членстве через хук `my_chat_member` — добавь бота в канал админом). `key` должен парситься в число, иначе условие = `false`. Профильные поля (`NAME`/`EMAIL`/`PHONE`) и UTM заполняются по ходу воронки (`ASK_QUESTION`→`saveTo`, диплинк-клик с UTM).
-
-**`LINK_CLICKED`** проверяет факт клика по URL-кнопке конкретного шага. Чтобы условие работало: у нужного `SEND_MESSAGE` хотя бы одна кнопка `kind:"URL"` с `"track": true`, а в условии `key` = `id` этого узла-шага. Клик фиксируется через публичный редирект бота, поэтому условие имеет смысл ставить **после** `DELAY`/`ASK_QUESTION` (дай пользователю время кликнуть).
-
-> **Платформа MAX.** Боты конструктора умеют работать и в мессенджере MAX. Там не поддерживаются `SUBSCRIBED`/`NOT_SUBSCRIBED` (нет членства в каналах) и reply-клавиатуры; публикация такого графа на MAX-бот вернёт **мягкие предупреждения** (не блокирует). Для Telegram-ботов всё работает как описано.
-
-## Платформа Instagram
-
-> **Сейчас Instagram выключен в сервисе:** IG-бота не подключить, страница `/bots/instagram` ведёт на `/bots`. Раздел оставлен на будущее включение.
-
-IG-боты подключаются через OAuth на странице **`/bots/instagram`** (раздел «Подключения» → карточка
-Instagram; прежний раздел «Инструменты роста» / `/growth` расформирован и редиректит) — **без вставки токена вручную**; у IG нет персонального бот-токена. После OAuth бот получает доступ к Messaging API через привязанный Instagram Business/Creator-аккаунт.
-
-### Разрешённые типы узлов для IG-ботов
-
-Только следующие (всё остальное — ошибка `IG_NODE_UNSUPPORTED` при публикации):
-
-| Тип | Доступен в IG |
-|---|---|
-| `TRIGGER_IG_COMMENT`, `TRIGGER_IG_DM`, `TRIGGER_IG_STORY_REPLY`, `TRIGGER_IG_STORY_MENTION` | ✅ (триггеры входа) |
-| `SEND_MESSAGE`, `SEND_PHOTO` | ✅ |
-| `BRANCH`, `CONDITION`, `SWITCH`, `STOP_AND_ERROR` | ✅ |
-| `SET_VARIABLE`, `ADD_TAG`, `REMOVE_TAG`, `FORMULA` | ✅ |
-| `ASK_QUESTION` | ✅ (с ограничениями — см. ниже) |
-| `DELAY` | ✅ (не более 24ч — см. ниже) |
-| `END` | ✅ |
-| `TRIGGER_COMMAND`, `TRIGGER_CALLBACK`, `TRIGGER_TEXT` | ❌ |
-| `BROADCAST_FILTER` (рассылки) | ❌ |
-| `SCHEDULE`, `ACTIONS`, `CALL_WEBHOOK`, `AI_REPLY`, `PAYMENT_LINK`, `YOOKASSA_PAYMENT` | ❌ |
-| `TRIGGER_PAYMENT` | ❌ |
-
-### Ограничения IG-ботов
-
-- **Нет команд** — вход только через `TRIGGER_IG_COMMENT` / `TRIGGER_IG_DM` / `TRIGGER_IG_STORY_REPLY` / `TRIGGER_IG_STORY_MENTION`. `/start` и другие команды не поддерживаются.
-- **Нет рассылок** — `BROADCAST_FILTER` недоступен.
-- **DELAY не более 24 часов** — Instagram доставляет сообщения только в течение 24-часового окна после последнего входящего действия (`IG_DELAY_OVER_24H`). `DELAY` с `kind=TOMORROW` или `kind=UNTIL` блокируются (они заведомо > 24ч). `kind=FIXED` с `durationSec > 86400` тоже блокируется.
-- **`ASK_QUESTION`** — `inputKind`: `TEXT`, `EMAIL`, `PHONE`, `NUMBER`, `CONTACT` (`IG_INPUT_UNSUPPORTED` для остальных). `CONTACT` допустим: кнопки «Поделиться номером» в IG нет, поэтому бот отправляет текст-инструкцию и принимает номер, набранный вручную (как телефон). Нельзя запрашивать `LOCATION`, `PHOTO`, `DOCUMENT`.
-- **Нет reply-клавиатур** — кнопки IG работают как inline (URL или Deep Link); стиль кнопок ограничен возможностями IG Messaging API.
-- **Нет SUBSCRIBED** — условие «подписан на канал» недоступно.
-- **Коммент → ЛС (Private Reply)** — на `SEND_MESSAGE`/`SEND_PHOTO` в графе с `TRIGGER_IG_COMMENT` укажи `"igReplyChannel": "dm"`, чтобы ответить автору комментария в Direct (а не публично под постом). По умолчанию (`"comment"`) — публичный ответ. Подробнее — `igReplyChannel` в разделе «Сообщения». **`"comment"` тоже требует, чтобы шаг был достижим от `TRIGGER_IG_COMMENT`** — иначе ошибка валидации `IG_COMMENT_REPLY_NO_COMMENT_TRIGGER` (в DM/story-флоу отвечать в комментарии некуда).
-
-### Оффлайн-проверка IG-графа
-
-```bash
-node validate.mjs graph.json --platform=INSTAGRAM
-```
-
-Ловит `IG_NODE_UNSUPPORTED`, `IG_DELAY_OVER_24H`, `IG_INPUT_UNSUPPORTED` — в дополнение ко всем обычным структурным проверкам.
-
-## Кросс-платформенное копирование (Telegram ⇄ MAX)
-
-Инструмент `copy_graph` копирует граф в **другого бота** пользователя (`targetBotId`), в т.ч. на другую платформу. Формат графа один и тот же; различается лишь платформа бота-получателя. При копировании в MAX-бот несовместимые узлы **адаптируются**, отчёт — в `notes[]`:
-
-| code | severity | что значит |
-|---|---|---|
-| `MAX_CONTACT_AS_TEXT` | TRANSFORM | вопрос с `inputKind=CONTACT` переписан в `inputKind=TEXT` + `validator=PHONE` (в MAX нет кнопки «поделиться контактом»; иначе узел стал бы тупиком) |
-| `MAX_SUBSCRIBED_ALWAYS_NO` | MANUAL | условие `SUBSCRIBED` оставлено как есть, но в MAX всегда «не подписан» — проверьте ветвление вручную |
-| `MAX_VOICE_AS_AUDIO` | INFO | голосовое уйдёт обычным аудио |
-| `MAX_VIDEO_NOTE_AS_VIDEO` | INFO | кружок уйдёт обычным видео |
-| `MAX_GALLERY_AS_ATTACHMENTS` | INFO | галерея уйдёт одним сообщением с вложениями |
-| `MAX_DELETE_NOOP` | INFO | действие «удалить сообщение» в MAX игнорируется |
-
-`preview: true` возвращает только `notes[]` (без копирования). Копирование в Telegram-бота (или в бота той же платформы) — точная копия, `notes[]` пустой. Новый граф создаётся как `DRAFT` с именем «… (copy)». Копировать в тот же бот нельзя (для дублирования — `clone_graph`).
-
-## Выходные хэндлы (`sourceHandle`) — шпаргалка
-| Узел | Хэндлы |
-|---|---|
-| обычный поток | `next` |
-| кнопки сообщения (`buttons`) | `btn_0`, `btn_1`, … (по индексу кнопки, плоско по всем рядам) |
-| `CONDITION` | `yes`, `no` |
-| `BRANCH` | `case_<id>`, `default` |
-| `ASK_QUESTION` | `valid`, `invalid` |
-| `SEND_MESSAGE` с `awaitReply:true` | `valid`, `invalid` (+ `btn_N` для кнопок) |
-| `CALL_WEBHOOK` | `ok`, `error` |
-| `ACTIONS` | `next`, плюс `error` — если внутри есть действие, которое может упасть (внешний запрос, CRM, Таблицы); `taken` — слот `booking_book` занят |
-| `SWITCH` | `case_<id>`, `default` |
-| `STOP_AND_ERROR` | выходов нет (терминатор) |
-| `SCHEDULE` | `scheduled`, `past` |
-| `DELAY` | `next`; у `UNTIL` ещё `late` (момент уже прошёл) и `error` (шаблон не разобрался как дата) |
-| `AI_REPLY` (`mode` не задан/`simple`) | `next`, `error` |
-| `AI_REPLY` (`mode:"agent"`) | `answered`, `action_<id>` (по числу `actions[]`), `unknown`, `budget_exhausted`, `error` — **выхода `next` нет** |
-
-## Подстановки в тексте
-`{{from.first_name}}`, `{{from.username}}`, `{{var.<имя>}}`, либо `{Имя}` как плейсхолдер. Имена переменных/меток: `[a-z_][a-z0-9_]{0,63}` (var) и `[a-z0-9_-]{1,64}` (tag).
+# Формат графа `retensy-bot-graph`
+
+## Контейнер импорта
+```json
+{
+  "format": "retensy-bot-graph",
+  "version": 1,
+  "name": "Название воронки",
+  "nodes": [ /* TgNode[] */ ],
+  "edges": [ /* TgEdge[] */ ],
+  "canvasMeta": {}
+}
+```
+При заливке через MCP в `update_graph` передаются только `nodes`, `edges`, `canvasMeta`, `name`.
+
+## Узел (TgNode)
+```json
+{ "id": "<uuid>", "type": "<NodeType>", "config": { ... }, "position": { "x": 0, "y": 0 } }
+```
+- `id` — валидный UUID (8-4-4-4-12), уникальный.
+- `position` — раскладка на холсте (слева направо: шаг x ≈ 420; ветки разносим по y).
+
+## Ребро (TgEdge) — «стрелка»
+```json
+{ "id": "<uuid>", "sourceNodeId": "<uuid>", "sourceHandle": "next", "targetNodeId": "<uuid>" }
+```
+`sourceHandle` — какой выход узла используется (см. ниже).
+- `id`, `sourceNodeId`, `targetNodeId` — **валидные UUID** (бэкенд десериализует их как `java.util.UUID`; короткая строка вроде `"m1"` → HTTP 400 при заливке). `id` уникален среди рёбер.
+
+## Типы узлов (NodeType) и их config
+
+### Триггеры (точки входа, корневые)
+
+#### Telegram / MAX
+- `TRIGGER_COMMAND` — `{ "isRoot": true, "command": "start" }` (команда без `/`). Первый — с `isRoot:true`.
+- `TRIGGER_CALLBACK` — `{ "matchMode": "EQUALS"|"STARTS_WITH", "value": "<callback_data>" }`
+- `TRIGGER_TEXT` — `{ "matchMode": "ANY"|"EQUALS"|"CONTAINS"|"REGEX", "value": "..." }`
+- `BROADCAST_FILTER` — режим рассылки (если есть — единственный триггер).
+- `TRIGGER_PAYMENT` («Оплата прошла») — в кассе владельца прошла оплата: ЮKassa или подключённые через
+  `connect_integration` CloudPayments, Robokassa, Т-Банк, Prodamus, bePaid (подтверждённая оплата этих касс
+  нормализуется к тому же виду).
+  `{ "minAmount": "1000", "descriptionContains": "курс" }` — оба фильтра необязательны.
+  **Ставь хотя бы один фильтр:** без них сценарий будет запускаться на КАЖДУЮ оплату в кассе.
+  В контексте: `{{payment.id}}`, `{{payment.amount}}`, `{{payment.status}}`,
+  `{{payment.description}}`, `{{payment.currency}}`, `{{payment.provider}}` (какая касса), плюс весь документ платежа
+  как `body`.
+  Запуск — один раз на платёж: повторные уведомления кассы о той же оплате сценарий не перезапускают. Сюда же приходит оплата счёта, пришедшая уже после `timeout` блока со счётом, — в диалоге того подписчика (пока бот выключен, оплата ждёт повтора ЮKassa).
+  - **Счёт выставлял бот** (действие `issue_invoice`) → подписчик определяется САМ: счёт
+    помнит его в `metadata` платежа. Прогон идёт в обычной сессии — можно прямо ставить
+    «Отправить сообщение» и «Добавить метку», указывать получателя и разбирать ответ кассы
+    не нужно. Это штатный способ «оплатил → выдать доступ», когда ждать в сценарии не хочется.
+  - **Оплата мимо бота** (ссылка из рассылки, счёт из кабинета ЮKassa) → получателя нет,
+    прогон headless: узлы отправки адресуй через `config.target`, либо пиши в CRM и таблицы.
+  ⚠️ Если оплату надо дождаться ПРЯМО в диалоге, триггер не нужен — веди ветку `paid`
+  от блока `ACTIONS` со счётом.
+- `TRIGGER_TG_EVENT` — любое событие Telegram, кроме обычного сообщения: вступил/вышел из канала,
+  реакция, буст, заявка в закрытую группу, ответ в опросе и т.п.
+  `{ "event": "<имя поля Update>", "filter": { ... }, "priority": 0 }`.
+  Рабочие `event` (бэкенд их размечает, остальные молчат): `message`, `edited_message`,
+  `callback_query`, `channel_post`, `edited_channel_post`, `chat_member`, `chat_join_request`,
+  `my_chat_member`, `message_reaction`, `message_reaction_count`, `chat_boost`,
+  `removed_chat_boost`, `poll`, `poll_answer`, `inline_query`, `chosen_inline_result`,
+  `shipping_query`, `pre_checkout_query`.
+  **НЕ работают** (Telegram их шлёт, но рантайм не разбирает): `business_*`, `chat_shared`,
+  `users_shared`, `write_access_allowed`, `purchased_paid_media` — такой триггер не сработает.
+  `filter` (все условия по И, пустое = не задано):
+  `{"status":"member"|"left"|"kicked"|…}` — только там, где есть `member.status`
+  (`chat_member`, `my_chat_member`); `{"chatId":"-1001234567890"}` — конкретный чат/канал
+  (сравнение строкой, id каналов не влезают в int), доступен у 12 событий с `chat`;
+  `{"text":"купить","textMode":"contains"|"equals"}` — только `message`/`edited_message`/
+  `channel_post`/`edited_channel_post`. У `poll`/`poll_answer`/`inline_query`/
+  `chosen_inline_result`/`shipping_query`/`pre_checkout_query` чата нет → фильтров тоже.
+  Бот должен быть админом канала/группы, иначе события оттуда не придут.
+- `TRIGGER_ANY_UPDATE` — `{}`, ловит ЛЮБОЙ апдейт. Приоритет самый низкий: срабатывает, только
+  если не подошёл ни один конкретный триггер. Удобен как «ничего не понял» / отладка.
+- `TRIGGER_WEBHOOK` — `{}`, точка входа сценария с источником WEBHOOK (не бот). Такие сценарии
+  создаются в вебе; у графа бота этот триггер не сработает.
+  - **Внешние события интеграции** — тот же `TRIGGER_WEBHOOK`, но с заполненными
+    `{ "provider": "<provider-ключ из integration_catalog, нижний регистр>", "connectionId": "<id из list_integrations>",
+    "event": "<events[].key нужного события из inbound.events того же provider в integration_catalog>" }`.
+    Без `provider`+`connectionId` узел — обычный вебхук с произвольным телом; с ними URL ингресса
+    (`integration_ingress_url`) ведёт на обработчик конкретного провайдера, и запрос принимается только
+    в формате, который он понимает (подпись/HMAC сервиса проверяется на бэке). Переменные события —
+    `{{body.<ключ>}}`, ключи и примеры — в `inbound.events[].vars` того же события каталога.
+    amoCRM шлёт пачку сущностей одним запросом (`leads[add][0..n]`, `leads[status]`, `contacts[add]`) — сценарий
+    запускается по КАЖДОЙ сущности отдельно (порядок: сделки добавлены → смена этапа → контакты), не только по первой.
+    `event: "<key>"` с `paymentSucceeded:true` (кассы ЮKassa/CloudPayments/Robokassa/Т-Банк/Prodamus/bePaid) помимо
+    этого же `{{body.<ключ>}}`-прогона ЕЩЁ запускает узел «Оплата прошла» ваших графов — headless (без чата)
+    либо в чате подписчика, если платёжную ссылку выдавало действие `*_link`/`issue_invoice` с привязкой
+    к нему. Тестовый/demo-платёж (`test_mode`/`demo_mode` в переменных) прогоняет только обычный вебхук —
+    «Оплата прошла» на нём не срабатывает.
+- `TRIGGER_SITE_FORM` — `{ "siteId": "<uuid сайта>", "formId": "<id формы>" }` — заявка с формы
+  опубликованного сайта владельца. `formId` пустой/нет = любая форма сайта. `siteId` обязателен
+  (`SITE_FORM_NO_SITE`), сайт должен быть свой (`SITE_FORM_FOREIGN_SITE`). Переменные: поля формы
+  `{{var.<имя>}}`, всегда `{{var.name}}`/`{{var.email}}`/`{{var.phone}}` (по имени поля, иначе по подписи),
+  UTM `{{var.utm_*}}`. Прогон без чата: узлы отправки — только с `config.target`. Работает и в сценарии
+  без бота (источник WEBHOOK — тогда `TRIGGER_WEBHOOK` не обязателен), и в сценарии бота; не для Instagram.
+- `TRIGGER_SCHEDULE` — `{ "cron": "0 9 * * 1-5", "timezone": "Europe/Moscow" }` — запуск сценария по расписанию:
+  cron из 5 полей (минута час день месяц день-недели), не чаще раза в минуту; зона по умолчанию `Europe/Moscow`.
+  Прогон **headless** (без чата): узлы отправки — только с явным `config.target`, действия, которым нужен
+  подписчик, пропускаются; время срабатывания — `{{schedule.at}}`. Запуски, пропущенные во время простоя сервиса,
+  не догоняются. Работает в опубликованном активном сценарии (бота или вебхук-сценарии). Журнал — `scenario_runs`.
+- ~~`TRIGGER_COMMENT`~~ — **мёртвый тип**: рантайм нигде не выставляет `event="comment"`, сработать
+  он не может. Убран из палитры редактора. Комментарии Instagram — `TRIGGER_IG_COMMENT`.
+
+#### Instagram (только для IG-ботов)
+IG-боты не поддерживают команды (`/start`). Вход — через взаимодействие с контентом или директ:
+- `TRIGGER_IG_DM` — `{ "isRoot": true, "keywords": "хочу, каталог" }` — входящее сообщение в Instagram Direct. Это дефолтный триггер нового IG-графа (бэкенд сеет его при создании). `keywords` (опц.) — список через запятую или с новой строки; **регистронезависимо, совпадение по вхождению (contains)**; пусто = любое сообщение.
+- `TRIGGER_IG_COMMENT` — `{ "isRoot": true, "keywords": "купить, цена" }` — комментарий к посту или Reel бота. `keywords` (опц.) — список через запятую или с новой строки; регистронезависимый contains; пусто = любой комментарий.
+- `TRIGGER_IG_STORY_REPLY` — `{ "isRoot": true, "keywords": "хочу, вопрос" }` — ответ на историю бота. `keywords` (опц.) — список через запятую или с новой строки; регистронезависимый contains; пусто = любой ответ.
+- `TRIGGER_IG_STORY_MENTION` — `{ "isRoot": true }` — упоминание бота в истории подписчика. **Текста нет → фильтрация по ключевым словам не применяется**; срабатывает на каждое упоминание независимо от содержимого истории.
+
+> **Разные слова — разные сценарии:** добавь **несколько триггеров одного типа** с разными `keywords`; бэкенд берёт **первый совпавший по порядку узлов**. Триггер-«ловушку» с пустыми `keywords` (ловит всё) ставь **последним** — иначе он заблокирует все нижестоящие ключевые слова.
+
+Для всех IG-триггеров реакция бота отправляется через Instagram Messaging API в течение **24-часового окна** после последнего входящего действия пользователя.
+
+### Сообщения
+- `SEND_MESSAGE` —
+  ```json
+  { "_title": "Заголовок узла", "parseMode": "PLAIN"|"HTML"|"MARKDOWN",
+    "text": "Текст сообщения",
+    "cards": [ { "id": "c1", "type": "text", "text": "Текст сообщения" } ],
+    "buttons": [ [ { "text": "Кнопка", "kind": "CALLBACK"|"URL", "value": "<url для URL; ПУСТО для CALLBACK>", "color": "", "track": true } ] ] }
+  ```
+  ВСЕГДА заполняй и `text`, и `cards[0].text` одинаково. `buttons` — массив рядов (каждый ряд — массив кнопок).
+  - **Медиа-карточки** (`cards[].type`): `text`, `image`, `video`, `audio`, `file`, `voice`, `videonote` (кружок), `gallery` (альбом 2–10 фото), `question` (вопрос). У медиа-карточки ссылка на файл лежит в поле `url` (у `gallery` — массив `urls`). Сам файл (фото/видео/документ) в графе НЕ хранится — только URL. Чтобы получить URL, сперва загрузи файл инструментом **`upload_file`** (`path` локального файла или `url` для перезаливки) — он кладёт файл в библиотеку **/bots/files** и возвращает публичный `url`; его и вставляй в карточку. Примеры: `{ "id":"c2","type":"image","url":"https://bots.retensy.com/media/botmedia/<id>.jpg","text":"подпись (опц.)" }`, видео/аудио/файл/`voice`/`videonote` — так же с `url`; галерея — `{ "type":"gallery","urls":["https://…","https://…"] }`. Уже загруженные файлы — `list_files`, удалить — `delete_file`. Лимит 50 МБ; типы: image/video/audio/pdf/zip/doc(x)/xlsx/pptx/txt (SVG нельзя).
+  - `parseMode:"HTML"` (дефолт редактора) — текст должен быть **безопасным Telegram-HTML**: разрешены только `b,strong,i,em,u,ins,s,strike,del,code,pre,a[href],tg-spoiler,br`. Любой другой тег/атрибут → ошибка публикации `HTML_NOT_SAFE`. Не уверен — ставь `PLAIN`.
+  - **Кнопки-выборы (`kind:"CALLBACK"`)**: `value` ОСТАВЛЯЙ ПУСТЫМ (`""`). Бот сам сгенерит `callback_data` вида `n:<id узла>:<индекс>`, а переход задаётся ребром `btn_N` от кнопки. **Непустой `value`** трактуется как legacy-`callback_data` для отдельного узла `TRIGGER_CALLBACK` (у такой кнопки ребра `btn_N` быть не должно) — если поставить `value` обычной кнопке-выбору, переход по `btn_N` **сломается** (нажатие → `NO_MATCH`).
+  - **Кнопки-ссылки (`kind:"URL"`)**: `value` = URL. Могут иметь `"track": true` — клики считаются, и на такой шаг можно сослаться из условия `LINK_CLICKED` (см. ниже).
+  - **`color`** (опционально, и у CALLBACK, и у URL) — только стили, которые рендерит Telegram (как в основном боте / pengrad `ButtonStyle`): `""`=по умолчанию, `"#2EA6FF"`=primary (синий), `"#34C759"`=success (зелёный), `"#FF3B30"`=danger (красный). Других цветов нет.
+  - **Режим «Вопрос» (`awaitReply: true`)** — сообщение задаёт вопрос и ждёт ответ (паркуется как `ASK_QUESTION`). Доп. поля: `"saveTo":"name"` (обязателен, `[a-z_][a-z0-9_]{0,63}`), `"inputKind":"TEXT"|"PHOTO"|"DOCUMENT"|"CONTACT"|"LOCATION"`, `"validator":"ANY"|"PHONE"|"EMAIL"|"REGEX"`, `"regex":"..."`, `"retryText":"..."`, `"maxAttempts":3`. Выходы — `valid` / `invalid` (как у `ASK_QUESTION`), плюс `btn_N` для кнопок.
+  - **Канал ответа Instagram (`igReplyChannel`, только для IG-ботов)** — `"comment"` (по умолчанию) — публичный ответ под комментарием; `"dm"` — личное сообщение автору комментария (Private Reply). `"dm"` срабатывает только в графе с `TRIGGER_IG_COMMENT` (нужен `comment_id`): Meta разрешает **1 ЛС на комментарий**, 24-часовое окно на private reply не распространяется. Чтобы ответить и публично, и в ЛС — поставь два шага: один с `"igReplyChannel":"comment"`, второй с `"igReplyChannel":"dm"`.
+- `SEND_PHOTO` — `{ "photoUrl": "https://...", "caption": "подпись (необязательно, ≤1024)", "igReplyChannel": "comment"|"dm" }` (`igReplyChannel` — только IG, см. `SEND_MESSAGE`). `photoUrl` можно получить через `upload_file`.
+
+### Логика / ветвление
+- `CONDITION` — проверка условий, выходы `yes` / `no`. `{ "match":"ALL"|"ANY", "conditions":[ { "kind":"...", "op":"...", "key":"...", "value":"..." } ] }`. `match:"ALL"` — все условия истинны; `"ANY"` — хотя бы одно. Полный список `kind`/`op`/полей — в разделе [«Условия CONDITION»](#условия-condition).
+- `BRANCH` — `{ "cases":[ {"id":"c1","label":"...","expression":"var.x=='a'"} ], "hasDefault": false, "abTest": false }`. Выходы: `case_<id>` (+ `default`).
+- `SWITCH` — развилка по ЗНАЧЕНИЮ, когда веток больше двух.
+  `{ "expression":"{{var.http_status}}", "cases":[ {"id":"v1","value":"200","label":"Успех"},
+  {"id":"v2","value":"404","label":"Не найдено"} ] }`. Выходы: `case_<id>` + `default` (есть всегда).
+  Выражение рендерится как шаблон (обычно просто `{{var.x}}`) и сравнивается со `value` каждого
+  случая **без учёта регистра и пробелов по краям**; первое совпадение выигрывает, иначе `default`.
+  Отличия: `CONDITION` — бинарное да/нет, `BRANCH` — случайный выбор (A/B), `SWITCH` —
+  детерминированный выбор по значению. Валидатор режет: пустое `expression`
+  (`SWITCH_NO_EXPRESSION`), нет случаев (`SWITCH_NO_CASES`), пустое `value` (`SWITCH_EMPTY_VALUE`),
+  повтор значения (`SWITCH_DUPLICATE_VALUE`), случай без ребра (`SWITCH_CASE_UNCONNECTED`).
+  Ребро на `default` необязательно.
+- `STOP_AND_ERROR` — `{ "message":"CRM не ответила: {{var.http_status}}" }`. Обрывает прогон и
+  помечает его в журнале как ошибочный (`FAILED`), шаг — `ok:false` с этим текстом. Выходов нет,
+  ничего подписчику не отправляет. Пустой `message` → «Сценарий остановлен с ошибкой».
+- `ASK_QUESTION` — вопрос со сбором ответа. `{ "promptText":"...","saveTo":"name","inputKind":"TEXT"|"PHOTO"|"DOCUMENT"|"CONTACT"|"LOCATION","validator":"ANY"|"PHONE"|"EMAIL"|"REGEX","regex":"...","retryText":"...","maxAttempts":3 }`. `inputKind` (по умолчанию `TEXT`) — что ждём в ответ (`CONTACT` → телефон: в Telegram показывается кнопка «Поделиться номером», в MAX/Instagram кнопки нет — номер вводится вручную и принимается как телефон на всех платформах; `LOCATION` → `lat,lon`, `PHOTO`/`DOCUMENT` → file_id). Выходы `valid` / `invalid`.
+- `END` — `{}` (конец ветки). **Не добавляй `END`**: ветка и так завершается на узле без исходящих рёбер; явный «конец сценария» бесполезен и убран из палитры редактора. Тип оставлен лишь для совместимости со старыми графами.
+
+### Тайминги
+- `DELAY` — пауза. Три вида (`kind`):
+  - **`FIXED`** («Отправить через»): `{ "kind":"FIXED", "durationSec": 86400 }` — `durationSec` в **секундах** (60 = 1 мин, 3600 = 1 час, 86400 = 1 сутки). Редактор также пишет `{ "kind":"FIXED", "duration": 24, "unit":"MINUTES"|"HOURS"|"DAYS" }` (минуты/часы/дни — чтобы не вбивать большие числа). Для генерации проще `durationSec`.
+  - **`TOMORROW`** («Отправить завтра»): `{ "kind":"TOMORROW", "time":"18:00" }` — завтра в указанное время `HH:mm` (МСК), относительно момента, когда пользователь дошёл до узла.
+  - **`UNTIL`** («Отправить в»): `{ "kind":"UNTIL", "isoTimestamp":"2026-06-25T15:00:00Z" }` — конкретный момент в ISO-8601. ⚠️ Рантайм читает только `isoTimestamp`; пары `isoDate`+`time` НЕ работают. Можно шаблон из переменной и смещение: `{ "kind":"UNTIL", "isoTimestamp":"{{var.slot_at}}", "offset":"-24h", "timezone":"Europe/Moscow" }` — «за сутки до записи» (`offset`: `-30m`, `+1d`, единицы s/m/h/d/w; дата без зоны читается в `timezone`, по умолчанию Москва). Момент уже прошёл → выход `late`, если ребро нарисовано, иначе шаг выполняется сразу (`snapshot.lateBy`). Шаблон не разобрался как дата → выход `error`.
+- `SCHEDULE` — `{ "isoDate":"2026-06-25", "time":"18:00", "timezone":"Europe/Moscow" }`. Выходы `scheduled` / `past`. `isoDate` может быть и ISO дата-временем или шаблоном (`"{{var.slot_at}}"`, тогда `time` не нужен) + `offset` как у `DELAY UNTIL`.
+- Прогон без пауз (между `DELAY`, `ASK_QUESTION`/`awaitReply`, ожиданием оплаты) ограничен **5 минутами**: дольше — рантайм обрывает его с ошибкой шага `run deadline exceeded` (прогон `FAILED`, пауза подписчика снята). Длинные цепочки `external_request` / `CALL_WEBHOOK` / `AI_REPLY` разноси `DELAY` — после паузы начинается новый прогон.
+- Массовый одинаковый момент срабатывания (`TOMORROW`/`UNTIL`/`SCHEDULE` у тысяч подписчиков одного бота) расходится постепенно: до 10 срабатываний на бота в секунду, время растёт с аудиторией (≈100 с на 1000 подписчиков, ≈17 мин на 10 000), другие боты не ждут. Не рассчитывай, что все получат сообщение в одну секунду.
+- Если Telegram вернул боту 429 (`retry after N`, пауза не дольше часа), срабатывания `DELAY`/`SCHEDULE` и рассылки этого бота (и по `BROADCAST_FILTER`, и прямые) ждут конца паузы; после такой паузы рассылка продолжается без потерь и без повтора уже доставленного. Это только про паузу 429: если сервис перезапустился посреди отправки, получатель, на котором её прервали, через ≤15 мин может получить рассылку (или прогон сценария) повторно. Ответ подписчику в живом диалоге отправляется сразу, без ожидания; если Telegram откажет снова, шаг уходит в ветку «Ошибка», если она проведена, иначе дальше по обычному выходу.
+- `AI_REPLY` при сбое провайдера (5xx, таймаут) уходит в `error` примерно через минуту — не рассчитывай на долгое ожидание ответа модели.
+
+### Состояние / действия
+- `SET_VARIABLE` (`{ "key":"name", "value":"..." }`), `ADD_TAG`/`REMOVE_TAG` (`{ "tag":"lead" }`), `FORMULA` (`{ "expression":"...", "saveTo":"name" }`)
+- `ACTIONS` — непустой пакет действий `{ "actions":[ { "kind":"...", ...поля } ] }`. Допустимые `kind` (иначе ошибка `ACTION_UNKNOWN_KIND`):
+  - **метки/автоворонки**: `add_tag`, `remove_tag`, `autoflow_add`, `autoflow_remove` — поле `tag` (`[a-z0-9_-]{1,64}`)
+  - **профиль**: `set_field` — `key` (`[a-z_][a-z0-9_]{0,63}`) + `value`; `subscribe`, `unsubscribe`
+  - **HTTP**: `external_request` — **основной способ сходить в чужой API**, те же поля и возможности,
+    что у узла `CALL_WEBHOOK`: `url` + `method`/`headersJson`/`bodyTemplate`/`timeoutMs` +
+    `saveStatusTo`/`saveBodyTo`/`extract`. Отличие одно: своих выходов у действия нет — сбой уводит
+    ВЕСЬ блок `ACTIONS` в его выход `error` (если ребро нарисовано; нет — идём по `next`), а
+    ветвиться по коду ответа надо следующим блоком `SWITCH`. **Платное действие** (как `CALL_WEBHOOK`):
+    на бесплатном тарифе публикация падает с `PREMIUM_NODE_FORBIDDEN`.
+    Ещё есть `subscriber_webhook` — `url` + `method`/`headersJson`/`bodyTemplate`
+  - **уведомления**: `notify` (`text`) — владельцу бота в бот уведомлений из его профиля (Telegram/MAX); не подключён → действие не удалось, блок уходит в `error`; `subscriber_email` (`email`,`text`)
+  - **письмо подписчику**: `send_email` — `email` (обязательно, один адрес — не список; шаблон `{{var.*}}` допустим), `subject`, `text` (обязательно; только обычный текст — HTML не поддерживается, теги уходят в письме экранированными как есть), опц. `replyTo`. Антиабуз: невалидный `email`/`replyTo`, пустой `text`, суточный лимит писем на владельца И на весь сервис, или сбой SMTP → действие не удалось, блок уходит в `error`; отправитель — всегда свой аккаунт сервиса (открытого релея нет).
+  - **передача оператору**: `agent_chat` (без полей) — «позвать человека»: диалог встаёт на паузу (бот и ИИ молчат, входящие копятся в «Диалогах»), владельцу уходит уведомление; без бота уведомлений действие помечается `NOT_CONFIGURED`, пауза всё равно включается. Вернуть боту — кнопка в «Диалогах» или MCP `dialog_handoff {active:false}`. В dry-run и headless-прогонах пропускается.
+  - **срок ответа оператора (SLA)**: `sla_check` — опц. `maxLevel` (0 — без потолка), `timezone` (для `sla_at`, по умолч. Europe/Moscow). Ставь первым в блоке `ACTIONS` после `DELAY` на срок ответа, ниже в том же блоке — эскалация (`add_tag`, `notify`). Оператор не писал в чат после `agent_chat` → `sla_breached`=`1`, `sla_level` +1, `sla_at` — ISO со смещением, действия блока выполняются; ответил / диалог у бота / тот же таймер повторно → `sla_breached`=`0`, остальные действия блока пропускаются. Новая передача — уровни с 1. Ветвиться дальше — `CONDITION` по `{{var.sla_level}}`.
+  - **запись на слоты** (календарь — `booking_calendar_create`/`booking_calendar_list`): `booking_slots` — `calendarId`, опц. `days` (1–62, по умолч. 7), `limit` (1–50, по умолч. 10), `saveTo` (по умолч. `slots`) → переменные `slots` (нумерованный список для сообщения), `slots_json`, `slots_count`; `booking_book` — `calendarId`, `slotAt` (по умолч. `{{var.slot_at}}`; можно номер из списка «2», ISO-время или подпись слота), опц. `slotsVar`, `name`/`phone` (по умолч. `{{var.name}}`/`{{var.phone}}`) → `booking_id`, `slot_at` (ISO с зоной — для напоминания `DELAY UNTIL {{var.slot_at}} offset -24h`), `slot_label`, `booking_status`; занятый слот → выход блока **`taken`** (если ребро нарисовано, иначе `error`); `booking_cancel` — `bookingId` (по умолч. `{{var.booking_id}}`), освобождает слот.
+  - **переход в другой сценарий**: `call_scenario` — `graphId` (сценарий ЭТОГО ЖЕ бота того же владельца, id из `list_graphs`; черновик тоже можно), опц. `nodeId` (стартовый блок цели; по умолч. триггер `/start` → первый триггер → первый блок без входящих рёбер — так стартует подсценарий без триггера), `variables: [{ "key":"plan", "value":"{{var.x}}" }]` (ключи `[a-z][a-z0-9_]{0,63}`, служебные `_*` запрещены — `ACTION_BAD_KEY`, в рантайме пропускаются, значения — шаблоны; сохраняются подписчику ДО перехода), `mode` — только `"goto"` (по умолч.). Подписчик уходит в целевой сценарий отдельным прогоном, текущий прогон завершается `OK`; ответы на вопросы и кнопки цели доходят до неё, хотя активный сценарий бота другой (`session.currentGraphId`). Ставь ПОСЛЕДНИМ в блоке (`CALL_SCENARIO_NOT_LAST`), не на себя (`CALL_SCENARIO_SELF`), только `goto` (`CALL_SCENARIO_BAD_MODE`), без цели — `CALL_SCENARIO_NO_TARGET`, чужой/несуществующий/вебхук-сценарий — `CALL_SCENARIO_FORBIDDEN` при публикации. В рантайме отказ = шаг `ok=false`, ошибка `CODE: call_scenario — …`, блок в `error` (нет ребра — `next`): `CALL_SCENARIO_RECURSION` (сценарий уже в цепочке переходов одного события), `CALL_SCENARIO_DEPTH` (> 5 переходов подряд), `CALL_SCENARIO_NOT_FOUND`, `CALL_SCENARIO_FORBIDDEN`, `CALL_SCENARIO_NO_ENTRY`, `CALL_SCENARIO_NO_SUBSCRIBER` (headless-вебхук), `NOT_CONFIGURED` (бэкенд в режиме развязанных сценариев — переход недоступен). Сбой более раннего действия блока не прячется переходом: шаг `ok=false` с кодом того сбоя, прогон `PARTIAL`, переход при этом выполняется. Цель-черновик исполняется как есть — правки черновика сразу видят подписчики, уже перешедшие в него. «Вызвать и вернуться» нет — для возврата поставь в конце цели свой `call_scenario` обратно (сработает, если между ними был ответ подписчика/задержка, иначе `RECURSION`).
+  - **контакт заявки**: `lead_link_contact` — `phone`/`email` (по умолч. `{{var.phone}}`/`{{var.email}}`) → склейка с единым контактом владельца по телефону E.164 или email, `{{var.contact_id}}`.
+  - **платный доступ / подписки** (бот должен быть админом группы/канала): `invite_link_create` — персональная ссылка на одно вступление: опц. `expireHours` (по умолч. 24), `name`, `saveTo` (по умолч. `invite_link`), `send` (false — не отправлять), `text`; `invite_link_revoke` — `link` (по умолч. `{{var.invite_link}}`); `subscription_extend` — `period` (`1mo`, `30d`, `1y`, `2w`, `12h`), опц. `var` (по умолч. `sub_until`), `timezone` — продлевает от max(сейчас, текущий срок); `subscription_check` — опц. `var`, `saveTo` (по умолч. `sub_active`) → `true`/`false`; `yookassa_charge_saved` — рекуррентное списание по сохранённому способу оплаты: `connectionId` (ЮKassa), `amount`, `description`, опц. `paymentMethodId` (по умолч. `{{var.yk_payment_method_id}}`), `periodKey` (по умолч. `{{var.sub_until}}` — защита от двойного списания за период). Доступ продлевает не списание, а сценарий `TRIGGER_PAYMENT` → `subscription_extend`.
+  - **Meta Conversions API** (Integration Core): `meta_capi_event` — `connectionId`, `eventName` (Purchase/Lead/…), опц. `dealId`, `stage`, `eventId`, `email`/`phone` (сырые — хешируются SHA-256), `value`, `currency`, `actionSource`. Поля других провайдеров — в `integration_catalog` (`actions[].inputs`).
+  - **Integration Core: поля и переменные-результаты** (все — с `connectionId`; пустое/неверное обязательное поле → действие не вызывает сервис, блок уходит в `error`):
+    - `ydelivery_price` (Яндекс Доставка) — ВСЕ поля обязательны: `fromLat`, `fromLon`, `toLat`, `toLon`, `fromAddress`, `toAddress` (город, улица, дом — без квартиры/подъезда), `weightKg`, `lengthCm`, `widthCm`, `heightCm` (габариты упаковки в см, > 0, запятая допустима). Без адресов или габаритов — ошибка (заглушек нет). → `ydelivery_price`, `ydelivery_currency`, `ydelivery_eta` (ISO-дедлайн).
+    - `cdek_tariff` (СДЭК) — `fromCity`, `toCity`, `weightGrams`, `tariffCode` → `cdek_price` (только доставка), **`cdek_total_sum`** (итог с доп. услугами, 2 знака — его показывай клиенту), `cdek_days_min`, `cdek_days_max`; `cdek_order_status` — `cdekNumber` → `cdek_status`.
+    - `moysklad_find_product` — `search` → `moysklad_product_name`, `moysklad_product_price`, **`moysklad_product_id`**; **`moysklad_product_stock`** — остаток: `productId` (обяз., UUID товара/модификации, обычно `{{var.moysklad_product_id}}`), опц. `stockType` (`stock` по умолч., `freeStock`, `quantity`, `reserve`, `inTransit`) → `moysklad_stock` (товар без движений — `0`). Дальше — `CONDITION` по `{{var.moysklad_stock}}`.
+    - `ymarket_order_status` (Яндекс Маркет) — `orderId` (число) → `ymarket_status` (PROCESSING, DELIVERY, DELIVERED, CANCELLED…), `ymarket_substatus` (этап/причина отмены). Подключение: `connect_integration` provider `yandex_market`, creds `{campaignId, apiKey}` (кабинет → Настройки → API и модули); businessId бэкенд определяет сам. Работает на `POST v1/businesses/{businessId}/orders` — ищет заказы за последние 30 дней, более старый → `error` «заказ не найден».
+    - **`unisender_send_sms`** — одиночное SMS: `phone` (с кодом страны), `sender` (альфа-имя 3–11 символов, зарегистрированное в Unisender), `text` (до 1000 символов) — все обязательны → `unisender_sms_id`. `unisender_subscribe` → `unisender_person_id`.
+    - `rest_api_call` — в `body` (JSON) `{{var.x}}` сам ставит кавычки строкам; число или boolean в переменной уходит своим типом (`{"qty": {{var.qty}}}` → `{"qty": 5}`). Тип — по значению переменной, не по виду строки: введённый текст из цифр (телефон) остаётся строкой.
+  - **бот/шаг**: `stop_bot`, `delete_step_message`, `cancel_payment_subscription`
+  - **Google Таблицы (работает)**: `gsheets_send` — дописать строку-заявку в таблицу: `{ "kind":"gsheets_send", "googleEmail":"me@gmail.com", "spreadsheetId":"<id таблицы>", "sheetName":"Лист1", "cells":["{{from.first_name}}","{{var.phone}}","{{var.email}}"] }`. `cells` — значения по порядку (шаблоны), бот дописывает их строкой в конец листа. Google-аккаунт подключается В ВЕБЕ (`/bots` → у действия кнопка «Подключить Google»), НЕ через MCP — у пользователя уже должен быть подключён `googleEmail`. Нужны `googleEmail` + `spreadsheetId` + непустой `cells[]` (иначе `ACTION_GSHEETS_INCOMPLETE`).
+    Остальные четыре действия с таблицами тоже РАБОТАЮТ и тоже требуют `googleEmail` + `spreadsheetId`:
+    `gsheets_get` (`range` → `saveTo`), `gsheets_update` (`range`, `values[]`), `gsheets_write_cell`
+    (`cell`, `value`), `gsheets_read_cell` (`cell` → `saveTo`; пустая ячейка не ошибка — переменная станет `""`).
+  - **CRM и внешние системы — РАБОТАЮТ** (реальные HTTP-клиенты на бэкенде, не заглушки).
+    Всем им нужен **`connectionId`** — id подключения пользователя; без него действие падает
+    «не выбрано подключение». **Узнать id: инструмент MCP `list_integrations`** (отдаёт
+    `{id, provider, title, hint}`; сами креды не отдаются). Значения полей — шаблоны
+    (`{{var.x}}`, `{{from.first_name}}`).
+    - `amocrm_send` — создать сделку (+контакт): `connectionId`, `leadName`, опц. `price`,
+      `pipelineId`, `statusId` (числа), `contactName`, `phone`, `email`. Если все три контактных
+      поля после рендера пусты — сделка уходит без контакта. В переменные кладёт `amo_lead_id`
+      и `amo_contact_id` (если amo его вернул).
+    - `amocrm_update` — частичное обновление сделки: `connectionId`, `leadId` (обычно
+      `{{var.amo_lead_id}}`), плюс те же `leadName`/`price`/`pipelineId`/`statusId`. Пустой
+      `leadId` или отсутствие полей для обновления — отказ.
+    - `bitrix24_call` — любой REST-метод Битрикс24: `connectionId`, **`b24method`** (именно так,
+      не `method` — это имя занято HTTP-методом «Внешнего запроса»), `fields` — список пар
+      `{key, value}` (ключ вида `fields[TITLE]` разворачивается во вложенную карту),
+      `extract` — список `{path, saveTo}` для JsonPath-извлечения ответа в переменные.
+    - `getcourse_send` — добавить/обновить пользователя: `connectionId`, `email`, опц. `userName`,
+      `phone`, `groups` (CSV групп), `addfields` (карта доп.полей). Повторная заявка обновляет,
+      а не дублирует.
+    - `getcourse_order` — создать заказ: те же поля пользователя + `offerCode`, опц. `dealStatus`,
+      `dealComment`. В переменные кладёт `gc_deal_id`, если GetCourse его вернул.
+    - `yametrika_event` — офлайн-конверсия в Я.Метрику: `connectionId`, `idType`
+      (`ClientId`|`Yclid`, по умолчанию `ClientId`), **`idValue`** (обязателен после рендера —
+      пустой обрывает действие), опц. `target`, `price`, `currency` (по умолчанию `RUB`),
+      `dateTime` (unix-секунды, по умолчанию «сейчас»).
+  - **Единственное НЕ интегрированное действие**: `cancel_payment_subscription` —
+    принимается как no-op с пометкой `integration_not_connected`.
+  - **модерация группы**: `group_unban`, `group_kick`, `group_approve`, `group_decline`
+
+### Внешнее / прочее
+- `CALL_WEBHOOK` — `{ "url":"https://...", "method":"POST", "headersJson":"{\"X-Key\":\"…\"}",
+  "bodyTemplate":"{...}", "timeoutMs":5000, "saveStatusTo":"http_status", "saveBodyTo":"http_body",
+  "extract":[{"path":"$.id","saveTo":"crm_id"}] }`. Выходы `ok` (код 2xx) / `error` (код ≥ 400,
+  сетевая ошибка, таймаут, отказ SSRF-гарда). Если ребра `error` нет — прогон идёт по `next`.
+  - `timeoutMs` — на этот узел; 0/не задан = общий клиент (connect 5 с / read 7 с), иначе значение
+    прижимается к диапазону **500…30000 мс**.
+  - `saveStatusTo` / `saveBodyTo` — имена переменных для HTTP-кода и тела ответа целиком.
+    Пишутся ВСЕГДА, в том числе на `error`: при сетевой ошибке код `0` и пустое тело (чтобы в
+    переменной не осталось значение прошлого прогона). Тело длиннее 65 536 символов обрезается — как любое строковое значение переменной (список/объект длиннее, например из `extract`, не сохраняется); все переменные подписчика вместе с именами — до 262 144 символов, запись сверх лимита не сохраняется (переменная прежняя).
+    Это штатный способ разветвиться по коду ответа: `saveStatusTo` → `SWITCH`.
+  - `extract` — разбор JSON-тела по JsonPath в переменные (работает только на валидном JSON).
+- `AI_REPLY` — ответ модели. Два режима, переключатель — поле `mode` (`"simple"`/не задано, либо
+  `"agent"`). Узел без `mode` работает дословно как режим `simple` (обратная совместимость: в
+  проде живут графы без этого поля). **Оба режима платные** (`PREMIUM_NODES`): на бесплатном
+  тарифе публикация падает с `PREMIUM_NODE_FORBIDDEN`. Веб-редактор показывает поле
+  `quotaFallbackText` в инспекторе для ОБОИХ режимов (без подстановки `{{var.x}}` — уходит клиенту
+  как есть).
+
+  **`mode: "simple"`** (сегодняшнее поведение, без изменений):
+  `{ "systemPrompt":"Ты консультант магазина.", "userPromptTemplate":"Вопрос: {{last_text}}",
+  "sendToUser": true, "saveTo":"ai_answer", "quotaFallbackText":"Спросите менеджера" }`.
+  `userPromptTemplate` обязателен (пустой → выход `error`). `sendToUser:true` — отправить ответ
+  подписчику; `saveTo` — положить в переменную. Если месячный AI-бюджет тарифа исчерпан, узел НЕ
+  ошибка: отправляется `quotaFallbackText` (если задан) и сценарий идёт дальше по `next`. В этом
+  случае `saveTo` НЕ обновляется — переменная хранит значение прошлого прогона (или остаётся
+  пустой, если прогона ещё не было). Температура задаётся глобально на сервере — поле
+  `temperature` в конфиге рантайм не читает.
+
+  **`mode: "agent"`** — поиск по базе знаний + ветки-действия + память диалога на этом узле. Температура
+  агента своя, серверная (`botbuilder.ai.agent-temperature`, по умолчанию 0.3), `temperature` узла не читается
+  (спека `docs/superpowers/specs/2026-09-21-ai-agent-node-design.md`, раздел 10). У узла-агента
+  **нет выхода `next`** — вместо него именованные ветки ниже.
+  ```json
+  { "mode": "agent", "knowledgeBaseId": "<id базы знаний>", "strict": true,
+    "systemPrompt": "Ты консультант магазина. Отвечай по базе, вежливо и по делу.",
+    "actions": [ { "id": "order", "title": "Оформить заказ", "when": "клиент готов купить" } ],
+    "extract": [ { "variable": "phone", "description": "телефон клиента" } ],
+    "quotaFallbackText": "Спросите менеджера" }
+  ```
+  Необязательные числовые/флаговые поля и их дефолты (можно не указывать вовсе):
+  `directAnswer` (`false`), `directAnswerThreshold` (`0.88`), `minScore` (`0.35`), `topK` (`5`),
+  `maxContextChars` (`6000`), `historyTurns` (`6`).
+  - `knowledgeBaseId` — id базы знаний ЭТОГО владельца (иначе рантайм ведёт себя так, будто базы
+    нет). `strict` (по умолчанию `true`) — без базы в строгом режиме публикация падает с
+    `AGENT_NO_KNOWLEDGE_BASE`.
+  - **Без найденных в базе фрагментов агент уходит в `unknown` в ЛЮБОМ режиме** — если хитов нет
+    или лучший скор ниже `minScore`, до вызова модели дело не доходит вообще (нестрогий режим
+    агента без базы или без совпадений не «отвечает по общим знаниям», он так же уходит в
+    `unknown`). **Исключение — узел с непустым `actions[]`:** он и без фрагментов зовёт модель
+    (платно), чтобы та могла выбрать действие — «запишите меня на завтра» слов из базы не содержит;
+    её ответ без фрагментов в любом режиме (и в нестрогом) уходит в `unknown` — только действие. Узел только с
+    `extract[]` выходит рано, как раньше. `strict` решает только то, что делает модель, когда релевантные фрагменты уже
+    нашлись: в строгом режиме — отвечает исключительно по ним; без строгого режима — может
+    дополнить их общими знаниями модели, но не про цены/сроки/обещания — это всегда только из
+    базы и инструкции.
+  - `directAnswer` (по умолчанию `false`) — прямой ответ готовой парой вопрос-ответ БЕЗ обращения
+    к модели (бесплатно), когда совпадение по базе ≥ `directAnswerThreshold`. Пара ищется по вектору
+    своего вопроса, так что порог 0.88 проходят почти дословные формулировки. Работает только для
+    документов-пар вопрос-ответ (не для кусков файлов/сайта) — кусок PDF, отданный дословно,
+    выглядел бы поломкой.
+  - `minScore` — порог релевантности фрагмента для решения «есть о чём отвечать»; ниже — выход
+    `unknown`. `topK`/`maxContextChars` — сколько фрагментов брать и лимит символов контекста.
+    `historyTurns` — сколько реплик истории диалога передавать модели.
+  - `systemPrompt` — инструкция агента. Мягкая норма — **до 10 000 символов**: длиннее модель хуже
+    держит середину, и каждый ответ дороже. У бэкенда для этого нет отдельного предупреждения при
+    публикации (веб-инспектор просто красит счётчик символов) — только `validate.mjs` (этот
+    скилл) предупреждает об этом явно. Жёсткий потолок — **30 000 символов**
+    (`AGENT_PROMPT_TOO_LONG`, блокирует публикацию и у бэкенда, и у `validate.mjs`). Платформа
+    сама добавляет ПЕРЕД инструкцией служебный блок: защиту от инъекций/вытягивания инструкции
+    через реплики клиента, историю и фрагменты базы, запрет писать, что действие уже выполнено
+    (это делает сценарий, не модель), запрет обещать несделанное, и формат ответа под конкретный
+    мессенджер — **дублировать это в `systemPrompt` не нужно**.
+  - `actions[]` — ветки, которые выбирает сама модель по смыслу разговора: `id` (латиница/цифры/`_`),
+    `title` (человеческое название — без него запись целиком игнорируется рантаймом и валидатором),
+    `when` (опц., подсказка модели, когда применять). Каждому действию — своё ребро
+    `action_<id>`; повтор `id` → `AGENT_DUPLICATE_ACTION_ID`, отсутствие ребра →
+    `AGENT_ACTION_NOT_CONNECTED`.
+  - `extract[]` — переменные, которые агент сам заполняет из разговора: `variable`
+    (`[a-z_][a-z0-9_]{0,63}`, не `ai_summary` — оно зарезервировано), `description` (что искать).
+    Значение — **слова клиента, а не проверенный факт**. Кривая запись → `AGENT_BAD_EXTRACT`.
+  - При уходе в действие (`action_<id>`) агент сам готовит сводку разговора для менеджера —
+    без отдельной настройки, кладёт её в `{{var.ai_summary}}` (до 1500 символов, тоже слова
+    клиента, не проверенные данные).
+  - Выходы: `answered` (ответила модель — по базе, а без строгого режима ещё и общими знаниями),
+    `action_<id>` (по числу `actions[]`), `unknown` (не знает ответа — нет фрагментов выше
+    `minScore`, ветка не подключена не блокирует публикацию, только предупреждение
+    `AGENT_UNKNOWN_NOT_CONNECTED`, но диалог упрётся в тупик), `budget_exhausted` (месячный
+    AI-бюджет исчерпан, если ветка подключена), `error` (сбой модели/поиска, ИИ не настроен на
+    сервере, headless-вебхук — у агента нет собеседника — или исчерпан бюджет, а ветка
+    `budget_exhausted` не подключена). Прямой ответ (`directAnswer`) отправляется и идёт в выход
+    `answered`, как обычный ответ модели.
+  - **Исчерпание бюджета у агента — НЕ `next`** (такого выхода у узла нет): уходит в
+    `budget_exhausted`, если ветка подключена, иначе в `error`. `quotaFallbackText` (без
+    подстановки переменных) отправляется в обоих случаях, если задан. Это касается и
+    `directAnswer` — бесплатный прямой ответ тоже не сработает при исчерпанном бюджете месяца,
+    проверка бюджета идёт раньше поиска по базе.
+- `PAYMENT_LINK` — сообщение с кнопкой-ссылкой на оплату (сам платёж не проводит).
+  `{ "paymentUrl":"https://example.com/pay?user={{from.id}}", "description":"Оплатите подписку:",
+  "buttonText":"Оплатить" }`.
+- `YOOKASSA_PAYMENT` — узел оплаты. **В новых сценариях его не ставь**: выставление счёта — это
+  действие, поэтому оно живёт действием `issue_invoice` внутри `ACTIONS` (см. ниже), а узла больше
+  нет в палитре. Тип жив в рантайме только ради графов, где он уже стоит.
+- Действие **`issue_invoice`** внутри `ACTIONS` — настоящий счёт на **кассу владельца бота**
+  (деньги идут на его магазин, не на счёт сервиса) и, если нужно, ожидание оплаты.
+  `{ "kind":"issue_invoice", "connectionId":"<id подключения ЮKassa>", "amount":"990",
+  "description":"Доступ к курсу", "buttonText":"Оплатить", "timeoutMinutes":60 }`.
+  - `connectionId` **обязателен** — подключение из реестра с `provider=YOOKASSA`
+    (`list_integrations`). Нет его → `YK_NO_CONNECTION`. Касса обязана принадлежать владельцу
+    бота, чужой id рантайм отвергает.
+  - `amount` обязателен, > 0, можно шаблоном (`{{var.price}}`); `description` обязателен.
+  - **Выходы даёт БЛОК `ACTIONS`** (тем же приёмом, что и `error`): при наличии счёта у блока
+    появляются `paid` и `timeout`. Ключевое правило: **поведение зависит от того, протянул ли ты
+    ветку `paid`.**
+    - Ветки `paid` НЕТ → блок просто шлёт счёт и идёт по `next`, ничего не дожидаясь.
+    - Ветка `paid` ЕСТЬ → сценарий встаёт на паузу до подтверждения оплаты кассой; не дождался за
+      `timeoutMinutes` → уйдёт в `timeout`. Сообщения подписчика до оплаты (другие триггеры, ветки до END,
+      вопроса или задержки) ожидание не сбрасывают: `paid`/`timeout` всё равно сработают. Сбрасывает его только
+      пауза на ДРУГОМ счёте с веткой `paid` — тогда оплата прежней ссылки сценарий не продолжает.
+  - ⚠️ **Счёт обязан быть ПОСЛЕДНИМ действием в блоке** (`INVOICE_NOT_LAST`) и только один
+    (`INVOICE_DUPLICATE`). Причина: с веткой `paid` блок встаёт на паузу, а возобновиться с
+    середины списка движок не умеет — действия после счёта молча не выполнились бы.
+  - `timeoutMinutes` — 1…1440, по умолчанию 60. Имеет смысл только вместе с веткой `paid`.
+  - Переменные после шага: `{{var.payment_url}}`, `{{var.payment_id}}`.
+  - Повторный проход по счёту: пока попытка ЭТОГО шага жива (не оплачена, таймаут не сработал, другой счёт с
+    `paid` её не сменил) — та же ссылка (тот же платёж), даже если между проходами подписчик ушёл в другую
+    ветку; после оплаты или таймаута — новый счёт. Оплата, пришедшая после таймаута, ветку `paid` не продолжает, зато запускает сценарии владельца с `TRIGGER_PAYMENT` в диалоге этого подписчика (один раз на платёж; бот выключен — ЮKassa повторяет уведомление, запуск после включения бота) — для опоздавших заведи такой сценарий. Если таймаут был пропущен, пока бот был выключен, повторный проход сперва спрашивает ЮKassa: платёж оплачен — шаг сразу идёт по `paid` (нового счёта нет); статус не узнать — та же ссылка; не оплачен — новый счёт.
+  - Без ветки `paid` ожидания нет: каждый проход по такому счёту — новый платёж с новой ссылкой.
+  - Действие бесплатное (в отличие от `external_request`).
+  - Чтобы `paid` срабатывал сразу, владелец вписывает адрес уведомлений из карточки подключения в кабинет
+    ЮKassa (событие `payment.succeeded`). Без уведомлений сервис сам опрашивает статус ожидающих счетов
+    (`GET /v3/payments/{id}`: через ~30 с, дальше реже, до раза в 10 мин, пока не вышел таймаут) — `paid`
+    сработает с задержкой до нескольких минут, ровно один раз (опоздавшее уведомление ничего не задвоит).
+  - Бот выключен в момент оплаты или проверка платежа не удалась (сбой ЮKassa, устаревший ключ в подключении) →
+    ЮKassa повторяет уведомление до суток; `paid` сработает на первом удачном повторе, если сценарий к тому
+    времени ещё не ушёл в `timeout`. Не удалось за сутки — сценарий по этой оплате не продолжится.
+- `CALL_WEBHOOK` — тоже платный узел, см. раздел «Внешнее / прочее». **В новых сценариях его не
+  ставь**: узла больше нет ни в палитре, ни в меню — внешний запрос собирается действием
+  `external_request` внутри `ACTIONS`. Тип живёт в рантайме только ради графов, где он уже стоит.
+- Действие `external_request` внутри `ACTIONS` — **тоже платное**, гейт тот же.
+
+## Лимиты тарифа, которые видит сборщик графов
+
+- **Блоков в сценарии.** Публикация падает с `NODE_LIMIT_EXCEEDED` (в тексте — сколько блоков в
+  графе и сколько даёт тариф). Ошибка на весь граф, `nodeId` пустой. Проверять нечем заранее:
+  число блоков берётся из `nodes[]`, лимит — из тарифа владельца.
+- **Число сценариев.** `create_graph`, `create_graph_from_template`, `clone_graph`, `copy_graph` и
+  создание сценария в вебе отдают **HTTP 402** `{error, upgradeUrl}`, когда лимит исчерпан.
+  Считаются сценарии, которые завёл человек; снимок публикации место не занимает.
+- **Переменные** (глобальные и на сценарий) тоже лимитированы тарифом — сама подсистема переменных
+  ещё не построена, поле лимита в тарифе уже есть.
+
+## Условия CONDITION
+
+Каждый элемент `conditions[]` — `{ "kind", "op", ...поля }`. Любая внутренняя ошибка условия = `false` (узел уходит в `no`).
+
+| `kind` | `op` (допустимые) | Поля | Что проверяет |
+|---|---|---|---|
+| `TAG` | `HAS`, `NOT_HAS` | `value` — метка `[a-z0-9_-]{1,64}` | есть ли у пользователя тег |
+| `VARIABLE` | `EQUALS`, `NOT_EQUALS`, `CONTAINS`, `NOT_EMPTY`, `EMPTY`, `GT`, `LT` | `key` — имя переменной `[a-z_][a-z0-9_]{0,63}`, `value` | значение переменной (`GT`/`LT` — числовое сравнение) |
+| `UTM` | `EQUALS`, `CONTAINS`, `NOT_EMPTY`, `EMPTY` | `key` ∈ `source`/`medium`/`campaign`/`content`/`term`, `value` | UTM-метку клика (`utm_<key>`), регистронезависимо |
+| `NAME` | `EQUALS`, `CONTAINS`, `NOT_EMPTY`, `EMPTY` | `value` | имя из профиля, регистронезависимо |
+| `EMAIL` | `EQUALS`, `CONTAINS`, `NOT_EMPTY`, `EMPTY` | `value` | email из профиля |
+| `PHONE` | `EQUALS`, `CONTAINS`, `NOT_EMPTY`, `EMPTY` | `value` | телефон из профиля |
+| `USERNAME` | `EQUALS`, `CONTAINS` | `value` | @username пользователя Telegram |
+| `SUBSCRIBED` | `SUBSCRIBED`, `NOT_SUBSCRIBED` | `key` — **числовой** id канала/группы (напр. `-1001234567890`); узнать числовой id подключённых каналов: `list_channels(botId)` | подписан ли пользователь на канал бота |
+| `LINK_CLICKED` | `CLICKED`, `NOT_CLICKED` | `key` — **`id` узла-шага** с отслеживаемой URL-кнопкой (тот же UUID, что у `SEND_MESSAGE`) | кликал ли пользователь по ссылке этого шага |
+| `CURRENT_DATE` | `BEFORE`, `AFTER`, `EQUALS` | `value` — дата `YYYY-MM-DD` | сегодняшнюю дату (МСК) |
+| `CURRENT_TIME` | `BETWEEN` | `value`, `value2` — время `HH:mm` | текущее время в интервале (через полночь — если `value`>`value2`) |
+| `DAY_OF_WEEK` | `IN` | `days` — массив из `MON`,`TUE`,`WED`,`THU`,`FRI`,`SAT`,`SUN` | день недели (МСК) |
+
+Для `NOT_EMPTY`/`EMPTY` поле `value` не нужно. `UTM` без `key` всегда `false`.
+
+**`SUBSCRIBED`** работает только если бот **админ** в канале/группе и канал «привязан» (бот узнаёт о членстве через хук `my_chat_member` — добавь бота в канал админом). `key` должен парситься в число, иначе условие = `false`. Профильные поля (`NAME`/`EMAIL`/`PHONE`) и UTM заполняются по ходу воронки (`ASK_QUESTION`→`saveTo`, диплинк-клик с UTM).
+
+**`LINK_CLICKED`** проверяет факт клика по URL-кнопке конкретного шага. Чтобы условие работало: у нужного `SEND_MESSAGE` хотя бы одна кнопка `kind:"URL"` с `"track": true`, а в условии `key` = `id` этого узла-шага. Клик фиксируется через публичный редирект бота, поэтому условие имеет смысл ставить **после** `DELAY`/`ASK_QUESTION` (дай пользователю время кликнуть).
+
+> **Платформа MAX.** Боты конструктора умеют работать и в мессенджере MAX. Там не поддерживаются `SUBSCRIBED`/`NOT_SUBSCRIBED` (нет членства в каналах) и reply-клавиатуры; публикация такого графа на MAX-бот вернёт **мягкие предупреждения** (не блокирует). Для Telegram-ботов всё работает как описано.
+
+## Платформа Instagram
+
+> **Сейчас Instagram выключен в сервисе:** IG-бота не подключить, страница `/bots/instagram` ведёт на `/bots`. Раздел оставлен на будущее включение.
+
+IG-боты подключаются через OAuth на странице **`/bots/instagram`** (раздел «Подключения» → карточка
+Instagram; прежний раздел «Инструменты роста» / `/growth` расформирован и редиректит) — **без вставки токена вручную**; у IG нет персонального бот-токена. После OAuth бот получает доступ к Messaging API через привязанный Instagram Business/Creator-аккаунт.
+
+### Разрешённые типы узлов для IG-ботов
+
+Только следующие (всё остальное — ошибка `IG_NODE_UNSUPPORTED` при публикации):
+
+| Тип | Доступен в IG |
+|---|---|
+| `TRIGGER_IG_COMMENT`, `TRIGGER_IG_DM`, `TRIGGER_IG_STORY_REPLY`, `TRIGGER_IG_STORY_MENTION` | ✅ (триггеры входа) |
+| `SEND_MESSAGE`, `SEND_PHOTO` | ✅ |
+| `BRANCH`, `CONDITION`, `SWITCH`, `STOP_AND_ERROR` | ✅ |
+| `SET_VARIABLE`, `ADD_TAG`, `REMOVE_TAG`, `FORMULA` | ✅ |
+| `ASK_QUESTION` | ✅ (с ограничениями — см. ниже) |
+| `DELAY` | ✅ (не более 24ч — см. ниже) |
+| `END` | ✅ |
+| `TRIGGER_COMMAND`, `TRIGGER_CALLBACK`, `TRIGGER_TEXT` | ❌ |
+| `BROADCAST_FILTER` (рассылки) | ❌ |
+| `SCHEDULE`, `ACTIONS`, `CALL_WEBHOOK`, `AI_REPLY`, `PAYMENT_LINK`, `YOOKASSA_PAYMENT` | ❌ |
+| `TRIGGER_PAYMENT` | ❌ |
+
+### Ограничения IG-ботов
+
+- **Нет команд** — вход только через `TRIGGER_IG_COMMENT` / `TRIGGER_IG_DM` / `TRIGGER_IG_STORY_REPLY` / `TRIGGER_IG_STORY_MENTION`. `/start` и другие команды не поддерживаются.
+- **Нет рассылок** — `BROADCAST_FILTER` недоступен.
+- **DELAY не более 24 часов** — Instagram доставляет сообщения только в течение 24-часового окна после последнего входящего действия (`IG_DELAY_OVER_24H`). `DELAY` с `kind=TOMORROW` или `kind=UNTIL` блокируются (они заведомо > 24ч). `kind=FIXED` с `durationSec > 86400` тоже блокируется.
+- **`ASK_QUESTION`** — `inputKind`: `TEXT`, `EMAIL`, `PHONE`, `NUMBER`, `CONTACT` (`IG_INPUT_UNSUPPORTED` для остальных). `CONTACT` допустим: кнопки «Поделиться номером» в IG нет, поэтому бот отправляет текст-инструкцию и принимает номер, набранный вручную (как телефон). Нельзя запрашивать `LOCATION`, `PHOTO`, `DOCUMENT`.
+- **Нет reply-клавиатур** — кнопки IG работают как inline (URL или Deep Link); стиль кнопок ограничен возможностями IG Messaging API.
+- **Нет SUBSCRIBED** — условие «подписан на канал» недоступно.
+- **Коммент → ЛС (Private Reply)** — на `SEND_MESSAGE`/`SEND_PHOTO` в графе с `TRIGGER_IG_COMMENT` укажи `"igReplyChannel": "dm"`, чтобы ответить автору комментария в Direct (а не публично под постом). По умолчанию (`"comment"`) — публичный ответ. Подробнее — `igReplyChannel` в разделе «Сообщения». **`"comment"` тоже требует, чтобы шаг был достижим от `TRIGGER_IG_COMMENT`** — иначе ошибка валидации `IG_COMMENT_REPLY_NO_COMMENT_TRIGGER` (в DM/story-флоу отвечать в комментарии некуда).
+
+### Оффлайн-проверка IG-графа
+
+```bash
+node validate.mjs graph.json --platform=INSTAGRAM
+```
+
+Ловит `IG_NODE_UNSUPPORTED`, `IG_DELAY_OVER_24H`, `IG_INPUT_UNSUPPORTED` — в дополнение ко всем обычным структурным проверкам.
+
+## Кросс-платформенное копирование (Telegram ⇄ MAX)
+
+Инструмент `copy_graph` копирует граф в **другого бота** пользователя (`targetBotId`), в т.ч. на другую платформу. Формат графа один и тот же; различается лишь платформа бота-получателя. При копировании в MAX-бот несовместимые узлы **адаптируются**, отчёт — в `notes[]`:
+
+| code | severity | что значит |
+|---|---|---|
+| `MAX_CONTACT_AS_TEXT` | TRANSFORM | вопрос с `inputKind=CONTACT` переписан в `inputKind=TEXT` + `validator=PHONE` (в MAX нет кнопки «поделиться контактом»; иначе узел стал бы тупиком) |
+| `MAX_SUBSCRIBED_ALWAYS_NO` | MANUAL | условие `SUBSCRIBED` оставлено как есть, но в MAX всегда «не подписан» — проверьте ветвление вручную |
+| `MAX_VOICE_AS_AUDIO` | INFO | голосовое уйдёт обычным аудио |
+| `MAX_VIDEO_NOTE_AS_VIDEO` | INFO | кружок уйдёт обычным видео |
+| `MAX_GALLERY_AS_ATTACHMENTS` | INFO | галерея уйдёт одним сообщением с вложениями |
+| `MAX_DELETE_NOOP` | INFO | действие «удалить сообщение» в MAX игнорируется |
+
+`preview: true` возвращает только `notes[]` (без копирования). Копирование в Telegram-бота (или в бота той же платформы) — точная копия, `notes[]` пустой. Новый граф создаётся как `DRAFT` с именем «… (copy)». Копировать в тот же бот нельзя (для дублирования — `clone_graph`).
+
+## Выходные хэндлы (`sourceHandle`) — шпаргалка
+| Узел | Хэндлы |
+|---|---|
+| обычный поток | `next` |
+| кнопки сообщения (`buttons`) | `btn_0`, `btn_1`, … (по индексу кнопки, плоско по всем рядам) |
+| `CONDITION` | `yes`, `no` |
+| `BRANCH` | `case_<id>`, `default` |
+| `ASK_QUESTION` | `valid`, `invalid` |
+| `SEND_MESSAGE` с `awaitReply:true` | `valid`, `invalid` (+ `btn_N` для кнопок) |
+| `CALL_WEBHOOK` | `ok`, `error` |
+| `ACTIONS` | `next`, плюс `error` — если внутри есть действие, которое может упасть (внешний запрос, CRM, Таблицы); `taken` — слот `booking_book` занят |
+| `SWITCH` | `case_<id>`, `default` |
+| `STOP_AND_ERROR` | выходов нет (терминатор) |
+| `SCHEDULE` | `scheduled`, `past` |
+| `DELAY` | `next`; у `UNTIL` ещё `late` (момент уже прошёл) и `error` (шаблон не разобрался как дата) |
+| `AI_REPLY` (`mode` не задан/`simple`) | `next`, `error` |
+| `AI_REPLY` (`mode:"agent"`) | `answered`, `action_<id>` (по числу `actions[]`), `unknown`, `budget_exhausted`, `error` — **выхода `next` нет** |
+
+## Подстановки в тексте
+`{{from.first_name}}`, `{{from.username}}`, `{{var.<имя>}}`, либо `{Имя}` как плейсхолдер. Имена переменных/меток: `[a-z_][a-z0-9_]{0,63}` (var) и `[a-z0-9_-]{1,64}` (tag).