Рекомендации для профилей и маршрутов
Соберите правила проверки один раз и закрепите их в профиле и маршрутах, чтобы агенты проверяли весь согласованный результат и явно показывали ограничения.
Эту страницу можно передать агенту при настройке профиля. Рекомендации применяются к задачам вашего проекта. Успешный исход этапа сам по себе не доказывает полноту проверки требований.
| Что закрепить | Где настроить |
|---|---|
| Команды проверок и диагностику окружения | В профиле проекта. |
| Правила ревью, аудита и браузерной проверки | В инструкциях этапов. |
| Формат отчёта, исходы и получателя возврата | В инструкциях и переходах маршрута. |
При выборе сценариев учитывайте требования и риски конкретной задачи. Пример новой функции показывает сохранение настроек, пустой выбор, режимы ON/OFF и пересечение параметров.
Правила проверяющих этапов
Для ревью, аудита и браузерного этапа рекомендуются следующие правила. Закрепляйте их в инструкциях и переходах конкретного маршрута: движок не доказывает полноту проверки требований по одному успешному исходу. Время применения правок — в справочнике профиля.
- На любом проходе новый воспроизводимый дефект, нарушающий согласованное требование, может быть блокером. Укажите, какой критерий нарушен.
- На повторе сначала проверьте прежние замечания, исправления и их последствия. Этот порядок не запрещает учитывать новые доказательства нарушения требований.
- «Пропустили на прошлом проходе» не означает «существовало до задачи» и не служит основанием для отсрочки. Предсуществование устанавливают относительно исходной ревизии задачи, а не предыдущего вердикта.
- Не расширяйте задачу, не блокируйте её вкусовыми замечаниями и не открывайте уже закрытую находку без новых доказательств.
- Лимиты времени, попыток и отсутствие прогресса ограничивают продолжение работы. Они не превращают открытые блокеры в успех: при остановке перечислите оставшуюся работу.
Для каждого блокера требуйте сценарий воспроизведения, ожидаемое и фактическое поведение, доказательство и адресат возврата — этап, который может исправить причину.
Если обязательная проверка недоступна, явно перечислите неподтверждённые критерии и причину. Это не доказывает дефект реализации, но не позволяет заявить полную приёмку. Используйте предусмотренный маршрутом возврат или остановку для решения человека: например, failed с владельцем environment или human, либо skipped с остановкой у человека, если так настроен маршрут. Условия исходов и переходы описаны в параметрах узла, а форма отчёта — в руководстве по приёмке.
Проверить готовность окружения
Для конкретной задачи различайте три уровня проверки:
| Уровень | Что проверить | Что подтверждает результат |
|---|---|---|
| Доступность | Контейнер запущен, нужный HTTP-адрес отвечает. | Доступен процесс или вход в приложение. |
| Необходимые процессы и связи | Очереди, воркеры, планировщик и внешние интеграции, от которых зависит задача, выполняют свою работу. | Нужные части системы работают; одного списка запущенных процессов недостаточно. |
| Пользовательский сценарий | Штатный запуск доводит действие пользователя до ожидаемого результата без ручного выполнения каждого промежуточного шага. | Проверена автономная работа всей нужной цепочки. |
Набор зависимостей и способ их проверки принадлежат проекту. Движок вызывает проверку профиля, но не выводит из HTTP-ответа, что все очереди и интеграции исправны.
Ручное продвижение цепочки допустимо для диагностики: можно проверить отдельную стадию или обработчик. Само по себе это не доказывает автономную работу. Если она входит в требования задачи, нужен отдельный сквозной прогон со штатными процессами. В отчёте перечислите ручные вмешательства, результат работы процессов и очередей, а также то, что осталось неподтверждённым. Недоступные обязательные части окружения требуют предусмотренного маршрутом возврата или остановки для решения человека. Форма отчёта — в руководстве по приёмке.
Доказательства для приёмки
done отдельного узла — результат этапа по его контракту. Сам по себе он не доказывает выполнение всей задачи. Перед приёмкой человек должен видеть покрытие требований, непроверенные пункты, открытые дефекты и ограничения доказательств.
Для отчёта полезна компактная таблица «требование → сценарий → результат → доказательство → ограничение». Например, если задача включает фильтр и фоновую обработку:
| Требование | Сценарий | Результат | Доказательство | Ограничение |
|---|---|---|---|---|
| Без фильтра поведение сохранено | Сравнить исходное состояние и OFF | Подтверждено | Сравнение выдачи до и после изменения | Только подготовленные данные |
| Фоновая обработка завершает работу | Штатный запуск до появления результата | Не проверено | Есть только журнал ручного выполнения стадий | Очередь и воркер в штатном режиме не проверены |
В рабочем отчёте дайте ссылки на артефакты конкретного прогона. Отдельно перечислите открытые дефекты и сведения для возврата. Формат отчёта рекомендуется для инструкций маршрута; это не обещание автоматического контроля полноты со стороны движка.
Непроверенный обязательный критерий нельзя представлять как выполненный. Исключение или перенос требует явного решения человека, зафиксированного в задаче и решении приёмки. До этого используйте предусмотренный маршрутом возврат или остановку. После исправлений повторите затронутые проверки и необходимые проверки прежнего поведения.
Применить рекомендации
Настройте команды и проверки окружения в профиле, а инструкции проверяющих этапов, формат отчёта и переходы — в маршруте. Для автоматической проверки доказательств предусмотрен хук профиля profile_route_node_evidence_check; полноту требований и достоверность доказательств всё равно нужно оценивать.
Проверьте профиль штатными командами, затем проверьте и опубликуйте маршрут. Учитывайте время применения изменений: публикация новой версии не меняет маршрут уже начатой попытки.