Happy path показывает, что система умеет пройти удачный маршрут. Он почти ничего не говорит о том, что произойдёт при тайм-ауте, повторном запросе или частично созданном артефакте.

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

Если в требованиях есть только успешный сценарий, агент обычно реализует именно его. Код может пройти зелёный тест, а в эксплуатации оставить дубли, потерянные уведомления или зависшие заказы. Это не «редкая крайность», а отсутствие покрытия.

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

Агент полезен для генерации негативных сценариев и проверки, что они действительно связаны с требованием. Но список допустимых последствий и граница автоматического восстановления остаются человеческим решением.

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

Восстановление тоже должно иметь владельца. Автоматически повторить запрос можно, но решить, когда остановиться, компенсировать действие или уведомить человека, — часть требования. Без этой границы система будет считать успешным любой технический ответ.