Новый адрес раздела открывается, заголовок правильный, тест контроллера проходит. Но старые ссылки из поиска ведут на ошибку, карта сайта содержит прежний путь, а на соседнем сервере осталась старая версия приложения. На каком шаге задача была объявлена законченной?
Разберём учебное изменение: раздел технического блога переезжает на новый URL. Статьи сохраняют свои адреса. Читатель должен попадать в раздел и по старой ссылке, а поисковые метаданные — указывать на новый маршрут. Это задача на согласованность нескольких частей, а не только на замену строки.
Зафиксируйте исходное состояние и границу результата
Сначала отделите разработку от выпуска. В этом упражнении агенту разрешено подготовить изменение в рабочей копии и проверить его. Применение к действующему сайту — отдельное действие, у которого есть своё разрешение, резервирование данных и способ восстановления.
Запишите старый и новый адрес, список сохраняемых URL и ожидаемый переход. Проверьте текущие незавершённые изменения, чтобы не принять чужую правку за часть этой задачи. Исходное состояние должно быть доступно для сравнения; способ его сохранения зависит от рабочего процесса команды.
Нужен также ответ о данных. Если адрес хранится в БД, изменение шаблона не обновит существующую запись. Если её создаёт сидер, повторный запуск может сохранить старое значение. Это проверяют по фактической реализации, а не по названию команды.
Исследуйте связи, которые определяют успех
Агенту можно поручить найти маршрут раздела, генерацию ссылок, canonical, хлебные крошки, карту сайта и способы обновления данных. Отдельно нужны потребители старого адреса: сохранённые ссылки нельзя найти полностью в репозитории, поэтому обратная совместимость задаётся требованием, а не результатом поиска строк.
Выход исследования — небольшая карта затронутых мест и неизвестных условий. Перечень всех моделей приложения здесь лишний. Если оказалось, что соседний сервис формирует ссылки самостоятельно, это зависимость для выпуска, которую нужно явно передать человеку.
Согласуйте решения, которые нельзя получить из кода
Для примера выберем постоянный прямой переход со старого адреса на новый, сохранение URL статей и замену внутренних ссылок. Неизвестные подразделы не должны перенаправляться наугад. Если у старого раздела были дополнительные страницы, их соответствие нужно определить отдельно.
После этого реализация может идти автономно в разрешённой области. Отдельная остановка нужна, если требуется удалить данные, изменить несогласованный публичный адрес или выполнить действие вне рабочей копии. Чтение ещё одного связанного шаблона не является новым продуктовым решением.
Результат задачи:
— новый адрес открывает прежние материалы;
— старый известный адрес ведёт прямо на новый;
— ссылки статей сохраняются;
— внутренние ссылки и метаданные согласованы;
— способ обновления существующей записи проверен отдельно.
Выпуск на действующий сайт не входит в этот запуск.
При новой зависимости опиши её влияние, не скрывай в итоговом «готово».Соберите изменение, которое можно проверить целиком
Сначала убедитесь, что существует рабочий новый маршрут и выбран способ переноса данных. Затем согласуйте ссылки и совместимость старого URL. Порядок можно менять под проект, но нельзя оставлять скрытую зависимость «на production вручную поправим запись» без описания и проверки.
Смысловые части помогают читать diff. При этом фиксированный лимит строк не нужен: карта маршрутов может быть длиннее контроллера и всё равно представлять одно понятное изменение. Размер важен настолько, насколько он мешает увидеть последствия.
Если работа прервалась, сохраните фактическое состояние: что изменено, какая проверка уже выполнена, что ещё не готово. Следующая сессия не должна угадывать, относится ли старый успешный тест к последней версии файлов.
Проверьте разные обещания разными способами
Проверка маршрута подтверждает ответ сервера. Проверка редиректа — код ответа и прямой адрес назначения. Проверка HTML — внутренние ссылки и canonical. Проверка обновления на наполненной тестовой БД — сохранение существующей записи и её связей. Ни одна из них отдельно не заменяет остальные.
После изменения шаблона нужен и визуальный проход: длинное название может сломать мобильную навигацию. Сборка CSS подтверждает техническую корректность сборки, но не читаемость меню. Отчёт должен различать автоматические и ручные проверки.
При замечании вернитесь к конкретной причине. Если canonical остался старым, исправьте источник метаданных и повторите затронутую проверку. Не требуется заново исследовать весь проект после каждой обратимой правки, когда граница изменения известна.
Примите результат и отдельно решите вопрос выпуска
В финальном отчёте полезны изменённое поведение, выполненные проверки, оставшиеся ограничения и инструкция применения. Фраза «все тесты зелёные» не сообщает, обновлена ли рабочая БД и был ли вообще разрешён выпуск.
Человек принимает результат по обещаниям задачи. Если код готов, но production не обновлён, это два разных состояния. После разрешённого выпуска отдельно проверяют реальные URL, содержимое и сохранность данных, а также возможность вернуться к совместимой версии.
Такой цикл не требует пяти документов для каждой опечатки. Для небольшой правки достаточно короткой записи и соответствующей проверки. Чем больше связей, данных и последствий у изменения, тем подробнее должны быть доказательства готовности.
