Безопасное редактирование кода и работа с Git

Работа агента должна оставаться обозримой и обратимой. Git даёт журнал изменений, но не снимает обязанность сохранить чужую работу, ограничить diff задачей и проверить, что…

Краткий ответ

Работа агента должна оставаться обозримой и обратимой. Git даёт журнал изменений, но не снимает обязанность сохранить чужую работу, ограничить diff задачей и проверить, что массовое редактирование не затронуло соседние файлы.

Начинайте с состояния рабочей копии

Перед правками Codex должен определить:

текущую ветку и корень репозитория;
изменённые, новые и удалённые файлы;
относится ли существующий diff к задаче;
есть ли вложенные репозитории или worktree;
какие инструкции действуют в целевой директории.

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

Делайте минимальный связный diff

Минимальный diff — не обязательно одна строка. Он включает все изменения, необходимые для целостного результата: реализацию, типы, тест и документацию контракта. Но он не должен одновременно форматировать весь файл, переименовывать соседние сущности и обновлять зависимости без связи с задачей.

Полезная последовательность:

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

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

Не маскируйте проблему механической правкой

Глобальная замена может быть уместна для переименования с надёжным typecheck, но опасна для текста, миграций и похожих идентификаторов. Перед массовой операцией получите список совпадений и разделите:

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

После операции повторите поиск по старому и новому значению. Отсутствие старой строки ещё не доказывает семантическую корректность.

Git как средство проверки

Используйте diff для трёх разных вопросов:

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

Коммит полезен как восстановимая веха, но Codex не должен самовольно публиковать ветку или открывать pull request, если пользователь просил только локальную реализацию. Commit, push и внешняя публикация — разные действия с разными последствиями.

Параллельная работа и worktree

Два агента, редактирующие один набор файлов в одной рабочей директории, создают гонки и трудноразличимые изменения. Для независимых write-heavy задач используйте разные Git worktree или строгие непересекающиеся области.

Безопасное разделение:

Агент A: только backend/src/catalog и его тесты.
Агент B: только frontend/src/modules/catalog и component tests.
Главный агент: контракт, интеграция результатов и общий прогон.

Если обе части зависят от ещё не принятого API, сначала согласуйте контракт, а уже потом распараллеливайте реализацию.

Упражнение: ревизия собственного diff

После небольшой правки попросите Codex ответить по итоговому diff:

какой пользовательский сценарий изменился;
зачем нужен каждый затронутый файл;
какие строки не относятся к задаче;
какие старые изменения он сохранил;
какой тест падает до исправления и проходит после;
что останется непроверенным.

Если агент не может связать файл с критерием готовности, этот файл — кандидат на исключение из патча.

Частые вопросы

Может ли Codex автоматически откатить неудачную попытку?

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

Нужно ли требовать коммит после каждого шага?

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

Почему нельзя одновременно запускать двух агентов на одном файле?

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

Что важно запомнить

Сначала отделите пользовательский diff от изменений текущей задачи.
Минимальный патч включает необходимую целостность, но не случайную уборку.
Просматривайте diff до, во время и после реализации.
Параллельные записи изолируйте по файлам или отдельным worktree.

https://yadro-code.ru/lessons/without-university/codex-agent-workflows/codex-agent-07