Ресёрч: симуляция/превью пути контакта и live-debugger journey у конкурентов (MLF-293, шаг 1)

Задача: MLF-293 — «Сценарии: симуляция/превью пути контакта + live-debugger». Подзадача зонтичной MLF-284 (июльский редактор сценариев). Это шаг 1 карточки (ресёрч); его результат ложится в шаг 2 (макеты превью пути и live-debugger — подсветка на canvas, панель стрима) и согласование с М. Терентьевым — без апрува в разработку не берём.

Дата: 2026-07-13 Метод: deep-research harness (6 углов → параллельные web-поиски → фетч 28 first-party URL → извлечение 78 фалсифицируемых утверждений → adversarial-верификация в 3 голоса, 75 проверок: 67 подтверждено / 8 опровергнуто). Финальный агент-синтезатор упал на StructuredOutput; отчёт собран напрямую из верифицированной фактуры журнала (не по памяти) — как и в MLF-288. Скоуп: строго две темы карточки — (1) симуляция / dry-run превью пути контакта (выбор профиля, прогон по графу без реальных отправок, подсветка веток и объяснение «почему пошёл сюда»); (2) live-debugger (лента контактов по нодам, фильтр по контакту, логи исполнения из AutomationExecutions + cdp.automation_analytics_events). Наш контекст: durable-движок automation (Flows/FlowVersions + AutomationExecutions, НЕ Journey/Enrollment), @xyflow/react canvas, светлая тема, тулбар с Publish/валидацией/ версиями уже есть.

⚠️ Поправка по модели данных (ADR-000; исходный источник был неверным). В постановке MLF-293 и в первой редакции этого ресёрча debugger был привязан к FlowExecutions/ FlowExecutionLogs — но это таблицы Telegram Flow Builder (чат-боты), НЕ automation (admin.group: 'Flow Builder', связи на senders/flows/flow-versions, sourceUpdateId). У automation отдельной таблицы логов AutomationExecutionLogs нет — и она не нужна. Для реализации задачи хватает того, что уже есть:

• AutomationExecutions (public.automation_executions) — per-contact состояние: status (queued/running/waiting_delay/waiting_event/completed/error), currentNodeId, path: string[] (последовательность пройденных нод), lastErrorMessage, startedAt. Этого достаточно для фильтра по контакту, подсветки пройденного пути и drill-down.
• cdp.automation_analytics_events — append-only лента событий шага (node_entered/node_executed/node_error/message_sent/message_skipped/flow_completed/…) с person_id, node_id, node_type, created_at — для хронологической ленты debugger'а.

Ниже по тексту FlowExecutionLogs заменён на эти сущности.

Достоверность и покрытие. Верифицированная 3-голосовая фактура набрана по четырём вендорам: Braze, HubSpot, Customer.io, n8n — на first-party документации (help-центры, docs). Дополнительно верифицирован Adobe Journey Optimizer (вне исходного списка, но сильный первоисточник с важной для нас развилкой). SendPulse — 10 утверждений сняты прямо с его first-party доков (Automation360), но через 3-голосовую верификацию не прогонялись; все они — про отсутствие фичи, потому риск низкий, помечаю отдельно. По Klaviyo, Iterable, ActiveCampaign эта итерация фактуры не набрала (URL фетчились, но утверждения не прошли извлечение/верификацию) — их выводов здесь нет, не выдумываем; при необходимости — отдельный догон. Mindbox в выборку не попал (как и в прошлых ресёрчах — доступ к докам ограничен).

---

1. TL;DR — что берём в макеты

Тема 1 · Симуляция / dry-run превью пути

1. Dry-run превью пути — зрелый отраслевой стандарт, эталон = Braze «Preview User Paths». Кнопка Test Canvas в футере билдера → выбор тестового пользователя → Run Test. Прогон без реальных отправок (Liquid обрабатывается, но сообщения не уходят, вебхуки не срабатывают, User Update не пишется в реальный профиль). Показывает тайминги, какие сообщения/каналы ушли бы, и — ключевое — на branch-шагах выводит met/unmet criteria, т.е. объясняет «почему пошёл в эту ветку» (подтверждено, 8 вердиктов high). Это ровно то, что просит MLF-293 — берём как референс №1.

2. Подсветка предсказанного пути на canvas — тоже стандарт, и есть два визуальных языка:

   • HubSpot — при тесте путь записи подсвечивается зелёным в превью воркфлоу, «No actual actions will be executed» (подтверждено).
   • Adobe Journey Optimizer — путь прогрессивно зеленеет по мере продвижения профиля, на упавшем шаге — warning-символ (подтверждено). Для нас: зелёная подсветка выбранной ветки/рёбер на нашей cyan-канве + значок ошибки на проблемной ноде — проверенный паттерн.

3. «Почему пошёл сюда» = показать сработавшее условие + модель first-match. Индустрия объясняет ветвление одинаково: контакт идёт по ПЕРВОЙ ветке, чью условие выполнил (Braze Audience Paths «put the most important path first»; HubSpot «follows the first branch condition it meets»; Customer.io «evaluate criteria to determine which path») (подтверждено у всех трёх). В превью надо на branch-ноде показать: какие критерии выполнены/не выполнены и почему выбрана именно эта ветка.

4. Детерминизм достигается фиксацией входных данных. n8n даёт это через pin data (заморозка вывода ноды) и mock-датасеты — «iterate without operating on variable data», прод игнорирует pinned data (подтверждено). Для нашего критерия приёмки «unit на детерминизм» модель та же: симуляция оценивает предикаты веток против зафиксированного снапшота профиля, first-match, без побочных эффектов.

5. Выбор субъекта прогона: реальный ИЛИ тестовый профиль — да, но «тестовый» ≠ синтетика. HubSpot гоняет по конкретной существующей записи (поиск в дропдауне). У Braze «test user» — это реальный профиль, назначенный для тестов (а не фейк-аккаунт): claim, что Braze принимает «и реальные, и выделенные тестовые» как две категории, опровергнут — в доках только «select a test user» (3 вердикта REFUTED). Вывод: делаем выбор любого реального профиля как субъекта dry-run; отдельная сущность «тестовый профиль» индустрией не навязывается.

6. ⚠️ Anti-pattern (Adobe): «test mode» ≠ «dry run». У AJO Test mode РЕАЛЬНО ШЛЁТ сообщения (генерит реальное событие, задевает другие journey) — это НЕ прогон без отправок; no-send-симуляция у Adobe называется отдельным «Dry run» (3 claim'а про «test mode без отправок» ОПРОВЕРГНУТЫ). Урок для нас: симуляция обязана быть жёстко без сайд-эффектов (ни отправок, ни записи событий, ни мутации профиля) — иначе повторяем грабли Adobe.

Тема 2 · Live-debugger

7. Главный вывод: «живого real-time стрима контактов по нодам» в индустрии практически НЕТ. Отраслевой паттерн — пост-фактум просмотр логов исполнения по контакту, а не стрим в реальном времени. Ни у Braze, ни у HubSpot, ни у Customer.io, ни у n8n верифицированно не нашлось живого стрима контактов, текущих через ноды. Это значит: пункт MLF-293 «стрим в реальном времени» — амбициознее рынка; реалистичный MVP — near-real-time лента событий из cdp.automation_analytics_events (poll/refresh), а не настоящий streaming. Об этом — открытый вопрос №3 ниже.

8. Отраслевой стандарт debugger = per-contact execution log с drill-down. Три реализации, все (подтверждены):

   • HubSpot Enrollment history — вкладка в редакторе и на детальной странице; drill-down в конкретную запись: «View logs» → панель со всей историей воркфлоу, шаг каждого действия, таймстемпы, ошибки красным, интерактивная диаграмма подсветки пройденных веток и конечной точки; явно позиционируется как «troubleshoot why a record went down a particular branch». Хранение 6 мес, лимит 100k логов/день.
   • Customer.io — Activity Log (историчный, окно 30 дней, НЕ стрим); фильтр по Identified/Anonymous и по Activity Type (Failed Event, Bounced Email, Person Deleted, Skipped Update); per-customer логи на странице профиля; отдельный Campaign Journeys показывает «how the person was impacted by each workflow action» и «почему не вошёл / не получил сообщение».
   • n8n — Executions list на воркфлоу (фильтр по статусу Failed/Running/Success/Waiting, времени старта, custom-data из Code-ноды); Debug in editor / Copy to editor — подтягивает данные прошлого прогона на canvas и пинит в первую ноду для replay (это воспроизведение реального прошлого рана, НЕ синтетическая симуляция).

9. Фильтр по контакту — универсальный must-have debugger'а. HubSpot (поиск записи в enrollment history), Customer.io (профиль клиента + Identified/Anonymous), n8n (custom-data filter) — все дают сузить лог до одного субъекта (подтверждено). У нас это ложится прямо на AutomationExecutions (состояние/путь) + cdp.automation_analytics_events (события) со скоупом по контакту.

10. Замыкание debugger'а на «почему»: та же first-match модель, что и в симуляции. HubSpot в enrollment history подсвечивает пройденные ветки и endpoint для реальной записи — т.е. тот же UX-язык объяснения ветвления работает и для симуляции (предсказание), и для debugger'а (факт). Это позволяет нам сделать один визуальный слой объяснения для обеих фич.

---

2. Ключевой контекст: что уже есть в нашем макете

Проверено по editor-ui-redesign.html (текущее состояние UI после 5 ресёрчей):

• Canvas на @xyflow/react, cyan-акцент (#02CBEF): выделенная нода — cyan-ring+glow, выбранное ребро — cyan. Значит для симуляции нужен отдельный визуальный код (зелёный «пройденный путь» + приглушение непройденных веток), чтобы не конфликтовать с выделением.
• Тулбар уже несёт Publish, валидацию, версии, паузу. Кнопки «Симуляция» / «Debug» в тулбаре пока НЕТ — их и предстоит спроектировать (шаг 2).
• Инспектор ноды (правая панель) — есть; branch-ноды имеют короткое превью условия. Панель объяснения «почему пошёл сюда» естественно встроить рядом/в инспектор.
• Панели стрима / логов исполнения в макете НЕТ — новая поверхность (нижняя dock-панель или правый drawer).
• Светлая тема — фиксирована (memory); зелёная подсветка пути и красная ошибка должны читаться на светлом фоне (не тёмный «debug console»-язык).

То есть будущие макеты MLF-293 пристраивают к этому макету две новые поверхности: (а) режим симуляции поверх canvas + панель объяснения; (б) панель debugger'а (лента + фильтр по контакту).

---

3. Тема 1 · Симуляция / dry-run превью пути

3.1 Braze «Preview User Paths» — эталон (подтверждено, 8 вердиктов high)

Точка входа — кнопка Test Canvas в футере билдера Canvas → Select a test user → Run Test. Свойства прогона:

• Без реальных отправок: «These test runs act as quality assurance that your messages are sent to the right audience, all before sending your Canvas»; «Braze processes Liquid logic during a test run, even if you're not sending an actual test message»; вебхуки НЕ исполняются, User Update НЕ пишется в реальный профиль.
• Объяснение ветвления: «Steps with segmentation show the met or unmet criteria. Messages also show this for delivery validations and channel eligibility». Тест-юзер входит, даже если реально не eligible — и Braze показывает, почему он не прошёл критерий. Это и есть «почему пошёл сюда».
• Тайминг: Message/Delay-шаги показывают, когда пользователь продвинулся бы / получил сообщение (без реального ожидания). Время входа конфигурируемо (дата в прошлом/будущем) для проверки time-dependent логики.
• Поддерживаемые шаги: Message, Audience Path, Decision Split, Delay, Action Path, Experiment Path; неподдерживаемые — пропускаются.
• Модель ветвления (Audience Paths): «Users are progressed down the first branch whose criteria they meet, so put the most important path first»; порядок не редактируется после запуска; «Everybody Else» всегда последним. Оценка — в момент достижения шага.

*Важный нюанс (подтверждено):* сам компонент Audience Paths на canvas не объясняет inline, почему юзер попал в ветку, и не показывает per-branch счётчики — это выведено именно в превью-прогоне, а метрики живут отдельно в аналитике. У Braze есть и второй метод теста — дубль Canvas с ограничением входной аудитории до тест-юзеров и фильтром по email; это реальный запуск с реальными (тестовыми) отправками, не dry-run (подтверждено; claim, что «подход Braze — это НЕ чистый dry-run», ОПРОВЕРГНУТ — Braze ships именно dry-run как метод №2).

Берём: модель Braze один-в-один как референс режима симуляции — вход из тулбара, выбор профиля, прогон без сайд-эффектов, объяснение met/unmet на branch-нодах, конфигурируемое время входа (позже — не MVP).

3.2 HubSpot «Test your workflow» — зелёная подсветка + first-match (подтверждено)

• Вход: открыть воркфлоу → Test → выбрать конкретную запись (contact/company/deal/ quote/ticket) через поиск/дропдаун (реальный профиль драйвит симуляцию).
• «No actual actions will be executed» — чистый dry-run; для каждого действия показывается симулированный итог + таймстемп.
• Путь записи подсвечивается зелёным в превью воркфлоу.
• Объяснение ветвления: «Branch conditions are evaluated in order, and the record will follow the first branch condition it meets», по текущему состоянию записи; оценка — в момент, когда запись достигает ветки, без авто-переоценки при последующих изменениях.
• Опционально «Send preview» шлёт тест-письмо на адрес тестировщика, не контакта — QA сообщения отделён от симуляции пути.

Берём: зелёную подсветку пройденного пути на canvas + first-match объяснение как основной визуальный язык симуляции (совпадает с Braze по семантике, добавляет наглядную подсветку).

3.3 Adobe Journey Optimizer — важная развилка «test mode vs dry run» (частично опровергнуто — урок для нас)

• Подтверждено: путь прогрессивно зеленеет по мере продвижения профиля по journey; на упавшем шаге — warning-символ; в test mode может войти только тестовый профиль; на split'е всегда выбирается верхняя ветка (детерминизм ради воспроизводимости — реальные условия не оцениваются, чтобы протестить другую ветку, надо переставить ветки).
• ⚠️ Опровергнуто (3 вердикта): утверждение «AJO test mode гоняет профили БЕЗ реальных отправок» — ложь. Test mode шлёт реальные сообщения («a real event is generated, meaning it will also hit other journeys listening to this event», события в датасетах JOtestmode-*). No-send-симуляция у Adobe — это отдельная фича «Dry run».

Урок: терминологию «test mode» индустрия использует и для реальных тестовых отправок. Наш режим — это именно dry-run без сайд-эффектов; в UI стоит назвать его так, чтобы не путали с «отправить тестовое письмо» (у нас будущая отдельная кнопка). Приём Adobe «переставь ветки, чтобы протестить другой путь» — анти-паттерн относительно того, что просит MLF-293: мы, наоборот, хотим оценивать реальные условия против выбранного профиля и показывать сработавшее — это ближе к Braze/HubSpot, а не к AJO-split.

3.4 n8n — детерминизм через pin/mock + partial execution (подтверждено)

n8n технически ближе всех к нашему durable-движку, поэтому берём его механику детерминизма:

• Data pinning — заморозка вывода ноды: на будущих тест-прогонах n8n подставляет pinned data вместо повторного исполнения; «iterate without operating on variable data»; прод игнорирует pinned data (чёткое разделение test/live).
• Mock-датасеты (Code/Set-ноды, Customer Datastore fake dataset) — сфабриковать тестовые данные и гонять граф без обращения к реальным источникам (аналог выбора тест-профиля).
• Partial execution — «run from a node»: исполнить одну ноду + только те upstream-ноды, что нужны для её входа. Manual-исполнения «attempt to mimic production executions».

Берём (в модель, не в UI): для критерия приёмки «unit на детерминизм симуляции» — оценка веток против зафиксированного снапшота профиля (аналог pinned data), first-match, без внешних вызовов. «Partial run от ноды» — хорошая идея на будущее, не MVP.

3.5 SendPulse — чего у него НЕТ (отстройка) (из first-party доков, без 3-голосовой верификации)

Прямой конкурент для отстройки. По его же докам Automation360 (statistics, condition, filter, view-automated-flows):

• НЕТ симуляции / dry-run прогона тестового контакта без отправок.
• НЕТ подсветки выбранных веток на canvas и объяснения «почему контакт ушёл в ветку».
• НЕТ live-debugger'а и per-contact логов исполнения.
• Что есть: клик по ноде → сайдбар с настройками, агрегированной статистикой и списком контактов, для которых элемент запускался (пост-фактум, с фильтрацией списка по элементу). Condition/Filter — статичные Yes/No-ветки.

Формулировки — «отсутствие фичи» из первичных доков; риск ошибки низкий, но помечаю, что эти пункты не проходили 3-голосовую верификацию (в отличие от Braze/HubSpot/CIO/n8n).

Что это даёт нам: симуляция + объяснение ветвления + подсветка на canvas — прямая отстройка от SendPulse. У них — только агрегаты постфактум; у нас — предсказание пути «до» и объяснение «почему». Это сильный дифференциатор, ровно в духе project-memory про отстройку.

3.6 Свод по теме 1 — что стандарт, где развилки

Аспект	Отраслевой стандарт	Развилка / решение для нас
Прогон без отправок	Да (Braze, HubSpot)	Жёстко без сайд-эффектов (урок Adobe)
Подсветка пути на canvas	Зелёный (HubSpot, Adobe)	Зелёный «пройдено» + приглушение непройденного, поверх нашей cyan-канвы
«Почему пошёл сюда»	met/unmet criteria + first-match (Braze, HubSpot, CIO)	Показать сработавшее условие на branch-ноде
Субъект прогона	Реальная запись (HubSpot) / test user = реальный профиль (Braze)	Выбор любого реального профиля; отдельная сущность «тестовый» не обязательна
Детерминизм	pin/mock данных (n8n)	Снапшот профиля + first-match, без внешних вызовов
Конфиг времени входа	Есть (Braze past/future)	Не MVP, заложить место

---

4. Тема 2 · Live-debugger / стрим контактов + per-contact логи

4.1 Реальность: живого real-time стрима по нодам почти ни у кого нет

Верифицированно не нашлось ни одного вендора с настоящим real-time стримом контактов, текущих через ноды на canvas. Индустриальный паттерн — исторический, пост-фактум лог исполнения с фильтром по контакту:

• Customer.io Activity Log — окно 30 дней, явно не real-time стрим.
• HubSpot Enrollment history — историчный, хранение 6 мес.
• n8n Executions — список прошлых прогонов; «production executions не отображаются на canvas», только пост-фактум через вкладку Executions.

Следствие для MLF-293. Формулировка карточки «стрим контактов в реальном времени» — амбициознее рынка. Реалистичный MVP поверх нашей cdp.automation_analytics_events — near-real-time лента (периодический poll/refresh новых событий), а не настоящий streaming через WS. Это — открытый вопрос №3 к согласованию.

4.2 n8n — per-flow Executions + replay (подтверждено)

• Executions list на воркфлоу: фильтр по статусу (Failed/Running/Success/Waiting), времени старта, custom-data из Code-ноды.
• Debug in editor (failed) / Copy to editor (success) — подтягивает данные прошлого прогона в редактор и пинит в первую ноду, чтобы воспроизвести воркфлоу на точных исходных данных. Это replay реального прошлого рана, НЕ синтетическая симуляция — важное концептуальное разделение: у n8n «debug» = переигрывание факта, «test» (pin/mock) = dry-run.

Берём: статус-фильтр (Running/Success/Failed/Waiting) как модель фильтрации ленты исполнения; идею «открыть прошлый прогон контакта и посмотреть, что было» — как drill-down.

4.3 HubSpot Enrollment history — эталон per-contact drill-down (подтверждено)

• Вкладка в редакторе и на детальной странице воркфлоу; поиск конкретной записи → «View logs» → правая панель с полной историей: все события, шаг каждого действия, таймстемпы, ошибки красным.
• Интерактивная диаграмма: подсветка пройденных веток и достигнутого endpoint для этой записи — явно для «troubleshoot why a record went down a particular branch».
• Фильтры: диапазон дат, версия воркфлоу, «дошёл до конкретного шага».
• Ограничения: хранение 6 мес, 100k логов/день на воркфлоу.

Берём: это прямой референс нашего debugger'а. Фильтр по контакту → панель истории с таймстемпами и статусами шагов + подсветка пройденного пути на canvas — один-в-один ложится на AutomationExecutions (состояние/путь) + cdp.automation_analytics_events (события). Красный на ошибках — переиспользуем язык из guardrails-ресёрча.

4.4 Customer.io — Activity Log + per-person journey view (подтверждено)

• Activity Log (workspace-wide, окно 30 дней): фильтр по Identified/Anonymous и Activity Type (Failed Event, Bounced Email, Person Deleted, Skipped Update); клик → payload для разбора. Позиционируется как troubleshooting, не как стрим.
• Per-customer логи на странице профиля клиента — сужение до одного контакта.
• Campaign Journeys (per-person): «how the person was impacted by each workflow action along the way» + «почему не вошёл / не получил сообщение».
• Ветвление детерминированное для True/False и Multi-Split (first-match), Random Cohort — недетерминированный (это осознанное исключение).

Берём: типизированный фильтр событий (по статусу/типу — доставка, ошибка, пропуск) для нашей ленты; предупреждение — окно ретенции (у CIO 30 дней, у HubSpot 6 мес): для нашего debugger'а над cdp.automation_analytics_events надо решить окно/пагинацию (открытый вопрос №4).

4.5 Что это значит для нас (маппинг на AutomationExecutions + cdp.automation_analytics_events)

• Debugger = чтение AutomationExecutions (состояние/путь контакта) + ленты cdp.automation_analytics_events (события шага) со скоупом по workspace (tenancy) и фильтром по контакту (person_id) — прямой аналог HubSpot enrollment-history / CIO per-customer. Отдельный AutomationExecutionLogs не нужен.
• Лента событий с типами (node_entered/node_executed/node_error/message_skipped…) и таймстемпами (created_at) — как Activity Type у CIO.
• Подсветка пройденного пути на canvas для выбранного контакта — общий визуальный слой с симуляцией (§3), только источник данных фактический, а не предсказанный.
• «Real-time» — как near-real-time poll, не WS-стрим (см. §4.1 и вопрос №3); критерий приёмки «smoke на стрим» это допускает.

---

5. Что берём в макеты (шаг 2) — сводный чек-лист

Режим «Симуляция» (dry-run):

• Вход из тулбара редактора (кнопка «Симуляция», рядом с Publish/валидацией).
• Выбор реального профиля как субъекта (поиск в дропдауне, как HubSpot); отдельная сущность «тестовый профиль» не обязательна.
• Прогон без сайд-эффектов (ни отправок, ни событий, ни мутации профиля) — назвать в UI так, чтобы не путали с «отправить тестовое» (урок Adobe).
• Подсветка пройденного пути зелёным + приглушение непройденных веток (поверх cyan-канвы).
• На каждой branch-ноде — объяснение «почему»: met/unmet criteria, сработавшая ветка (first-match), в инспекторе/поповере.
• Значок ошибки на ноде, где симуляция упала бы (переиспользовать язык guardrails).
• (Не-MVP, заложить место) конфиг времени входа past/future; partial-run «от ноды».

Live-debugger:

• Новая поверхность — нижняя dock-панель / правый drawer (в макете её нет).
• Фильтр по контакту (обязателен) + фильтр по типу/статусу события (Running/Success/Failed/Waiting/Skipped).
• Лента исполнения из cdp.automation_analytics_events (нода, событие, таймстемп, статус; ошибки красным); состояние/путь контакта — из AutomationExecutions.
• Клик по контакту → подсветка его пройденного пути на canvas (общий слой с симуляцией).
• Drill-down в конкретный лог → payload/причина (как CIO/HubSpot «View logs»).
• «Real-time» = near-real-time refresh/poll, не WS-стрим (см. вопрос №3).

Общий визуальный слой: один механизм «подсветка пути + объяснение ветвления» на две фичи (предсказание в симуляции, факт в debugger'е) — как у HubSpot.

---

6. Решения по открытым вопросам (зафиксировано 2026-07-13)

Проговорено с М. Терентьевым; эти решения — бриф для макетов (шаг 2):

1. Субъект симуляции — ✅ любой реальный профиль (поиск/выбор из базы, как HubSpot). Отдельной сущности «тестовый контакт» не вводим (индустрия её не навязывает).
2. Строгий no-send — ✅ да. Симуляция — абсолютно без сайд-эффектов (ни отправок, ни событий, ни мутации профиля), в отличие от Adobe test mode. Отправка тестового сообщения — отдельная будущая кнопка, не часть симуляции.
3. «Real-time» в live-debugger — ✅ near-real-time (poll/refresh) лента из cdp.automation_analytics_events (напр. refresh каждые 3–5с), НЕ настоящий WS/SSE-streaming. Совпадает с рынком (живого стрима по нодам ни у кого нет), укладывается в ~12ч, критерий «smoke на стрим» проходит.
4. Окно ретенции debugger'а — ✅ последние 30 дней (как Customer.io), простая пагинация. Расширение до 6 мес — на потом при необходимости.
5. Единый слой объяснения ветвления — ✅ да, один визуальный механизм «подсветка пути + почему» на обе фичи (симуляция = предсказание, debugger = факт), как у HubSpot.
6. Глубина «почему» — ✅ met/unmet criteria + сработавшая ветка (first-match), уровень Braze. Полный разбор предиката со значениями атрибутов — не MVP, заложить место.

---

7. UX-развилки (для макетов, шаг 2) — решения

Проработаны поверх реальной сетки макета editor-ui-redesign.html: слева тёмный app-сайдбар (256px) + палитра-рельс (56→190px) + canvas + правый инспектор ноды 420px, сверху тулбар (Publish/версии/валидация).

A. Панель debugger'а — нижний dock (не правый drawer). Правый борт уже занят инспектором 420px; лента исполнения — горизонтально-табличные данные (время · контакт · нода · событие · статус), которым нужна ширина. Нижний dock даёт ментальную модель «консоль/лог» (как n8n Executions) и естественную вертикальную пару: путь контакта подсвечен на canvas ↑, его лог скроллится снизу ↓. Панель collapsible/resizable по высоте, по умолчанию свёрнута (не ест высоту canvas).

B. «Симуляция» — отдельный read-only режим (не transient-оверлей на редактируемой канве). Симуляция по природе read-only (во время прогона не редактируешь). Смешивать edit-аффордансы (drag, cyan-выделение) с результат-подсветкой — визуальная каша. Braze/HubSpot ровно так: ты входишь в прогон (Test Canvas / Test) — граф тот же, но это отдельный акт. В режиме тулбар меняется на контролы симуляции (выбор профиля → Run → повтор → выход), edit-аффордансы приглушены.

C. Симуляция и debugger — два входа, один общий движок отрисовки.

• «Симуляция» — на черновике (до публикации), субъект = выбранный профиль, без runtime-данных.
• «Debug/Мониторинг» — на опубликованном/активном flow, субъект = реальные контакты из AutomationExecutions (+ лента событий cdp.automation_analytics_events), нижний dock. Оба рисуют один и тот же слой «зелёный путь + почему на branch-ноде» (решение §6.5) — движок строим один раз. Разделяем входы, т.к. это разные стадии жизненного цикла (design-time QA vs run-time troubleshooting) с разным контекстом тулбара (draft vs active по guardrails-ресёрчу); общий визуальный язык маркетолог учит один раз.

D. Палитра прогона (разводим с брендовым cyan). Зелёный = пройденная нода/ребро; серый/приглушённый = не пройдено; красный = ошибка/упал бы (переиспользуем язык guardrails). Cyan-кольцо выделения в sim/debug-режиме подавляем (или тонкий контур), чтобы зелёный доминировал — иначе зелёная подсветка и cyan-выделение спорят на одной ноде.

E. «Почему» — бейдж на branch-ноде + деталь в инспекторе. Компактный бейдж на branch-ноде (какая ветка выбрана: «✓ открыл письмо» / «✗ не выполнил») + клик → инспектор с met/unmet деталью. Canvas остаётся читаемым, детали — по требованию (паттерн Braze/HubSpot: сам компонент ветвления не грузит inline-объяснением).

Итог для макетов: отдельный read-only режим «Симуляция» на черновике + нижний dock-debugger на активном flow, оба на общем движке подсветки (зелёный путь + бейдж «почему»), cyan-выделение уступает зелёному в режимах прогона.

---

8. Достоверность и ограничения этого ресёрча

• Верифицировано 3 голосами: Braze, HubSpot, Customer.io, n8n (+ Adobe как бонус) — 67/75 проверок подтверждено, 8 опровергнуто. Опровержения были содержательными и учтены в выводах (Adobe test-mode шлёт реально; Braze «test user» = реальный профиль, а не синтетика; Braze ships dry-run как отдельный метод).
• SendPulse — 10 утверждений сняты с first-party доков, но без 3-голосовой верификации; все — «отсутствие фичи», риск низкий, но помечено.
• Не набралось: Klaviyo, Iterable, ActiveCampaign (URL фетчились, но фактура не прошла извлечение/верификацию — не выдумываем). Mindbox в выборку не попал.
• Финальный синтез-агент упал (StructuredOutput); отчёт собран вручную из журнала верифицированной фактуры — не по памяти модели.
• Скоуп сознательно узкий — только две темы карточки; смежное (A/B, счётчики на нодах, аналитика) — в других ресёрчах (guardrails).

---

Приложение · Источники (first-party, верифицированные)

Braze

• Preview User Paths in Canvas — https://www.braze.com/docs/user_guide/messaging/canvas/testing_canvases/preview_user_paths
• Send Test Canvases — https://www.braze.com/docs/user_guide/messaging/canvas/testing_canvases/sending_test_canvases
• Audience Paths component — https://www.braze.com/docs/user_guide/messaging/canvas/canvas_components/audience_paths
• Measuring & testing with Canvas analytics — https://www.braze.com/docs/user_guide/messaging/canvas/testing_canvases/measuring_and_testing_with_canvas_analytics

HubSpot

• Test your workflow — https://knowledge.hubspot.com/workflows/test-your-workflow
• Workflow enrollment history — https://knowledge.hubspot.com/workflows/workflow-enrollment-history
• Use if/then branches — https://knowledge.hubspot.com/workflows/use-if-then-branches-in-workflows
• Review a record's workflow paths and actions — https://knowledge.hubspot.com/workflows/review-a-records-workflow-paths-and-actions

Customer.io

• Branch types — https://docs.customer.io/journeys/branches/ (канонический — https://docs.customer.io/messaging/send/workflows/branches/types/)
• Filter Activity Logs — https://docs.customer.io/journeys/people/find/filtering-logs/
• Campaign Journeys — https://docs.customer.io/journeys/send/campaigns/journeys/

n8n

• Debug executions — https://docs.n8n.io/build/understand-workflows/understand-executions/debug-executions
• View executions for a single workflow — https://docs.n8n.io/build/understand-workflows/understand-executions/view-executions-for-a-single-workflow
• Types of executions (manual/production) — https://docs.n8n.io/build/understand-workflows/understand-executions/types-of-executions
• Data pinning — https://docs.n8n.io/data/data-pinning/

Adobe Journey Optimizer (вне исходного списка, но верифицированный первоисточник)

• Testing the journey — https://experienceleague.adobe.com/en/docs/journey-optimizer/using/orchestrate-journeys/create-journey/testing-the-journey

SendPulse (first-party, без 3-голосовой верификации — «отсутствие фичи»)

• Automation360 statistics — https://sendpulse.com/knowledge-base/email-service/automation360/statistics
• Condition element — https://sendpulse.com/knowledge-base/email-service/automation360/automation360-condition
• Filter element — https://sendpulse.com/knowledge-base/email-service/automation360/automation-360-filter
• View automated flows — https://sendpulse.com/knowledge-base/email-service/automation360/view-automated-flows

Не набралось фактуры (для возможного догона): Klaviyo (help.klaviyo.com/hc/en-us/articles/115002779471, .../115002779351), Iterable (support.iterable.com/hc/en-us/articles/10044063369492, .../5367225442324), ActiveCampaign, Mindbox.