@besales/mcp 0.25.0 → 0.31.0

package/dist/resources/workflows/audit-dialogues.md

@@ -0,0 +1,89 @@
+# Аудит production-диалогов
+
+## Цель
+
+Read-only разбор реальных переписок через `besales_dialogues_query` и
+`besales_dialogue_transcript`: найти ошибки агента, доказуемо сопоставить их с
+выполненными trigger-actions и подготовить изменения правил и regression-кейсы.
+Ничего в агенте, CRM или платформе этот workflow не меняет.
+
+## Выборка
+
+1. Если пользователь не задал период, возьми последние 7 суток и явно укажи это в отчёте.
+2. Для общего аудита фильтруй по периоду, платформам и `has_messages=true`.
+3. Для аудита созданных заявок добавь:
+   - `action_type=["GETCOURSE_CREATE_DEAL"]`;
+   - `action_success=true`;
+   - `action_execution_mode="production"`.
+   `GETCOURSE_SEND_PAYMENT_LINK` проверяй отдельной выборкой как коммерческий side effect:
+   он может работать с существующим заказом и не доказывает создание новой заявки.
+4. Обойди все страницы `besales_dialogues_query` по `cursor`. Не выдавай первую страницу
+   за полную выборку.
+5. Для каждого `conversationId` дочитай все страницы `besales_dialogue_transcript`.
+   Объединяй `turns` и `triggerExecutions`; `turn.messageId` связывает реплику с действием.
+
+Action-фильтр применяется к действию на сообщении внутри заданного окна дат. Это позволяет
+отличить заявку периода от старого действия в длинном диалоге.
+
+## Что считать созданной заявкой
+
+- `GETCOURSE_CREATE_DEAL`, `success=true`, `resultSummary.skipped=false` и есть
+  `dealNumber` или `dealId` — подтверждённое создание.
+- `executionMode=test` — симуляция, в production-статистику не включать.
+- `resultSummary.skipped=true` — идемпотентный пропуск, новую заявку не считать.
+- Успешное действие без безопасного идентификатора — факт выполнения подтверждён, но создание
+  пометь `REVIEW`, не додумывай результат.
+- Сырой result намеренно не доступен. Не пытайся получить его прямым SQL.
+
+## Классификация
+
+Каждому подтверждённому действию присвой один итог:
+
+| Итог | Когда |
+|---|---|
+| `JUSTIFIED` | Новый потенциальный клиент выражает релевантный интерес, готовность обсуждать продукт/условия или просит следующий коммерческий шаг. |
+| `FALSE_POSITIVE` | Действующий/оплативший ученик решает доступ, обучение, материалы, домашнее задание, расписание, возврат или иную поддержку без новой покупки. |
+| `REVIEW` | Контекста недостаточно, намерение смешанное либо действие не подтверждено идентификатором. |
+
+Дополнительно поставь тип обращения: `NEW_SALES`, `EXISTING_CUSTOMER_SUPPORT`,
+`ACCESS_PROBLEM`, `TECH_SUPPORT`, `BILLING_SUPPORT`, `OTHER`.
+
+## Доказательства
+
+- Приведи 1-3 коротких фрагмента клиента с `sentAt` и `messageId`.
+- Укажи trigger name, action type, action time и deal number/id, если они есть.
+- Отделяй наблюдаемый факт от вывода модели.
+- Не выводи телефоны, email, токены и внешние идентификаторы без необходимости.
+- Не утверждай, что оператор написал сообщение: `isAi=false` означает оператор ИЛИ
+  историческое сообщение бота.
+
+## Масштаб
+
+- До 200 диалогов анализируй все.
+- Более 200: если пользователь явно просит весь массив — анализируй весь массив батчами;
+  иначе возьми стратифицированную выборку по платформе и trigger name, назови размер выборки
+  и не экстраполируй абсолютные числа на всю совокупность.
+
+## Формат отчёта
+
+1. **Охват:** период, платформы, фильтры, найдено/прочитано/не удалось прочитать.
+2. **Итог:** confirmed actions, justified, false positives, review, false-positive rate.
+3. **Ошибочные заявки:** таблица `conversationId | action | deal | тип | решение | доказательство`.
+4. **Пограничные случаи:** отдельная таблица `REVIEW`.
+5. **Повторяющиеся причины:** паттерны, частота только по фактически разобранной выборке.
+6. **Изменения:** конкретные правила промпта/триггера, но без автоматического применения.
+7. **Regression-кейсы:** входной контекст, ожидаемая реакция агента и запрещённое действие.
+
+Нулевой результат тоже фиксируй: какие фильтры применялись и что именно не найдено.
+
+## Не использовать для статистики рассылок
+
+Этот workflow анализирует содержание диалогов и trigger-actions, но не воспроизводит метрики
+страницы `/broadcast-analytics`. Для «сколько отправлено/доставлено/ответило по дням» используй
+`besales_broadcast_analytics_get`, для результатов отдельных запусков —
+`besales_broadcast_cohorts_list`. `besales_dialogues_query` считает диалоги, а транскрипт содержит
+реплики; оба грейна отличаются от строк получателей волн.
+
+Название CRM-воронки не обязано присутствовать в транскрипте. Если нужен справочник CRM pipelines,
+вызови `besales_crm_list`, затем `besales_crm_pipeline_list`. Поле `funnel` в аналитике рассылок —
+отдельная бизнес-воронка волны и приходит из analytics tool.

package/dist/resources/workflows/compare-models.md

@@ -20,7 +20,7 @@
 
 2. **`besales_model_comparison_run_start`** `{ agent_id, models?, dialogue_count? }`
    — запуск (async). По умолчанию `dialogue_count=5`; `models` опционально (тогда
-   набор по умолчанию). До **18 моделей** и **20 диалогов**, если оператор просит
+   набор по умолчанию). До **21 модели** и **20 диалогов**, если оператор просит
    больше. Возвращает `run_id`.
 
 3. **`besales_model_comparison_get`** `{ agent_id, run_id }` — поллируй до