4 независимых ревью · live-аудит voice.lead-up.ru · 12.08.2026
Не три продукта.
Один AI‑сотрудник и его задачи.
Входящий звонок, исходящий обзвон, первое сообщение и ответ в чате — не отдельные сценарные системы. Это способы запуска и выполнения задач одного сотрудника.
Где была презентация? В текущем ZIP её нет: README Романа прямо говорит, что презентация и текст видео намеренно исключены. Найденная предыдущая презентация Sqoch от 29 июля сохранена, но её модель «роль → сценарии» уже устарела.
Открыть прежнюю презентацию ↗01 · Каноническая модель
Задача — центр исполнения.
Канал — только транспорт.
Навык отвечает «как»
Продать, квалифицировать, записать, проконсультировать. Это способность сотрудника, а не отдельный продукт.
Задача отвечает «что сделать»
Принять обращения, обзвонить базу, написать клиенту, подтвердить запись или обработать новые лиды.
Канал отвечает «где»
Телефон, Telegram, WhatsApp, сайт. Направление и инициатор — свойства задачи, а не отдельные сценарии.
02 · Четыре режима одной сущности
Все различия помещаются в поля задачи.
Принимать входящие
- trigger
- звонок клиента
- channel
- телефония
- mode
- постоянная
Обзвонить базу
- trigger
- запуск / расписание
- channel
- телефония
- mode
- массовая
Написать первым
- trigger
- событие / оператор
- channel
- мессенджер
- mode
- одна / массовая
Отвечать в чате
- trigger
- сообщение клиента
- channel
- чат / мессенджер
- mode
- постоянная
Один навык «Продавать» может работать во всех четырёх задачах. Один клиент сохраняет общую историю между звонком и перепиской.
03 · Что сделал Роман
Сохраняем инженерное ядро.
Не принимаем его продуктовую оболочку.
Берём в Sqoch
- 19 Tool Contracts — типизация разрешённых действий.
- Project Context — факты и правила проекта.
- Confirmation + authorization — защита рискованных записей.
- Effect lifecycle — committed, uncertain, reconciliation.
- Evidence — результат подтверждается фактом операции.
- Soul MD — сырьё для личности и стиля сотрудника.
Не принимаем как есть
- Нет Task как основной продуктовой и backend-сущности.
- Три scenario family искусственно становятся центром мира.
- outbound_task существует лишь как строка источника запуска.
- Нет frontend, API и runtime — архив является спецификацией.
- Нет реальных connectors к SIP, RetailCRM и мессенджерам.
- Нет UX создания сотрудника, задачи, теста и публикации.
121 файл299 тестов проходят с vendored tzdb3 scenario family0 production runtime
04 · Как адаптировать
Не переписывать всё. Переподключить к правильным владельцам.
У РоманаВ SqochРешение
scenario familyнавык / behavior templateперенести правила, убрать корневую сущность
launch sourcetrigger задачидобавить Task и тип запуска
tool contractAction + Connector + Grantсохранить schema, дописать адаптер
project contextKnowledge + Project Policyразделить факты, правила и снимки
Soul MDEmployee Identityструктурировать стиль и disclosure
effect / evidenceTaskExecution resultсохранить и привязать к TaskItem
05 · Что делать с voice.lead-up.ru
Разобрать техническое меню
по продуктовым сущностям Sqoch.
Один тестовый контур с выбором инициатора, канала и тестовых данных.
«Принимать входящие» — постоянная задача. SIP — настройка канала. Живые контакты — исполнения.
Аудитория, окно, темп, повторы, стоп-лист и итоги находятся в одной карточке задачи.
RetailCRM остаётся источником данных, а не названием пользовательского раздела.
Один черновик, diff, тест, публикация и откат. Технический граф — в advanced/debug.
Одна история звонков и сообщений с фильтрами по задаче, каналу, среде и результату.
06 · Финальное решение
Роману — не продолжать наращивать граф.
Его следующий результат должен быть не очередным JSON-пакетом, а одним вертикальным рабочим путём в модели Sqoch.
- 01Создать AI‑сотрудника
Личность, знания, права и навык «Продавать».
- 02Создать TaskContract
Постоянная, одиночная и массовая задача; trigger, channel, schedule, retry, compliance.
- 03Запустить четыре режима
Входящий звонок, исходящий звонок, первое сообщение и ответ клиенту.
- 04Подключить реальную операцию
SIP + RetailCRM: прочитать клиента и создать проверяемый результат.
- 05Показать это во frontend
Сотрудник → задачи → исполнения → диалоги → итог. Затем тесты, публикация и откат.
РешениеHandoff принять как технический донор. Архитектуру и готовность — не принимать.
Материалы