# Waytiqo Agent Playbook

Используй этот файл как постоянный контекст для агента, который собирает импортный JSON по `waytiqo_schema.json`.

## Что извлекать

- `requirements`: глобальные обязательства, ограничения, критерии успеха, правила, compliance, SLA, KPI, дедлайны и другие условия, которые важны не для одного шага, а для всей инициативы.
- `factors`: внешние влияния на успех или провал: бюджет, команда, компетенции, рынок, конкуренты, сезонность, риски, зависимости, поддержка партнера, технический долг.
- `goals`: конечные результаты, которых хотят достичь. Если явных целей нет, сформулируй 1-2 цели из главного намерения текста.
- `steps`: действия, этапы, инициативы, решения, подзадачи и варианты развития сценария. Собирай дерево: родительский шаг должен объединять дочерние.
- `conditions`: не критерии завершения, а внешние условия, сигналы, допущения и ограничения, которые влияют на возможность выполнения шага или на применимость сценарного варианта.

## Как отличать сущности

- Если формулировка звучит как "нужно / обязаны / требуется / нельзя без", это обычно `requirements`.
- Если формулировка звучит как "мешает / помогает / зависит от / влияет / риск / ресурс", это обычно `factors`.
- Если формулировка звучит как "достичь / запустить / внедрить / обеспечить / выбрать", это обычно `goals`.
- Если формулировка звучит как "сделать / подготовить / проверить / согласовать / настроить", это обычно `steps`.
- Если формулировка звучит как "возможно, только если...", "при условии...", "если доступно...", "если согласуют...", "если рынок позволит...", это `conditions`.

## Как кодировать ветвления

- В схеме нет отдельного поля `branch`, поэтому ветвления кодируй через вложенные альтернативные `steps`.
- Создавай общий родительский шаг, если текст описывает выбор, сравнение или развилку. Примеры названий: `Выбрать вариант запуска`, `Сравнить сценарии`, `Определить путь внедрения`.
- Каждый дочерний шаг такого узла - отдельный вариант сценария, альтернатива или сравниваемая опция.
- Условия, которые "включают" или "выключают" вариант, записывай в `conditions` именно на шаге варианта.
- Если в тексте явно есть победивший вариант, его условие может быть `true`, а для отвергнутых или недоступных вариантов чаще подходит `false`.
- Если вариант возможен, но пока не подтвержден, используй `maybe`.

## Правила построения JSON

- Возвращай только JSON, без комментариев и без markdown.
- Соблюдай схему буквально: никаких дополнительных полей.
- Все id для `requirements` и `factors` делай детерминированными: lowercase, латиница, цифры, дефисы. Хороший формат: `req-...` и `fac-...`.
- Не дублируй сущности с одинаковым смыслом. Если в тексте одно и то же требование встречается в разных местах, создай один глобальный элемент и ссылайся на него.
- Не создавай `conditions`, `factors`, `requirements` или `steps`, если для них нет уверенного основания в тексте.
- Если у шага нет дочерних шагов, поле `steps` можно не указывать.
- Если фактор упоминается без явной силы влияния, не придумывай число `impact`.
- Не используй `conditions` для формулировок вроде "сделать отчет" или "подготовить документ" - это шаги, а не условия.
- Если текст описывает критерий приемки, а не внешнее ограничение сценария, лучше оставить это в шаге или требовании, а не превращать в `conditions`.

## Как ставить статусы

- `true`: внешнее условие выполняется, допуск есть, зависимость доступна, вариант реалистично активен.
- `false`: условие не выполняется, зависимости нет, ограничение блокирует шаг или вариант.
- `maybe`: условие не подтверждено, обсуждается, зависит от проверки или может измениться.
- Если у требования есть связь со шагом, но нет явного статуса выполнения на шаге, используй `maybe`.

## Что делать с разными типами входа

- Транскрибация встречи: выделяй договоренности, решения, открытые вопросы, зависимости, следующие шаги и альтернативные варианты, если обсуждался выбор.
- Упрощенное ТЗ: выделяй цели, обязательные требования, этапы реализации и ограничения, от которых зависит сценарий.
- Список задач: группируй задачи в 1-3 цели и строй дерево шагов по смыслу; отдельные ветки делай только если действительно есть альтернативы.
- Статья или сравнение вариантов: извлекай цель выбора/внедрения, ключевые критерии как `requirements`, драйверы и риски как `factors`, а сравниваемые варианты представляй как дочерние шаги общего шага выбора.

## Качество результата

Перед ответом проверь:

1. JSON валиден по схеме.
2. У каждого `requirement_id` есть соответствующий элемент в `requirements`.
3. Каждый id фактора в шагах существует в глобальном `factors`.
4. Нет пустых заголовков.
5. Нет сущностей, которых не было в исходном тексте хотя бы косвенно.
6. `conditions` описывают именно внешние условия применимости или блокировки, а не результат выполнения шага.
7. Если в тексте были альтернативы, они оформлены как соседние варианты под общим родительским шагом.