Как проверять работу Codex и не сломать проект

Коротко: проверяйте не сообщение «готово», а доказательства

Безопасная работа с Codex строится вокруг трёх вопросов: что именно изменилось, какие проверки это подтверждают и как вернуть исходное состояние. Если на любой вопрос нет понятного ответа, работу рано принимать.

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

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

Сначала определите цену ошибки

Глубина проверки должна соответствовать риску. Замена подписи кнопки и изменение формы оплаты требуют совершенно разного контроля.

• Низкий риск: текст, цвет, ссылка, черновик документа. Достаточно diff, сборки и визуальной проверки.
• Средний риск: форма, расчёт, импорт данных, SEO-шаблон. Нужны тесты, граничные случаи и проверка на копии данных.
• Высокий риск: доступы, платежи, удаление, миграция базы, публикация от имени компании. Нужны отдельная среда, резервная копия, план отката и подтверждение человека.

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

До начала: сохраните точку возврата

Самая спокойная проверка начинается до первого изменения. В Git-проекте зафиксируйте текущее состояние или убедитесь, что понимаете, какие изменения уже принадлежат вам. Для эксперимента используйте отдельную ветку или worktree.

• Не смешивайте новую задачу с незавершёнными изменениями другого человека.
• Не просите Codex очищать рабочую папку или откатывать всё без точного списка файлов.
• Для данных сделайте резервную копию или работайте на тестовом наборе.
• Для сайта запишите текущие рабочие URL и основной пользовательский путь.

Опишите готовность до изменений

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

• Какое поведение должно измениться для пользователя.
• Какие файлы или разделы разрешено менять.
• Какие команды должны завершиться успешно.
• Какие обычные, ошибочные и граничные случаи нужно проверить.
• Что обязательно должно остаться без изменений.

Готово, когда: [наблюдаемый результат]. Обязательные проверки: [команды и сценарии]. Не меняй: [границы]. Если выполнить проверку невозможно, явно укажи это и не заменяй её предположением.

Для сложной задачи сначала согласуйте план

План позволяет заметить опасное действие до того, как оно попадёт в файлы. Попросите Codex изучить проект, перечислить затрагиваемые части, допущения, риски и проверки — и только затем переходить к реализации.

• Какие файлы и системы будут затронуты.
• Какие действия обратимы, а какие требуют подтверждения.
• Как будет проверяться каждый этап.
• Какие вопросы заметно меняют результат.

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

Ограничьте доступ папкой проекта

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

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

Проверка №1. Изучите список изменённых файлов и diff

Сначала смотрите не на красивый результат, а на область изменений. В панели review можно открыть изменённые строки, оставить точечные комментарии, принять часть правок или вернуть ненужный фрагмент.

• Нет ли файлов, которые не относятся к задаче.
• Не удалён ли полезный код, контент или настройка.
• Не появились ли ключи, пароли, персональные данные и служебные файлы.
• Сохранены ли существующие названия, URL, структура и технологии.
• Не замаскировано ли большое переписывание под маленькую правку.

Покажи полный список изменённых, новых и удалённых файлов. Для каждого объясни связь с задачей. Затем проверь diff на лишние изменения, секреты, потерю данных и выход за согласованные границы. Ничего не исправляй без отдельного списка замечаний.

Проверка №2. Запустите сборку и автоматические проверки

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

• Запускайте команды, принятые именно в этом проекте.
• Не считайте пропущенную проверку успешной.
• Отделяйте ошибку, созданную изменением, от уже существующей проблемы среды.
• После исправления ошибки повторите проверку целиком.
• Сохраните краткий итог: команда, статус и важный результат.

Проверка №3. Пройдите основной пользовательский сценарий

Успешная сборка не гарантирует, что человеку удобно пользоваться результатом. Откройте страницу, файл или инструмент так, как это сделает обычный пользователь, и пройдите путь от начала до результата.

1. Откройте исходное состояние или чистую сессию.
2. Выполните главный сценарий без специальных обходных действий.
3. Проверьте успешный результат и понятность обратной связи.
4. Повторите сценарий с пустыми, неверными и граничными данными.
5. Убедитесь, что связанное старое поведение осталось рабочим.

Проверка №4. Посмотрите сайт во встроенном браузере

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

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

Открой [URL] во встроенном браузере и пройди сценарий [шаги]. Проверь широкую и мобильную ширину, пустые и ошибочные данные. Не отправляй информацию во внешнюю систему. Зафиксируй доказательства и перечисли проблемы по приоритету.

Проверка №5. Используйте чек-лист для типа результата

У сайта, таблицы и презентации разные риски. Добавьте специализированную проверку вместо одной универсальной фразы.

• SEO-страница: title, description, H1, canonical, robots, sitemap, ссылки и структурированные данные.
• Таблица: число строк, дубли, пропуски, формулы, итоговые суммы и исходный лист.
• Документ: факты, источники, оглавление, номера страниц, стили и отсутствие обрезанного текста.
• Презентация: одна мысль на слайд, читаемость, подписи диаграмм, источники цифр и заметки докладчика.
• Изображение: размер, композиция, точность текста, права на референсы и отсутствие лишних элементов.

Отдельно проверяйте данные и внешние действия

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

• Сначала черновик, затем проверка, затем отдельное подтверждение отправки.
• Сначала план миграции и резервная копия, затем тест на копии данных.
• Сначала список удаляемых объектов, затем подтверждение каждого точного адресата или пути.
• Сначала новое значение настройки и последствия, затем применение.

Проведите независимое ревью без автоматических исправлений

После реализации смените режим с исполнителя на проверяющего. Команда /review может проверить незакоммиченные изменения, отдельный коммит или отличие от базовой ветки и выдать приоритетные замечания, не меняя рабочие файлы.

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

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

Перед публикацией подготовьте план отката

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

1. Зафиксируйте проверенную версию и список входящих изменений.
2. Подтвердите точное окружение, домен или адрес публикации.
3. Опишите способ возврата на предыдущую версию.
4. Опубликуйте только после явного решения.
5. Откройте живой URL и повторите критический сценарий.
6. Проверьте метрики, логи и сообщения об ошибках, если они доступны.

Когда нужно остановиться, а не продолжать исправления

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

• Codex меняет всё больше несвязанных файлов.
• После каждого исправления появляются новые ошибки в другой части проекта.
• Невозможно объяснить, зачем нужен конкретный изменённый файл.
• Критическая проверка недоступна, а результат предлагают принять по предположению.
• Для продолжения внезапно требуется полный доступ, секрет или необратимое действие.
• План отката неясен или исходное состояние уже невозможно восстановить.

Безопасный процесс из десяти шагов

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

1. Ограничьте задачу одним проверяемым результатом.
2. Оцените цену ошибки и критические действия.
3. Сохраните точку возврата или откройте отдельный worktree.
4. Опишите контекст, границы и критерии готовности.
5. Для сложной задачи согласуйте план до изменений.
6. После работы изучите список файлов и полный diff.
7. Запустите сборку и обязательные автоматические проверки.
8. Пройдите пользовательский сценарий и граничные случаи.
9. Проведите независимое ревью без автоматических исправлений.
10. Опубликуйте после подтверждения и проверьте живой результат.