@besales/mcp 0.48.0 → 1.0.0-beta.4

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

@@ -4,7 +4,7 @@
 
 Read-only разбор реальных переписок через `besales_dialogues_query` и
 `besales_dialogue_transcript`: найти ошибки агента, доказуемо сопоставить их с
-выполненными trigger-actions и подготовить изменения правил и regression-кейсы.
+выполненными действиями и подготовить изменения правил и regression-кейсы.
 Ничего в агенте, CRM или платформе этот workflow не меняет.
 
 ## Выборка
@@ -13,26 +13,37 @@ Read-only разбор реальных переписок через `besales_d
 2. Для общего аудита фильтруй по периоду, платформам и `has_messages=true`.
 3. Для аудита созданных заявок добавь:
    - `action_type=["GETCOURSE_CREATE_DEAL"]`;
-   - `action_success=true`;
    - `action_execution_mode="production"`.
+   `action_success` здесь НЕ ставь: исход каждого шага считай по транскрипту — отчёту нужны и
+   подтверждённые заявки, и дубли, и неизвестные исходы (`REVIEW`). `action_success=true` годится
+   только для быстрого счёта подтверждённых: провалы и неизвестные исходы он отсекает.
    `GETCOURSE_SEND_PAYMENT_LINK` проверяй отдельной выборкой как коммерческий side effect:
    он может работать с существующим заказом и не доказывает создание новой заявки.
 4. Обойди все страницы `besales_dialogues_query` по `cursor`. Не выдавай первую страницу
    за полную выборку.
 5. Для каждого `conversationId` дочитай все страницы `besales_dialogue_transcript`.
-   Объединяй `turns` и `triggerExecutions`; `turn.messageId` связывает реплику с действием.
+   Объединяй `turns` и `actionExecutions`: исполнение лежит ровно на одной странице.
+   `triggerMessageId` исполнения — реплика человека, начавшая ход; `responseMessageId` —
+   ответ того же прогона.
 
-Action-фильтр применяется к действию на сообщении внутри заданного окна дат. Это позволяет
-отличить заявку периода от старого действия в длинном диалоге.
+Фильтр действия — по типу ШАГА: тип, успех и окно дат сходятся на одном шаге одного
+исполнения, окно считается по времени исполнения. Это отличает заявку периода от старого
+действия в длинном диалоге. `total` манифеста — число диалогов, а не заявок.
 
 ## Что считать созданной заявкой
 
-- `GETCOURSE_CREATE_DEAL`, `success=true`, `resultSummary.skipped=false` и есть
-  `dealNumber` или `dealId` — подтверждённое создание.
-- `executionMode=test` — симуляция, в production-статистику не включать.
-- `resultSummary.skipped=true` — идемпотентный пропуск, новую заявку не считать.
-- Успешное действие без безопасного идентификатора — факт выполнения подтверждён, но создание
+- Шаг `stepType=GETCOURSE_CREATE_DEAL` со `status=OK`, `reusedOpenInvoice=false` и есть
+  `dealNumber` или `dealId` — подтверждённое создание. При `reusedOpenInvoice=true` шаг
+  успешно использовал открытый счёт, но нового заказа нет; считай его отдельно от созданных.
+- `status=SKIPPED` — идемпотентный пропуск (дубль), новую заявку не считать.
+- Шаг с `outcomeUnknown=true` (`FAILED` или `OK`) — исход неизвестен, сделка могла создаться:
+  пометь `REVIEW`.
+- Исполнение с `abandoned=true` — неизвестен исход только НЕЗАВЕРШЁННОГО шага: шаг `OK` с номером
+  сделки в том же исполнении остаётся подтверждённым; шаг, до которого исполнение не дошло, в
+  `steps` не записан вовсе.
+- Успешный шаг без безопасного идентификатора — факт выполнения подтверждён, но создание
   пометь `REVIEW`, не додумывай результат.
+- `runId=null` — прогон неизвестен (ручной запуск, перенесённая строка), а не «действий не было».
 - Сырой result намеренно не доступен. Не пытайся получить его прямым SQL.
 
 ## Классификация
@@ -51,7 +62,7 @@ Action-фильтр применяется к действию на сообще
 ## Доказательства
 
 - Приведи 1-3 коротких фрагмента клиента с `sentAt` и `messageId`.
-- Укажи trigger name, action type, action time и deal number/id, если они есть.
+- Укажи имя действия (`actionName`), тип шага, время исполнения и номер/id сделки, если они есть.
 - Отделяй наблюдаемый факт от вывода модели.
 - Не выводи телефоны, email, токены и внешние идентификаторы без необходимости.
 - Не утверждай, что оператор написал сообщение: `isAi=false` означает оператор ИЛИ
@@ -61,7 +72,7 @@ Action-фильтр применяется к действию на сообще
 
 - До 200 диалогов анализируй все.
 - Более 200: если пользователь явно просит весь массив — анализируй весь массив батчами;
-  иначе возьми стратифицированную выборку по платформе и trigger name, назови размер выборки
+  иначе возьми стратифицированную выборку по платформе и имени действия, назови размер выборки
   и не экстраполируй абсолютные числа на всю совокупность.
 
 ## Формат отчёта

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

@@ -15,15 +15,15 @@
    сейчас). Выбери **~5 моделей** под use-case агента (продажи → живой тон;
    рассуждение → reasoning-модели; дёшево/много → budget). `defaultModelIds` —
    разумный набор по умолчанию, если оператор не назвал модели.
-   - `available=false` → провайдер не настроен. GLM и prefixed Qwen (`qwen/*`) идут
-     через OpenRouter (`OPENROUTER_API_KEY`), а `qwen3.8-flash` — напрямую через
-     Alibaba DashScope (`DASHSCOPE_API_KEY`) на стороне prompt-services; `glm-5.3`,
-     `glm-5.3-flash`, `glm-5.3-flashx` без префикса — напрямую через Z.AI (`ZAI_API_KEY`),
-     это те же модели, что `z-ai/glm-5.3-*` через OpenRouter.
+   - `available=false` → модель сейчас недоступна. Модели с префиксом провайдера (claude, grok,
+     deepseek, gemini, GLM, `qwen/*` и другие) идут через OpenRouter (`OPENROUTER_API_KEY`), а
+     `qwen3.8-flash` — напрямую через Alibaba DashScope (`DASHSCOPE_API_KEY`) на стороне prompt-services.
+     Для GLM бери `z-ai/glm-5.3`, `z-ai/glm-5.3-flash`, `z-ai/glm-5.3-flashx` через OpenRouter;
+     в запуск передавай runnable id из текущего каталога.
 
 2. **`besales_model_comparison_run_start`** `{ agent_id, models?, dialogue_count? }`
    — запуск (async). По умолчанию `dialogue_count=5`; `models` опционально (тогда
-   набор по умолчанию). До **35 моделей** и **20 диалогов**, если оператор просит
+   набор по умолчанию). До **36 моделей** и **20 диалогов**, если оператор просит
    больше. Возвращает `run_id`.
 
 3. **`besales_model_comparison_get`** `{ agent_id, run_id }` — поллируй до

package/dist/resources/workflows/connect-crm-from-scratch.md

@@ -52,13 +52,11 @@ field-mapping / operators.
 
 Уникальность: один AmoCRM на workspace (`(workspaceId, AMOCRM)`).
 
-**Follow-up шаг — переписка в карточке сделки.** `READY` даёт управление сделками и контактами,
-но сообщения бота в карточке НЕ появятся, пока AmoCRM не зарегистрирует чат-канал: `channelId`
-и `channelSecretKey` выдаёт только их техподдержка, по письму заданной формы. Адрес вебхука и
-готовый текст письма отдаёт `besales_crm_amocrm_channel_registration` — пересылай их человеку
-дословно, адрес сам не собирай. Ключи от поддержки он привяжет в интерфейсе
-(`POST /api/amo-crm/channel-connect`); через MCP этого шага нет. Предупреди об этом шаге сразу,
-как о local-app у Bitrix24, — иначе клиент считает настройку законченной, а переписки не видит.
+**Отдельный шаг — переписка в карточке сделки.** Сразу предупреди: `READY` подключения не
+означает регистрацию чат-канала amoCRM. Получи текст заявки через
+`besales_crm_amocrm_channel_registration` и передай человеку дословно, адрес не собирай сам.
+Выданные поддержкой `channelId` и секрет человек привязывает в интерфейсе, минуя ассистента.
+Подробности — `besales://docs/crm-integration`.
 
 ## BITRIX24 — подключение
 
@@ -71,11 +69,6 @@ field-mapping / operators.
 Несекретное: `account_domain` (`school.getcourse.ru`, опц. `managed_tag_prefix`).
 Секрет: `school_api_key` (опц. `legacy_api_key`). `READY` = read-only API-проба прошла.
 
-## TELEGRAM (Forum CRM) — подключение
-
-Несекретное: `forum_group_id` (ID форум-группы). Секрет: `crm_bot_token`. `READY` =
-`getMe` бота прошёл.
-
 ## Активация
 
 CRM создаётся в `status` и работает (sync воронок, выгрузка звонков, запись лидов) только
@@ -88,6 +81,16 @@ CRM создаётся в `status` и работает (sync воронок, в
   переключиться, либо чтобы повторно включить CRM, авто-отключённую по ошибке авторизации
   (`401/403`). ⚠️ Это деактивирует текущую активную — предупреди пользователя перед вызовом.
 
+
+## Входящие события amoCRM (адрес вебхука)
+
+amoCRM шлёт события сделок на адрес, который человек вписывает в настройках вебхуков своего
+аккаунта. Адрес несёт пропуск, поэтому через ассистента он НЕ проходит: закажи одноразовую
+ссылку `besales_crm_webhook_url_reveal({ crm_id })` и передай человеку — страница за ссылкой
+потребует входа и права управлять CRM и покажет адрес один раз. Ссылка одноразовая и с
+ограниченным сроком; просроченную заказывай заново тем же инструментом. У прочих провайдеров
+такого адреса нет — инструмент ответит отказом.
+
 ## Что дальше (CRM READY + активна)
 
 Pipelines: `besales_crm_pipeline_list` / `besales_crm_pipeline_create`,

package/dist/resources/workflows/connect-datasource-from-scratch.md

@@ -58,14 +58,15 @@ Ordering-инвариант: connection `READY` прежде чем назнач
 
 `besales_datasource_vectorize({ data_source_id, catalog_external_code, enabled: true })` —
 включает семантический поиск по каталогу (роль `PRODUCT_CATALOG` обязательна, подключение
-`ACTIVE`): синк в Pinecone. `enabled: false` — удаление векторов. Нужно, когда товаров много
-и поиск по точному `$filter` не годится («покажи что-то для дома до 5000»).
+`ACTIVE`): индексация в PostgreSQL + pgvector. `enabled: false` — удаление векторов. Нужно,
+когда товаров много и поиск по точному `$filter` не годится («покажи что-то для дома до 5000»).
 
 ## Чтение/запись в диалоге — это ДЕЙСТВИЯ ТРИГГЕРОВ (не tools агента)
 
 Финальный шаг «агент реально читает/пишет 1С в разговоре» настраивается через **существующий**
-`besales_trigger_upsert` (НЕ через `besales_datasource_*`). У агента ровно 3 attachable tool
-(`run_trigger`/`send_pic`/`call_qa`) — 1С-логика живёт внутри действий триггера. Форма действия:
+`besales_trigger_upsert` (НЕ через `besales_datasource_*`). Это совместимая поверхность настройки:
+1С-логика исполняется серверными action steps под ActionGovernor, а модель получает только
+разрешённый action key и не выбирает connection ID или тип шага. Форма действия:
 
 ```
 besales_trigger_upsert({ platform_id, agent_id, name, condition, actions: [{

package/dist/resources/workflows/extract-from-document.md

@@ -9,8 +9,9 @@
 - xlsx: `besales_file_upload_request` → browser upload → `besales_file_upload_status` →
   `besales_workbook_inspect`.
 - Google Sheets: `besales_workbook_inspect` по URL.
-- Inspect показывает инвентаризацию и sample. Нужные вкладки дочитай через
-  `besales_workbook_sheet_read`; `readError` не означает пустой лист.
+- Inspect даёт инвентаризацию и sample. Нужные листы дочитай через
+  `besales_workbook_sheet_read`; `readError` не означает пустой лист, а
+  `sourceTruncated=true` запрещает выдавать доступную часть за полный источник.
 - Иначе: прочитай содержимое и классифицируй сам.
 - Глубже про таксономию вкладок — concept `besales://concepts/workbook-classification`.
 
@@ -24,7 +25,7 @@
 | Прайс / каталог / таблица | `besales_knowledge_table_link` либо `besales_workbook_to_knowledge_document` |
 | Продуктовый / бизнес-текст | `besales_knowledge_document_upload` |
 | Brand-guide / tone / persona | ICP tone (`besales_icp_create`) + `besales_behavior_update` |
-| Выгрузка диалогов из CRM (amoCRM) | `besales_workbook_extract_amocrm_leads` → `besales_icp_import_dialogues` → `besales_icp_import_status` |
+| Выгрузка диалогов из CRM (amoCRM) | `besales_workbook_extract_amocrm_leads`; в v2 найденные lead ID сохраняются для отдельного аудио-конвейера и не передаются в текстовый `besales_icp_import_dialogues` |
 | Значения (имя компании, телефон, часы) | `besales_variable_create` |
 | Общий PDF / договор / политика / непонятный тип (fallback) | `besales_knowledge_document_upload` — дефолт, если ничего выше не подошло |
 
@@ -33,11 +34,12 @@
 Если что-то ушло в knowledge — не забудь создать/привязать space:
 `besales_knowledge_space_create` → `besales_knowledge_space_channel_link_upsert`.
 
+После раскладки сохрани решения через `besales_workbook_classification_update`. Архивируй
+provenance только по просьбе пользователя через `besales_workbook_archive`; созданные документы
+при этом остаются.
+
 ## Принцип
 
 Документ редко = «одна сущность». Прайс-лист несёт и таблицу для RAG, и переменные
 (контакты), и иногда tone. Раскладывай по всем релевантным целям за один проход.
 Затем возвращайся в `besales://workflows/platform-setup-from-scratch`.
-
-Перед записью результатов сохрани решения через `besales_workbook_classification_update`.
-Архивируй исходник только по просьбе пользователя через `besales_workbook_archive`.

package/dist/resources/workflows/operator-edit.md

@@ -0,0 +1,15 @@
+# Ручная связь CRM-оператора
+
+Прочитайте `besales_crm_operator_list` и возьмите `operator_id` и `editVersion` из выбранной строки.
+В `besales_crm_operator_update` можно отправить `expected_version`, `workspace_member_id`
+и прежние `is_operator` / `is_sdr`. Версия обязательна при изменении `workspace_member_id`, включая `null`; старый вызов
+только с флагами сохраняется без версии. Версия сама по себе не является правкой.
+
+`workspace_member_id` — users.id текущего сотрудника с ролью OPERATOR/MANAGER. Почты CRM
+и Besales могут различаться. `null` снимает связь вручную; пропуск сохраняет её.
+Ручное снятие сохраняется после синхронизации. Новый профиль сотрудника создаётся только
+если отсутствует, выключенным без логинов; существующая готовность остаётся прежней.
+
+При 409 сохраните введённые поля, перечитайте строку для сравнения и дождитесь явного решения
+человека. Не подставляйте currentVersion автоматически и не повторяйте PATCH. Ошибка содержит
+безопасные идентификаторы и текущую версию, без сырой строки пользователя и секретов.

package/dist/resources/workflows/platform-setup-from-scratch.md

@@ -66,17 +66,21 @@ Backbone happy-path настройки с нуля по **6-фазной мод
    а) построй структуру скрипта (этапы/ветки/реплики/переходы) → `besales_dialog_script_update`
       (поле `dialog_script` — SUMMARY/скелет; читать/сверять — `besales_dialog_script_get`);
    б) промпт: `besales_prompt_generate_get_instructions` → локально выполни стадии →
-   `besales_prompt_generate_submit`. До `besales_prompt_finalize` передай полученный текст как
-   `candidate_prompt` в `besales_sandbox_run_start` с `mode=single_agent`; после COMPLETED + findings
-   сверь `testedConfiguration.promptContentHash` и только затем активируй отдельным finalize.
-   §6 пиши НА ОСНОВЕ скрипта, но подробнее и независимо. Структура — `besales://docs/prompt-anatomy`.
-3. `besales_behavior_update` — приветствие: ТОЛЬКО `bot_greeting` текстом, БЕЗ кнопок (дефолт
-   «Привет!/Hello» → язык аудитории; для INBOUND открывает диалог). `greeting_buttons` opt-in — лишь
-   по явному запросу; остальной behavior (persona/тон/typing) — фаза Enrich. `besales://docs/agent-behavior`.
+   `besales_prompt_generate_submit`. До публикации передай полученный текст как `candidate_prompt`
+   в `besales_sandbox_run_start` с `options.mode=single_agent`. Дождись `COMPLETED` и findings,
+   сверь `testedConfiguration.promptContentHash` с SHA-256 проверенного текста; затем отдельно,
+   после подтверждения пользователя, вызови `besales_prompt_finalize`. §6 пиши НА ОСНОВЕ скрипта,
+   но подробнее и независимо. Структура — `besales://docs/prompt-anatomy`.
+3. `besales_behavior_update` — приветствие: поле `text`, БЕЗ кнопок (дефолт «Привет!/Hello» →
+   язык аудитории; для INBOUND открывает диалог). ⚠️ У НОВОГО канала секции поведения ещё нет,
+   сливать не с чем — первая запись `greeting` обязана нести `text`, `buttons`,
+   `keyboard_type` и `popup_delay_seconds` целиком; дальше присылай только меняемые поля.
+   `buttons` opt-in — лишь по явному запросу; остальной behavior (persona/тон/typing) — фаза
+   Enrich. `besales://docs/agent-behavior`.
 4. **Статика:** `besales_prompt_lint` + анализ `besales_prompt_analyze_get_instructions` /
    `besales_prompt_analyze_submit`.
 5. **Симуляция:** `besales_sandbox_run_start` по тест-сценариям (фаза 3) → findings → правки.
-   Черновик проверяй через `candidate_prompt`: это не меняет ответы работающего бота.
+   `candidate_prompt` проверяет черновик без публикации в работающем боте.
    Глубже — `besales://workflows/iterate-with-sandbox`.
 6. **Выбор модели (только здесь или по запросу — дорого):** `besales://workflows/compare-models`
    (`besales_model_catalog_list` → `besales_model_comparison_run_start` → `_get` → `_eval_submit`).
@@ -119,83 +123,68 @@ Backbone happy-path настройки с нуля по **6-фазной мод
 
 ## Маршруты обычных задач
 
-Шесть фаз выше нужны для новой настройки. Свободный вопрос или точечная правка не запускают
-полный мастер. Каждый маршрут начинается с `besales_workspace_current`, затем выбирает объект
-обычным именем и заканчивается перечитыванием либо lifecycle-status.
+Шесть фаз нужны для новой настройки. Свободный вопрос или точечная правка не запускают весь
+мастер. Сначала `besales_workspace_current`, затем выбор объекта по имени; завершай маршрут
+повторным чтением или проверкой статуса операции.
 
-### Новый FAQ-бот
+### FAQ или продажи
 
-1. Предусловие: канал `READY`; получить `platform,agent_summaries,readiness` через
-   `besales_platform_context_get`.
-2. Собрать темы ответов и ограничения; ICP предложить, но не делать gate.
-3. Создать агента, положить факты в Q&A/RAG, сгенерировать prompt и greeting.
-4. Создать FAQ-сценарии, выполнить sandbox, получить findings.
-5. Завершение: привязка агента/knowledge видна в context, run `COMPLETED`, quality policy
-   выполнена. Иначе назвать конкретный следующий tool и аргументы.
-
-### Новый sales-бот
-
-Тот же путь, но до финализации обязательны релевантный ICP и скрипт диалога. CRM нужна только
-если задача включает сделку, поля или стадии. Наличие строки CRM не доказывает live authorization:
-проверить setup status/health и фактические pipelines.
+На READY-канале прочитай `besales_platform_context_get`, собери темы и ограничения, создай
+агента, знания, промпт и приветствие. FAQ-боту предложи ICP без обязательного шага; sales-боту
+до финализации нужны релевантный ICP и скрипт. Подготовь сценарии, получи завершённый sandbox и
+findings; привязки знаний проверь в context, качество — по readiness. Если что-то не доказано,
+назови следующий инструмент и недостающие аргументы.
 
 ### Правка работающего агента
 
-1. `besales_agent_list(query=...)`; при нескольких совпадениях показать их и остановить выбор.
-2. `besales_agent_get`/`besales_prompt_patch_get` и полный относящийся к записи снимок.
-3. Изменить draft или одиночным `besales_prompt_batch_start` с idempotency key.
-4. Протестировать версию изолированно; commit/finalize — отдельный шаг.
-5. Перечитать agent/version. `skippedCount > 0`, lint failure или stale test не являются успехом.
-
-### Документ → знания, правила или ICP
-
-Использовать `besales://workflows/extract-from-document`. Inspect/sample не равны полной вычитке.
-Для другого языка сначала перечислить листы/разделы и дать саммари на языке диалога. Чтение
-продолжается; перед записью чисел, процентов и условий получить подтверждение, если человек их
-ещё не согласовал. Завершение: source fingerprint, сохранённая classification, созданные IDs и
-повторное чтение связей.
-
-### CRM или 1С
-
-CRM: `besales://workflows/connect-crm-from-scratch`; 1С/data source:
-`besales://workflows/connect-datasource-from-scratch`. Browser setup поллится до `READY`.
-После записи проверить live health/catalog/pipeline, а не только существование строки.
+`besales_agent_list` с `query` → при нескольких совпадениях согласуй выбор →
+`besales_agent_get` → полный снимок и черновик `besales_prompt_patch_*`. Для пакетной операции
+есть `besales_prompt_batch_start` с `idempotency_key`; её исход проверяй через
+`besales_prompt_batch_status` или `besales_prompt_batch_by_key`. Проверка кандидата изолирована
+от публикации; commit/finalize — отдельное согласованное действие. Перечитай итоговую версию:
+`skippedCount > 0`, ошибка линтера или устаревший тест не означают успех.
 
-### Follow-up
+### Документ и подключение источников
 
-Прочитать полный config последовательности и ограничения площадки, затем
-`besales_followup_sequence_upsert`. Проверить повторным list и статистикой шагов. Сезонная пауза,
-disabled draft и отсутствие ожидаемого запуска различаются; closed dialogue не получает касаний.
+Документ → `besales://workflows/extract-from-document`: sample недостаточен для полной вычитки.
+Для другого языка сначала перечисли листы/разделы и дай саммари на языке диалога; числа,
+проценты и условия согласуй до записи, если они ещё не согласованы. Зафиксируй классификацию,
+идентификаторы созданных объектов и повторно проверь связи.
 
-### Подготовка и проверка рассылки
+CRM → `besales://workflows/connect-crm-from-scratch`; 1С →
+`besales://workflows/connect-datasource-from-scratch`. Дождись `READY`, затем проверь доступный
+каталог и воронки. Само наличие строки подключения не доказывает живую авторизацию.
 
-Сначала preview/dry-run и полный список ошибок/контактов, потом явное подтверждение фактической
-отправки. Сохранить `idempotency_key` до вызова, затем поллить соответствующий status. При
-`OUTCOME_UNKNOWN` искать запуск по receipt/key и не повторять отправку.
+### Дожимы, рассылки и аналитика
 
-### Исходящая аналитика
+Для follow-up прочитай полный config и ограничения канала, сохрани все шаги при замене и
+перечитай цепочку: `besales://docs/follow-up`. Выключенная цепочка и отсутствие ожидаемого
+запуска — разные состояния.
 
-`besales_broadcast_analytics_get`: передать период, `view=cohort|period|entry` и нужное зерно.
-`summary.totals` — канонический общий итог денег; multichannel rows не суммировать повторно.
-Исходящие метрики не доказывают отсутствие входящих сообщений.
+Для рассылки сначала покажи preview и доступные ошибки/причины пропуска, получи подтверждение
+живой отправки; затем проверяй статус. Если инструмент принимает `idempotency_key`, сохрани его
+до вызова. При `OUTCOME_UNKNOWN` ищи receipt/запуск, повтор не разрешён автоматически.
 
-### Бот молчит или не доставил
+Исходящий отчёт — `besales_broadcast_analytics_get`: период, `view=cohort|period|entry` и нужное
+зерно. Общие неденежные итоги бери из `totals`, денежные плитки — из `moneyTotals.paidAmount` и
+`moneyTotals.indirectAmount`; строки по каналам не суммируй повторно. Исходящие метрики не
+доказывают отсутствие входящих сообщений.
 
-1. Выбрать контакт/сообщение по обычным данным; если MCP-пути чтения нет, честно назвать
-   unsupported и перейти в UI, не угадывать причину.
-2. По времени проверить mute/silence/operator status, routing/model, RAG evidence,
-   trigger/action execution, transport и delivery receipt.
-3. Отсутствие evidence назвать «не найдено свидетельство», а не нулём.
-4. Завершение — одна доказанная причина либо перечень точных недостающих данных.
+### Бот молчит и аудит
 
-### Аудит
+Выбери контакт и сообщение по обычным данным. Если MCP не даёт нужного чтения, назови пробел и
+перейди в UI. По времени проверь доступные свидетельства паузы/оператора, маршрута и модели,
+знаний, исполнения действий и доставки. Отсутствие свидетельства не равно нулю. Результат —
+доказанная причина либо точный список недостающих данных.
 
-`besales://workflows/audit-dialogues`: start → status → result/findings. Pending/failed/unknown
-не становятся success; доказательства маскируются и не копируются без необходимости.
+Сырой аудит → `besales://workflows/audit-dialogues`; отчёт ревизора →
+`besales_dialogue_audit_runs_list` / `besales_dialogue_audit_run_get` /
+`besales_dialogue_audit_findings`. Pending/failed/unknown не являются успехом; ненужные PII
+маскируй и не копируй.
 
 ### Продолжение после ошибки
 
-401 → reconnect конкретного workspace; 403 → добавить названный scope, сохранив прежние;
-410 → новый get_instructions; 422 → исправить поля; 429 → ждать `retryAfter`; timeout/5xx
-неидемпотентной мутации → `OUTCOME_UNKNOWN`, receipt/status/list. Перед продолжением перечитать
-объект и права: сохранённый план не заменяет свежую проверку.
+401 → восстанови подключение нужного workspace; 403 → проверь недостающие scopes, сохраняя
+прежние; 410 у external instructions → новый get_instructions; 422 → исправь указанные поля;
+429 → выжди срок из ответа. Timeout/5xx после неидемпотентной записи → неизвестный исход,
+сначала receipt/status/list. Перед продолжением перечитай объект и права.

package/dist/resources/workflows/production-readiness-check.md

@@ -1,9 +1,10 @@
 # Workflow: Production Readiness Check
 
-Финальная проверка перед запуском бота. Workspace overview нужен для выбора площадки, но
-`besales_agent_readiness_get` проверяет конкретного агента. Сейчас API не фиксирует полную
-версию зависимых настроек и возвращает `NOT_PROVEN`, даже если промпт и quality evidence
-актуальны. Не обещай, что повтор sandbox даст `READY`. Часть бизнес-возможностей остаётся опциональной.
+Финальная проверка перед запуском бота. Workspace overview нужен для выбора канала, но
+`besales_agent_readiness_get` проверяет конкретного агента — по каждому каналу, к которому он привязан.
+Сейчас API не фиксирует версии зависимых настроек и возвращает `NOT_PROVEN`, даже если промпт и
+свидетельства качества актуальны. Не обещай, что повтор песочницы даст `READY`. Часть
+бизнес-возможностей остаётся опциональной.
 
 ## Шаг 1 — Снимок
 
@@ -12,24 +13,33 @@
 
 ## Чеклист (по readiness выбранного агента)
 
+Ответ двухуровневый. Верхние `gates` — сводка по каналу песочницы (`sandboxChannelId`); `bindings[]` —
+те же ворота по каждому каналу агента. Верхний `missing` содержит все шаги: пункты агента, затем пункты
+каждой привязки с названием канала.
+
 **Блокирующее (должно быть):**
 
 - `channelActive`, `aiEnabled`, `promptConfigured`, `promptHashInvariant`, `greetingConfigured`.
-- `knowledgeLinked`: все объявленные namespace существуют в workspace.
-- `icp.passed`: ICP обязателен для sales/qualification/reactivation.
-- `sandbox.status=COMPLETED`, `configurationCurrent=true`, `findingsStatus=SUBMITTED`,
-  `qualityRate ≥ policy.minQualityRate`, `checksRate ≥ policy.minChecksRate` и есть expectations.
-  Сейчас `configurationCurrent=null`: `promptAndAgentCurrent` проверяет только промпт и запись
-  агента, а `unverifiedDependencies` перечисляет непроверенные зависимости. Это блокирует общий
-  положительный вердикт, даже при `promptAndAgentCurrent=true`.
+- `knowledgeLinked`: все пространства из настроек поиска агента существуют, и хотя бы одно из них доступно
+  каналу автоматическим поиском.
+- `icp.passed`: ICP обязателен для продаж, квалификации и реактивации
+  (`SALE`, `QUALIFICATION`, `REACTIVATION`); для FAQ/поддержки это не обязательный шаг.
+- `sandbox.status=COMPLETED`, `findingsStatus=SUBMITTED`, `qualityRate ≥ policy.minQualityRate`,
+  `promptAndAgentCurrent=true`. Прогон по кандидату промпта готовность не доказывает.
+  `configurationCurrent=null`: `promptAndAgentCurrent` проверяет только промпт и запись агента, а
+  `unverifiedDependencies` перечисляет непроверенные зависимости. Это блокирует общий положительный
+  вердикт, даже при `promptAndAgentCurrent=true`.
+- Проверки ожиданий сценариев у доказанного прогона: ни одной проверки — шаг «добавьте ожидания»; доля
+  `checksRate` ниже `policy.minChecksRate` — шаг с долей и порогом. Пустой `checksRate` значит «не проверяли», а не
+  ноль процентов. Восемь базовых проверок заводит оператор командой `yarn evals:seed-baseline` на сервере.
 
 **Сильно рекомендуется:**
-- `passRate` — только живучесть. Даже 1.0 не заменяет quality/checks/findings.
-- `crmAuthorization=NOT_EVALUATED` означает, что live-доступ CRM надо проверить отдельно,
+- `passRate` — только живучесть. Даже 1.0 не заменяет quality и findings.
+- `crmAuthorization=NOT_EVALUATED` означает, что живой доступ к CRM надо проверить отдельно,
   когда CRM входит в цель запуска.
 
-`NOT_PROVEN` — нормальный честный исход. Выполни адресные пункты `missing`, затем перечитай
-readiness: сохранённый ответ не заменяет свежую проверку объекта и прав.
+`NOT_PROVEN` — нормальный честный исход. Выполни адресные пункты `missing` обоих уровней, затем
+перечитай readiness: сохранённый ответ не заменяет свежую проверку объекта и прав.
 
 **По бизнес-цели (опционально — НЕ «недоделано» если не нужно):**
 - Triggers / follow-ups: `besales_trigger_upsert` / `besales_followup_sequence_upsert`.