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