Агент сообщил «проверки зелёные», но в отчёте есть только форматирование. Код аккуратно оформлен, а доступ к чужой записи по-прежнему открыт. Проблема здесь в соответствии между требованием и проверкой: успешная команда доказывает только то, что она действительно проверяла.
Для рабочего процесса нужен набор условий, после которых изменение можно передавать на приёмку. Разберём, как связать их с командами, отличить локальную помощь от обязательной проверки и не дать исправлению тестов скрыть дефект.
Начните с риска изменения
Пусть задача меняет сохранение статьи через админку. Риск оформления покрывает форматтер. Сохранение полей проверяет функциональный тест. Доступ обычного пользователя требует отдельного отрицательного сценария. Отображение нового поля в узком окне может потребовать браузерного прохода. Ни один из этих пунктов не следует из остальных.
До правки запишите, каким доказательством закрывается каждое существенное условие. Не нужно приписывать всему проекту одинаковый набор: исправление опечатки и изменение прав доступа требуют разной глубины проверки. Но уже обязательные проверки проекта не следует отменять ради экономии нескольких команд.
| Условие задачи | Подходящая проверка |
|---|---|
| Код соответствует принятому оформлению | Форматтер в режиме проверки |
| Редактор сохраняет новое поле | Сценарий сохранения и чтения значения |
| Обычный пользователь не меняет статью | Запрос без нужного разрешения и проверка неизменности данных |
| Поле доступно с клавиатуры | Проход по форме с наблюдением фокуса |
Указывайте команду вместе со средой
В этом проекте PHP-команды выполняются внутри webserver. Для другого репозитория сначала нужно прочитать его инструкции. Пример ниже показывает существующие точки запуска блога; наличие команды не означает, что она была выполнена для вашего изменения.
docker compose --env-file .local/.env -f .local/docker-compose.yml exec -T webserver composer test
docker compose --env-file .local/.env -f .local/docker-compose.yml exec -T webserver vendor/bin/pint --test
npm run buildСкрипт composer test определяется в composer.json проекта: здесь он очищает конфигурационный кеш и запускает artisan test. Это не встроенный универсальный набор Composer. Перед переносом команды в другой проект проверьте его scripts и тестовое подключение к БД.
Pint с --test проверяет оформление без применения исправлений. Обычный запуск Pint может менять файлы. Laravel описывает отдельную тестовую среду; её настройки нужно проверить до сценариев, которые подготавливают или очищают данные. Рабочая база не должна становиться тестовой по случайности.
Локальный хук не равен обязательной проверке
Хук полезен для быстрой обратной связи рядом с изменением. Однако Git допускает обход pre-commit через --no-verify. Кроме того, локальная установка хуков может отсутствовать у другого разработчика или агента. Поэтому обещание «это невозможно пропустить» для такого механизма неверно.
Если проверка должна блокировать принятие изменения, настройте её обязательность на стороне процесса интеграции: запуск в CI, проверка нужной ревизии и правила принятия результата. Конкретные настройки зависят от сервера репозитория. Сам факт появления зелёной задачи в CI ещё не означает, что слияние без неё запрещено.
Локальный и серверный наборы должны ссылаться на понятные команды и конфигурацию. Иначе на машине агента проходит один анализ, а в CI запускается другой. Отдельно проверяйте, что статус относится к последней версии изменения, а не к предыдущему коммиту.
Не превращайте исключения в способ получить зелёный статус
Статический анализ можно вводить постепенно. Baseline PHPStan фиксирует существующие замечания, чтобы отделить их от новых. Но автоматическое добавление нового предупреждения в baseline меняет границу проверки, а не устраняет причину.
Для агентской задачи стоит явно определить, разрешено ли менять baseline, отключать правило, пропускать тест или заменять ожидаемый результат. Это обычные изменения проекта, требующие объяснения. Если запрет должен быть техническим, учитывайте все доступные способы записи, включая оболочку; отсутствие Edit не блокирует Bash.
Иногда тест действительно неверен. Тогда нужно показать, какое требование он искажает, исправить сценарий и проверить поведение по правильному условию. Подмена ожидания фактическим ошибочным ответом без такого обоснования делает набор менее полезным.
Отчёт должен позволять повторить проверку
Проверка: команда, каталог и тестовая среда.
Версия: коммит или описание текущего diff.
Результат: фактический код завершения и существенный вывод.
Покрывает: конкретные условия задачи.
Не выполнено: причина и оставшийся риск.
После последней проверки: перечислить последующие изменения, если они были.Если после успешного прогона менялись затронутые файлы, определите, что нужно повторить. Не объявляйте старый результат доказательством нового кода. При этом бессмысленные повторные полные прогоны без изменений не добавляют уверенности сами по себе.
Останавливайте исправление, когда следующая попытка не опирается на новую проверяемую гипотезу или требует расширить задачу. Человек принимает решение о риске и достаточности доказательств. Набор команд помогает сделать это решение обоснованным, но не может заменить понимание того, что именно должно работать.
