Изолированный «под-агент» с собственным системным промптом. Отвечает за одно намерение: запись, перенос, цены, медицинский вопрос, общая справка, перевод на оператора. У каждой ветки — свой код, активная версия настроек, опционально — пошаговый сценарий и защитные условия.

В коде и в БД ветка хранится в таблице intents — исторически. Концептуально это branch, но из-за связи 1:1 с намерением мы пока не разделяли их в коде.

Защита от ложных переключений внутри пошагового сценария. Это не второй вызов маршрутизатора — один вызов, но с расширенным промптом. Работает пошагово:

1. Пациент пишет что-то вроде «а сколько стоит приём?» внутри записи.
2. Маршрутизатор анализирует реплику и возвращает: general_info (в Песочнице — бейдж «Решение маршрутизатора: general_info»).
3. Система видит: тред уже идёт по пошаговой ветке new_booking, шаг qualify. Переключать опасно — потеряем контекст записи.
4. Вместо переключения: effective_code остаётся new_booking, в системный промпт ветки добавляется блок:

   [ПОДСКАЗКА РОУТЕРА]
   Маршрутизатор счёл, что тема — `general_info`.
   Ты ведёшь сценарий `new_booking`.
   Если пациент сменил тему — выдай [INTENT_CHANGE: general_info].
   Если реплика в сценарии — зафиксируй в слот и продолжай.

5. Модель new_booking получает весь этот контекст и сама решает:
   • Ответить на вопрос и остаться → вернёт {"state_after": "qualify", "soft_insertion": true} → бейдж «удержались в ветке» + «боковой вопрос».
   • Решить, что тема реально сменилась → вернёт [INTENT_CHANGE: general_info] → переключение ветки.

Ключевое: решение принимает модель ветки за один вызов, а не отдельный маршрутизатор. Подсказка маршрутизатора — просто контекст в промпте.

Ситуация, когда модель пошаговой ветки отвечает на вопрос вне сценария, не продвигая шаг и не меняя ветку. Типичные примеры внутри new_booking: «а сколько стоит приём?», «у вас есть парковка?», «как долго идёт приём?».

Откуда система знает, что это боковой вопрос? Модель сама сообщает об этом в структурированном ответе:

STATE_JSON: {"state_after": "qualify", "slots_updated": {}, "soft_insertion": true}

Счётчик soft_insertion_count в состоянии диалога инкрементируется на каждом таком ответе и сбрасывается при смене шага или ветки. При трёх подряд — в системный промпт ветки добавляется жёсткое указание: «верни пациента к вопросу текущего шага».

В Песочнице: бейдж «тип ответа: боковой вопрос» (жёлтый) на ответе ассистента.

STATE_JSON: {"state_after": "qualify", "slots_updated": {"name": "Алексей"}}

Правило, которое блокирует переход шага вперёд, пока не заполнены нужные слоты. Хранится в поле guards каждого шага (Настройки → Шаги → поле «Защитные условия»). Проверяется после того, как модель вернула корректный state_after — то есть даже если модель «захотела» перейти, валидатор не пустит без нужных данных.

Формат — JSON-объект, где каждый ключ — имя защитного условия:

{
  "require_legal_rep": {
    "description": "Для записи ребёнка нужны ФИО и телефон законного представителя",
    "trigger_slot": "is_child",
    "trigger_value": true,
    "required_slots": ["legal_rep_name", "legal_rep_phone"]
  }
}

Поля:

• trigger_slot — слот, при значении которого защитное условие активируется. Если опущен — условие активно всегда.
• trigger_value — значение, которое должен иметь trigger_slot для активации (например, true).
• required_slots — список слотов, которые должны быть заполнены для разрешения перехода.
• description — пояснение для операторов; показывается в «Состоянии диалога» в Песочнице при срабатывании.

Сейчас защитное условие задано на шаге qualify ветки new_booking: при is_child: true нельзя перейти в present, пока не заполнены legal_rep_name и legal_rep_phone. В Песочнице при срабатывании появляется красный блок: «🔒 защитное условие require_legal_rep не пройдено — ждём: legal_rep_name, legal_rep_phone».

Когда диалог уходит в ветку escalate_human, фиксируется причина — для статистики и для оператора, который примет диалог. Возможные значения:

• acute_pain — пациент описывает острое состояние.
• surgery — упоминание операции, наркоза, стационара.
• angry — агрессивный или раздражённый тон.
• explicit_request — пациент явно просит оператора («дайте человека»).
• routing_loop — сработала защита от петли (3+ переключений ветки).

В Песочнице видно в карточке ответа: «Передача оператору · причина: <reason>». Само значение модель возвращает в служебном сигнале [INTENT_CHANGE: escalate_human|reason] либо его подставляет код (например, routing_loop при срабатывании защиты).