ВАШ КОНВЕЙЕР / НАСТРОЙКА

Настроить конвейер под проект

Настройки полезно разделять по смыслу: процесс работы, окружение проекта и выбор исполнителей. Тогда изменение модели не требует пересобирать весь маршрут.

Где что менять

Что требуется	Где настраивается
Добавить этап, изменить инструкцию или переход	Черновик маршрута в редакторе.
Объявить команду тестов, пути или устройство стенда	Профиль проекта.
Выбрать исполнителя, модель, усилие и резерв	Политика запуска проекта.
Связать ведущего и исполнителя в цикл	Поле loop в определении маршрута и переходы пары.
Ограничить число кругов цикла	PROFILE_LOOP_MAX_ROUNDS в профиле проекта.
Уточнить результат конкретной задачи	Постановка и критерии приёмки этой задачи.
Вернуть текущую работу с замечанием	Управление конкретной попыткой.

Файлы окружения, хуки, модельные ключи и время применения изменений разобраны в справочнике профиля проекта. Поля узла — в его разделе о маршрутах.

Типы этапов

Агент (agent) читает назначенную инструкцию и получает предусмотренный контекст. Используйте его для изучения, планирования, реализации или анализа результата.

Команда (command) вызывает разрешённую команду профиля. Подходит для машинных проверок: синтаксис, тесты, сборка. Доступность команды объявляется профилем.

Ворота (gate) ждут решения человека. Используйте их там, где нужно согласовать план, подтвердить причину дефекта или принять результат.

Статус (status) показывает результат своего владельца и не исполняется отдельно.

Инструкция и контекст

Хорошая инструкция ограничена задачей этапа. В ней понятно, что получить и как понять, что этого результата достаточно.

Например, проверяющему этапу нужны критерии приёмки и изменения. Автору плана — постановка, сведения о проекте и результат изучения. Передавать всё подряд обычно менее полезно, чем явно указать необходимые входы.

Редактор позволяет собрать инструкцию из блоков Markdown, задать условия их включения и требуемый контекст. Просматривайте итоговый текст через «Показать инструкцию».

Правила проверяющих этапов

Правила повторного ревью, новых блокеров и недоступных проверок собраны в рекомендациях для профилей и маршрутов. Закрепите их в инструкциях проверяющих этапов и переходах маршрута.

Переходы и возвраты

Для каждого исхода определите дальнейшее действие: переход, возврат, остановку или другой поддерживаемый маршрут. Объясняйте смысл ветки, а не только её техническое имя.

Пример: если ревью нашло ошибку, верните реализацию автору с замечанием. Если план не отвечает постановке, верните планирование. Если недоступно окружение, сначала требуется восстановить его.

Замечанию нужен получатель

Текст отклонения отправляется агенту этапа, на который ведёт возврат. Командный этап не может прочитать инструкцию на доработку.

Когда нужен повтор

Повтор того же этапа уместен, если повторное выполнение может изменить результат: например, после временного сбоя. Возврат нужен, когда требуется исправить вход или работу предыдущего этапа.

Если неудачный исход уже возвращает работу назад, не добавляйте к нему повтор продуктовой ошибки на прежнем входе. Комбинацию retry.productFailure > 0 с возвратом по failed валидатор отклоняет.

Ограничивайте повторы. Исчерпанный бюджет должен приводить к понятной остановке, которую можно разобрать.

Петля ведущего и исполнителя

Для режима «цикл» маршрут объявляет пару в поле loop. Ведущий ставит задания, проверяет результат и решает, продолжать ли текущий этап или начинать следующий. Доработка идёт через передачи внутри пары; у обоих узлов retry.productFailure равен 0.

Потолок кругов задаётся отдельно в профиле. Он не заменяет проверки прогресса и не сбрасывается на новом этапе. Полный контракт и учебный пример — в руководстве по режиму петли.

Исполнители и модели

Исполняемый этап имеет ключ runKey. По нему политика запуска выбирает исполнителя и настройки модели. В маршрут не включаются provider, model и effort.

Для управления политикой используйте CLI проекта, чтобы сохранить проверку версии настроек. В примерах замените <name> именем своего профиля:

engine/bin/factory profile <name> runner show
engine/bin/factory profile <name> runner set claude --failover codex
engine/bin/factory profile <name> runner set REVIEW codex --failover claude

Первый set задаёт основной и резервный исполнители проекта, второй — правило для этапа с ключом REVIEW. Выбирайте только установленных и авторизованных исполнителей.

Точные модели берутся из каталога выбранного инструмента. Не переносите произвольное имя модели из чужого примера. После изменения политики выполните проверку хоста:

RUN_HOST_PREFLIGHT=1 engine/bin/factory-check <name> --host-preflight

Приоритет правил: конкретный этап задачи → задача → этап профиля → настройки проекта. Наследование, резерв и поля FAMILY, VERSION, EFFORT, EXACT разобраны в справочнике исполнителей и моделей.

Начальная разведка

Scout задаётся отдельно от маршрутов каталога. Для маршрута можно требовать эту разведку или пропустить её, если подготовленный процесс этого не требует. Допустимость выбора проверяется вместе со всем каталогом.

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

Импорт, публикация и откат

Импорт создаёт новый черновик и заново проверяет привязки к профилю. Внешние команды, пути репозиториев и настройки моделей в него автоматически не переезжают.

После изменения проверяйте черновик и сравнивайте его с опубликованной версией. Откат меняет версию для новых попыток. Уже идущие задачи продолжают читать свои закреплённые маршруты, а рабочие черновики сохраняются.