Начните с правила: сайт можно публиковать только после успешных автоматических проверок той версии, которая уйдёт на сервер. Для этого свяжите тесты с процессом публикации, а хуки Claude Code используйте для ранней обратной связи во время работы агента. Ниже разберём, какие проверки нужны небольшому бизнесу, как поставить блокировку при ошибке и что попросить у разработчика. В результате у вас будет понятный порядок приёмки: от проверки заявки до разрешения на выпуск сайта.
Что проверять, когда Claude Code пишет «готово»?
Запишите, какое действие посетитель должен выполнить на сайте. Для компании услуг это заявка, для каталога — поиск товара и переход к контакту. Такой подход совпадает с рекомендацией начинать разработку сайта с бизнес-цели: звонка, заявки, продажи или записи (Saitodrom, «Разработка сайтов в Беларуси»).
Сообщение агента об окончании работы не подтверждает, что этот путь сохранился. Страница открывается, кнопка выглядит правильно, но запрос формы уходит с ошибкой. Поэтому проверяйте действие целиком, включая результат на стороне сайта.
- Основной сценарий: посетитель заполняет форму и получает подтверждение, а тестовая заявка появляется там, где её ожидает сотрудник.
- Обработка ошибок: пустое обязательное поле мешает отправке, а недоступный сервер не вызывает ложное сообщение об успехе.
- Отображение: на узком экране кнопка отправки остаётся доступной, текст и поля не перекрывают друг друга.
- Техническая готовность: проект собирается, нужные страницы открываются, автоматические тесты завершаются успешно.
Для сайта белорусской компании с ценами в BYN отдельно проверьте, что правка не изменила валюту в карточке и итоговой сумме. Это пример проверки содержимого: тест на открытие страницы такую ошибку пропустит.
Первую проверку проведите на тестовой копии с вымышленной заявкой. У неё должен быть понятный признак, чтобы сотрудник не принял её за настоящее обращение. Если копия подключена к рабочим уведомлениям, заранее согласуйте тестовую отправку.
Чем отличаются инструкция, хук и запрет публикации?
Harness — рабочая оболочка вокруг ИИ-агента: она связывает модель с файлами, командами и инструментами. Хук в такой среде запускает заданное действие при определённом событии. Например, после изменения кода можно запускать подходящую проверку и возвращать её результат агенту.
В русскоязычном руководстве по Claude Code описан подход, где отдельный проверяющий оценивает изменения, а хуки не позволяют сделать коммит без успешных тестов на том коде, который попадёт в коммит (GitHub, sfrangulov/claude-code-handbook-ru). Существенна именно привязка результата к конкретным изменениям.
| Способ | Что даёт | Граница защиты |
| Инструкция в CLAUDE.md | Объясняет агенту, какие команды запускать и что считать готовым | Сама по себе не запрещает выпуск сайта |
| Хук Claude Code | Автоматически запускает проверку при выбранном событии | Защищает только те действия, которые проходят через настроенное событие |
| Обязательная проверка перед публикацией | Останавливает выпуск при неуспешном результате | Требует закрыть обходные пути публикации |
У хука после редактирования и у запрета публикации разные задачи. Первый помогает агенту раньше увидеть ошибку. Второй удерживает сломанную версию вне рабочего сайта, даже если локальную проверку пропустили.
Если агент имеет доступ к настройкам проверки и прямой доступ к рабочему серверу, он получает возможность обойти ограничение. Разделите права: агент готовит изменения, а отдельный процесс выпускает проверенную версию. Начать можно с выбора безопасного режима работы с Claude Code для сайта.
Как настроить проверки и остановку выпуска?
Настройку удобно передать разработчику как отдельную задачу с проверяемым результатом. Длительность зависит от состояния проекта: сначала нужно выяснить, есть ли тесты и воспроизводимая сборка. Просите оценить отдельно подготовку проверок и подключение запрета публикации.
- Определите команды проекта. Разработчик фиксирует, как установить зависимости, проверить код, запустить тесты и собрать сайт. Команда npm test подходит только проекту, где в package.json уже настроен соответствующий сценарий.
- Создайте общий сценарий проверки. Он последовательно запускает нужные команды и завершается с ошибкой, если хотя бы одна обязательная проверка провалилась. Отсутствующий тест тоже должен быть заметен, иначе получится пустой отчёт об успехе.
- Подключите хук Claude Code. Выберите событие по документации установленной версии и сначала проверьте его на тестовом проекте. Хук должен запускать общий сценарий и показывать агенту причину сбоя; случайную конфигурацию из чужого проекта переносить не стоит.
- Добавьте тот же сценарий в процесс публикации. Сервис автоматических проверок, который часто называют CI, проверяет выбранную версию кода. Выпуск получает только успешный результат этой версии и использует сборку из неё.
- Проведите контрольный отказ. На отдельной ветке намеренно сломайте тест и попробуйте выпустить сайт. Затем исправьте ошибку и повторите проверку: сначала процесс обязан остановиться, после исправления — разрешить выпуск.
Попросите показать журнал контрольного отказа. В нём должны быть видны версия кода, команда и причина остановки. Слова «хук сработал» недостаточны: проверьте, что публикация действительно не состоялась.
Если после успешных тестов Claude Code снова меняет файл, прежний результат больше не подтверждает готовность новой версии. Проверки запускают заново. По той же причине нельзя проверять одну сборку, а перед отправкой на сервер незаметно собирать другую с иными настройками.
Настройки обязательных проверок и доступ к публикации оставьте под контролем владельца проекта или ответственного разработчика. Если агент способен удалить тест, изменить команду на формальную заглушку и сам одобрить выпуск, техническая блокировка теряет смысл.
Как принять работу без навыков программирования?
Попросите показать два результата: отчёт автоматических проверок и основной путь клиента на тестовой копии. В отчёте должны быть названия проверок и их результаты. В демонстрации — отправка заявки и её получение, а не только красивое сообщение в браузере.
Разберите один отказ вместе с разработчиком. Например, при недоступном обработчике формы сайт должен сообщить о проблеме, а не благодарить за заявку. Так вы проверите конкретное поведение, которое легко оценить без чтения кода.
Не смешивайте успешную сборку с работоспособностью сервера. Ошибка 503 означает, что сервер сейчас не может обработать запрос; среди причин бывают перегрузка и технические работы. Ошибка соединения с базой WordPress относится к другому участку: приложение не получает доступ к базе данных (KalinkinDev, материалы об ошибке 503 и соединении с базой WordPress). Поэтому после публикации нужна отдельная проверка доступности и основного сценария.
Для рабочего сайта согласуйте, кто получает сообщение о сбое и кто вправе вернуть предыдущую версию. Возврат файлов не всегда возвращает прежнее состояние базы, поэтому порядок восстановления нужно проверить до выпуска изменений, которые затрагивают её структуру.
Проверку защищённого соединения тоже стоит выделить в отдельную задачу. Для неё пригодится материал о том, как настроить Claude Code для проверки SSL на сайте малого бизнеса. Такой контроль дополняет тест формы, но не заменяет его.
Если сайт уже работает, в задачу на доработку можно включить тестовую копию, проверки основных сценариев и блокировку выпуска. Результат такой услуги легко принять: разработчик демонстрирует намеренную ошибку, остановку публикации и успешный повтор после исправления.
Типичные ошибки при автоматической проверке сайта
- Ограничиться просьбой «всегда запускай тесты». Исправление: сделать успешный результат обязательным условием публикации вне диалога с агентом.
- Проверять только внешний вид. Исправление: добавить сценарий отправки формы и проверить появление тестовой заявки у получателя.
- Считать любое завершение команды успехом. Исправление: убедиться, что сценарий передаёт ошибку дальше, а процесс выпуска останавливается.
- Разрешить агенту бесконтрольно менять тесты. Исправление: отдельно просматривать изменения проверок и настроек выпуска, особенно удалённые условия.
- Пропустить проверку на рабочем сервере. Исправление: после публикации проверить доступность сайта и согласованный путь клиента, сохранив возможность остановить выпуск или вернуть предыдущую версию.
Начните с действия на две минуты: добавьте в задачу разработчику фразу «Покажите на тестовой ветке, что падающий тест блокирует публикацию именно проверяемой версии сайта».
