Задача: MLF-295 — «Сценарии: мультиканальные ноды-действия Telegram + Web Push (первый класс)». Это шаг 1 карточки (ресёрч); его результат ложится в шаг 2 (макеты инспекторов Telegram и Web Push в Claude Design) и согласование с М. Терентьевым — без апрува в разработку не берём.
Дата: 2026-07-13 Метод: deep-research harness (5 углов → параллельные web-поиски → фетч 21 first-party источника → извлечение 91 фалсифицируемого утверждения → adversarial-верификация в 3 голоса, 75 проверок по топ-25 утверждениям: 25 подтверждено / 0 опровергнуто; синтез с дедупом → 14 итоговых находок). 103 агента, 0 ошибок. Скоуп: только то, что нужно для инспекторов Telegram- и Web-Push-нод «первого класса» — (1) как нода привязывается к каналу отправки, (2) выбор бота/канала Telegram, (3) состав полей Web Push, (4) consent/подписка Web Push, (5) валидация конфига перед публикацией, (6) сборка omnichannel-сценария. Продукт-ориентир — SendPulse (от него идёт отстройка UI), эталон детального web-push — OneSignal.
Достоверность и покрытие. Верифицированная фактура собрана в основном по SendPulse (первичный ориентир, разобран глубоко) и OneSignal (эталон богатого web-push-инспектора); Braze покрыт одной темой (привязка канала через дропдаун). Заявленные в запросе Customer.io, Klaviyo, Iterable, Mindbox, MoEngage, Insider переживших верификацию утверждений в этой итерации не дали — их модели здесь не приводим (не выдумываем; при необходимости — отдельный догон, см. «Открытые вопросы»). Отдельные сырые находки по Customer.io/Mindbox из журнала фетча, не прошедшие верификацию, отмечены в «Пробелах» как таковые.
Текущее состояние UI редактора — mockups/editor-ui-redesign.html (собран по итогам
4 предыдущих ресёрчей). Применительно к этой задаче в нём уже реализовано:
MessengerInspector) — выбор чат-бота из дропдаупа (сгруппировано
«Telegram»), три режима контента переключателем — «Сообщение / Цепочка», текст с
parseMode (HTML/Markdown/None), инлайн-кнопки (текст+URL), выбор шаблона/цепочки.PushInspector) — минимальная: только заголовок, текст, URL.mailcheck) в сайдбаре консоли.renderStates.Значит, ресёрч должен закрыть дельту до «первого класса»: (а) привязка ноды к каналу отправки (а не только к боту), (б) выбор Telegram-канала/группы, а не только бота, (в) богатый состав Web Push (иконка/бейдж/картинка/action-кнопки/TTL/приоритет/deep-link), (г) consent-гейт Web Push в UI, (д) канал-специфичная валидация перед публикацией.
Тема 1 · Привязка ноды к каналу — две парадигмы.
Тема 2 · Telegram — привязка через бота, канал косвенно. 4. У SendPulse Telegram не отдельная нода — он внутри общего Messenger-элемента (Instagram / WhatsApp / Facebook Messenger / Telegram). Конкретный канал определяется выбором бота через дропдаун «Select the bot you want to run». Можно поставить несколько Messenger-элементов и слать через несколько ботов/платформ разом. 5. Три взаимоисключающих режима контента Messenger-ноды: (1) текстовое сообщение (переменные + эмодзи), (2) запустить flow (цепочку), (3) отправить одобренный шаблон (у SendPulse — только WhatsApp, Pro+). → В нашем макете уже есть «Сообщение / Цепочка»; третий режим (шаблон) для Telegram неактуален. 6. Привязка flow к боту/каналу — через триггер, а не через поле канала на ноде. Типы триггеров: дефолтные (Welcome / Standard reply / Unsubscribe) и кастомные (Keyword, A360-event, Join a Telegram group or channel). → Для нас: выбор Telegram-бота живёт в инспекторе ноды (как сейчас), но стоит показать, что бот определяет и канал.
Тема 3 · Web Push — от минимализма до богатой модели.
7. SendPulse A360 Push-нода — минималистична: заголовок, текст, опциональная картинка
(реком. 128×128px до 200KB), click-through URL, TTL (по умолч. 24 ч). Нет action-кнопок,
badge, deep-link, приоритета. (Богатые кнопки есть в отдельном standalone push-редакторе
SendPulse — но это другой инструмент, не flow-нода.)
8. OneSignal — эталон детального инспектора (ориентир, куда расти): Title (реком. <50 симв),
Message (<120), Icon (256×256 PNG/JPG), Large Image, до 2 action-кнопок (Chrome),
Launch/Deep-link URL, TTL (0–2419200с, дефолт 3 дня), Priority (High=10 / Normal=5),
Web Push Topic (дедуп). Важно: иконка/картинка/бейдж — per-browser поля
(chrome_web_icon, firefox_icon, chrome_web_badge, chrome_web_image), а не единое поле.
9. Action-кнопки принципиально ограничены браузером: Chrome — до 2, Firefox/Safari — 0
(это ограничение платформы, не продукта; закладывать как browser-dependent). Каждая кнопка =
id (идентификатор клика) + text (лейбл) + url (куда открыть) + опциональная icon.
Тема 4 · Consent Web Push — жёсткий гейт.
10. SendPulse шлёт push только контактам, подписанным на push, чья push-подписка
связана с email-адресом (email в подписке = email из события). → Для нас это
подтверждает: перед отправкой push — обязательный consent-гейт (у нас уже есть
src/lib/consent.ts); в UI ноды стоит явно предупреждать про достижимую аудиторию.
Тема 5 · Валидация перед публикацией. 11. SendPulse (Telegram flow builder): элементы с пустыми полями → красным, несвязанные (disconnected) → жёлтым; flow нельзя сохранить, пока поля не заполнены; нужен минимум один Message/Action-элемент. Паттерн red-empty / yellow-disconnected — общий для всех channel-билдеров SendPulse. → Наш макет уже реализует ровно этот паттинг (красная точка / жёлтый пунктир). «Первый класс» = добавить канал-специфичные правила (для Push — задан ли URL/иконка; для Telegram — выбран ли бот).
Две парадигмы (обе подтверждены, 3-0):
| Парадигма | Кто | Как выбирается канал |
|---|---|---|
| Нода-на-канал | SendPulse Automation 360 | Отдельные элементы Email / SMS / Viber / Web Push / Messenger. Выбор канала = выбор типа ноды из палитры. |
| Message-нода + дропдаун | Braze Canvas | Единый Message-компонент, шаг 1 «Select your messaging channel» — 9 каналов (Email, Push, SMS/MMS/RCS, In-App, WhatsApp, Content Cards, LINE, Banners, Webhook). |
Вывод для нас: макет уже следует модели SendPulse — отдельные ноды в категории «Сообщения». Это валидный и распространённый путь; вводить braze-подобную универсальную message-ноду с дропдауном канала не нужно — это ломало бы уже согласованную палитру. «Первый класс» достигается качеством инспекторов отдельных нод, а не сменой парадигмы.
Источники: sendpulse.com/.../automation360/flow-elements · braze.com/.../canvas_components/message_step · braze.com/.../canvas_by_channel/in-app_messages_in_canvas
3.1 Telegram живёт внутри общего Messenger-элемента (подтверждено, 3-0)
✓ Соответствие макету: в
MessengerInspectorдропдаун «Чат-бот» уже сгруппирован «Telegram» и содержит выбор бота (@username — name). Это ровно паттерн SendPulse.
3.2 Три режима контента (подтверждено, 3-0)
✓ В макете есть переключатель «Сообщение / Цепочка». Режим «Шаблон» для Telegram не нужен.
3.3 Привязка через триггер, не через поле канала (подтверждено, 3-0)
Источники: sendpulse.com/.../automation360/messenger · sendpulse.com/.../automation360/flow-elements · sendpulse.com/.../chatbot/telegram/create-flow
Рекомендация для инспектора Telegram-ноды (макет):
Две крайние модели — их полезно держать как «минимум» и «потолок»:
| Поле | Детали |
|---|---|
| Заголовок (title) | обязателен |
| Текст (text) | тело, с переменными |
| Картинка (image) | опциональна, заменяет дефолтную; реком. 128×128px, до 200KB |
| Ссылка (click-through URL) | куда ведёт клик |
| TTL (push lifetime) | по умолчанию 24 часа |
Чего НЕТ в A360-ноде: action-кнопок, badge, deep-link (отдельно от URL), приоритета. (⚠️ Богатые action-кнопки есть в отдельном standalone push-редакторе SendPulse — но это другой инструмент, не flow-нода. Для инспектора flow-ноды релевантна именно A360-модель.)
Контент:
headings) — обязателен для web push (fallback на Site Name); реком. <50 симв.contents) — обязателен (кроме background); реком. <120 симв.chrome_web_icon, firefox_icon,
chrome_web_badge, chrome_web_image. Это структура данных API, не обязательно
раскладка UI (см. «Пробелы» п.3).Action-кнопки (подтверждено, 3-0):
web_buttons, max 2). Firefox — 0, Safari — 0 (ограничение
браузера; MDN Notification.maxActions: Chrome=2, Firefox=0).id (уникальный идентификатор клика) + text (лейбл) + url (куда открыть;
do_not_open блокирует открытие) + опциональная icon (public URL).Launch / deep-link URL (подтверждено; 2-1 по split):
url (универсальный https, открывается в браузере, поддерживает
персонализацию — основное для web push), web_url (только web), app_url (нативный
deep-link your-app-scheme://, mobile only). Для веба хватает url.?_osp=do_not_open).Delivery-контролы (подтверждено; TTL 2-1 по split):
ttl:0 =
не доставлять с опозданием. Контролирует хранение, пока устройство offline.Рекомендация для инспектора Web Push (макет) — «первый класс» между минимумом и потолком:
| Поле | Брать? | Обоснование |
|---|---|---|
| Заголовок, Текст | ✓ (есть) | база обоих |
| Иконка | ✓ добавить | есть у OneSignal; в макете нет |
| Картинка (large image) | ✓ добавить | опциональна; SendPulse и OneSignal |
| Ссылка / URL клика | ✓ (есть) | база обоих |
| Action-кнопки (до 2) | ✓ добавить, помечая browser-dependent | ключевой признак «первого класса»; но честно показать «Chrome — до 2, Firefox/Safari — не поддерживают» |
| TTL (время жизни) | ✓ добавить, дефолт 3 дня | оба продукта; у нас durable Jobs — TTL логично ложится |
| Приоритет (High/Normal) | ✓ добавить | OneSignal; простой enum из 2 значений |
| Badge, per-browser иконки, Web Push Topic | задел (за рамками MVP) | OneSignal-специфика; заложить в config-schema, но не в первый макет |
Источники: sendpulse.com/.../automation360/web-push-notifications-automation360 · documentation.onesignal.com/docs/en/push · .../web-push-setup · .../action-buttons · .../reference/push-notification · .../docs/en/links · MDN Notification.maxActions
Жёсткий гейт (подтверждено, 3-0): SendPulse отправляет push только контактам, которые (а) подписаны на push и (б) чья push-подписка связана с email-адресом (email в подписке = email из события).
Вывод для нас: у нас уже есть consent/suppression-гейт (src/lib/consent.ts, правило
«перед отправкой — всегда проверять consent»). Ресёрч подтверждает, что это отраслевая
норма для push, не наша перестраховка. В UI инспектора Push-ноды стоит:
Источник: sendpulse.com/.../automation360/web-push-notifications-automation360
Паттерн SendPulse (подтверждено, 3-0):
✓ Соответствие макету:
renderStatesуже показывает красную точку (ошибка, блокирует) и жёлтый пунктир (не подключена, warning) — ровно этот паттерн. Совпадает и с RESEARCH-publish-guardrails (два уровня: warning не блокирует / error блокирует; ошибка на самой ноде + панель-список).
Дельта до первого класса: канал-специфичные правила публикации:
text+url.Источник: sendpulse.com/.../chatbot/telegram/create-flow
url/web_url/app_url, web_buttons, chrome_web_*). При
проектировании инспектора берём это как модель данных, а UI компонуем по-своему (напр.
одно поле «Иконка» в UI, а per-browser — задел в schema).SendPulse (первичный ориентир): sendpulse.com/knowledge-base/email-service/automation360/flow-elements · .../automation360/messenger · .../automation360/a360-email · .../automation360/web-push-notifications-automation360 · sendpulse.com/knowledge-base/chatbot/telegram/create-flow · .../telegram/telegram-triggers
OneSignal (эталон Web Push): documentation.onesignal.com/docs/en/push · .../docs/en/web-push-setup · .../docs/en/action-buttons · .../docs/en/links · .../reference/push-notification · .../docs/en/webhooks
Braze (привязка канала): braze.com/docs/user_guide/messaging/canvas/canvas_components/message_step · .../canvas/create_a_canvas/canvas_by_channel/in-app_messages_in_canvas · braze.com/docs/api/objects_filters/messaging/web_objects · .../channels/push/push_setup/push_subscription_states
Прочие (в выборке, для контекста consent/валидации): experienceleague.adobe.com/.../troubleshoot-journey/troubleshooting (Adobe Journey Optimizer: errors блокируют / warnings нет) · help.klaviyo.com/.../14781686592283 · support.iterable.com/.../31174083562900-Setting-up-Web-Push-Notifications · docs.customer.io/journeys/channels/push/send-push
Статистика: 5 углов, 21 источник фетч, 91 утверждение извлечено, топ-25 верифицировано в 3 голоса (25✓/0✗), 14 находок после синтеза, 103 агента, 0 ошибок.