Агент изменил файл, а приложение старое: проверьте checkout

Начните с процесса, который действительно читает файлы

До редактирования попросите агента назвать физическую рабочую директорию. В командной оболочке pwd -P показывает физический путь вместо удобного логического пути через символическую ссылку. Сохраните этот результат локально. Затем выясните, какая команда создаст проверяемую сборку и какую директорию использует именно она. Открытый в правильной папке терминал ещё не доказывает, что package script, схема IDE, подключённый каталог контейнера или фоновый сервер читают те же исходники. Проследите путь до фактического производителя результата, а не до красивого названия вкладки редактора.

Со стороны разработчика отдельно проверьте рабочую область редактора и запущенный сервер. Редактор может показывать одну копию, пока терминал помнит другую. Сервер способен продолжать отдавать предыдущую сборку после закрытия терминала, из которого его запустили. Если операционная система или инструменты разработки позволяют посмотреть рабочую директорию процесса, сравните её с ответом агента. Не публикуйте полный environment процесса: там могут находиться ключи и токены. Для проверки идентичности обычно достаточно связи между исполняемым файлом, процессом и исходным каталогом.

Если путь сборки неизвестен, зафиксируйте именно неизвестность. Это недостающий факт, а не подтверждённая ошибка кэша. Приостановите новые правки настолько, чтобы связать видимое приложение с корнем исходников. В нашем примере сразу обнаруживается, что агент работал в delivery-worktree, а разработчик собирал стабильную копию. Уже сделанное исправление может быть правильным. Повторение той же правки во втором каталоге добавит ещё один патч для последующего согласования, но не объяснит, почему первая сборка не содержала ожидаемого изменения.

Запишите ревизию и состояние рабочей копии

Внутри Git-команды git rev-parse --show-toplevel и git rev-parse HEAD определяют корень репозитория и текущий commit. Имя ветки добавляет контекст, но не заменяет SHA: указатель ветки перемещается, а отдельный worktree вообще может находиться в detached-состоянии. Две рабочие копии способны иметь одинаковый commit и разные незакоммиченные изменения. Поэтому запись идентичности должна одновременно описывать ревизию и важное локальное состояние. Сохраняйте эти сведения вместе, когда передаёте ту же Task другому провайдеру или просите нового агента продолжить работу.

Посмотрите git status --short --branch и изучите относящийся к задаче diff, прежде чем считать каждое изменение частью текущего запроса. Справочник Git status объясняет состояния индекса, рабочей директории и неотслеживаемых файлов, которые отражает вывод. Пустой diff отслеживаемых файлов не доказывает, что локальная конфигурация или игнорируемый вход сборки не влияет на результат. Не нужно отправлять все такие файлы агенту. Нужно понять, какие из них реально читает сборка, и проверить эту связь, сохраняя приватные настройки внутри разрешённого окружения.

Для передачи достаточно фактической записи: корень исходников, commit, ветка либо detached-состояние, изменённые пути и последняя выполненная проверка. Отдельно укажите, закоммичены ли правки. Не приписывайте commit работу, которая пока существует только на диске. Когда агент пишет «сохранено», уточняйте смысл результата: буфер редактора, файл, commit, удалённая ветка и развёрнутый артефакт имеют разную долговечность. Каждое состояние полезно, но отвечает на собственный вопрос о восстановлении. Такая точность особенно важна перед переходом на другой компьютер, где локального незакоммиченного файла может вообще не оказаться.

Считайте worktree самостоятельной рабочей папкой

Связанный Git-worktree предоставляет тому же репозиторию ещё одну рабочую директорию. Это удобно для изоляции исправлений и подготовки релизов, но редактируемое дерево файлов у каталогов раздельное. Документация Git worktree описывает эту связь между общим репозиторием и отдельными состояниями рабочих копий. Команда git worktree list --porcelain помогает получить список путей и ревизий. Просмотрите его до того, как объявить похожую папку старым ненужным дублем. Имя каталога само по себе ничего не говорит о ценности незакоммиченных файлов внутри него.

В нашем примере стабильная папка чистая и находится на main, worktree доставки содержит небольшой патч, а экспериментальная копия хранит другие изменения. Текущей задаче принадлежит только патч доставки. Не исправляйте расхождение удалением экспериментальной папки или слепым слиянием всех веток. Сначала выясните, не работает ли там другой агент или человек. Каталог может не создавать CPU-нагрузку в момент проверки и всё равно содержать важный незавершённый результат. Содержимое, владелец и назначение важнее даты, которую вы предполагаете по имени папки.

Если несколько агентов работают параллельно, каждому execution нужен явный корень исходников. В общем описании Task отделите этот корень от места будущей интеграции. Если один агент проверяет, а второй редактирует, обозначьте, какую папку разрешено менять каждому. Это предотвращает неприятную гонку: reviewer начинает тестировать diff, другой процесс меняет файлы под ним, а итоговый отчёт ссылается на ревизию, которая уже не соответствует реально проверенным исходникам. Даже хорошие тесты дают слабое доказательство, когда неизвестно, какой именно набор файлов находился под ними во время запуска.

Оставьте полноценный путь для папок без Git

Полезная Task не обязана начинаться в репозитории. Пользователь может попросить разобрать заметки, исправить экспортированный проект, проверить набор изображений или создать первые файлы до настройки контроля версий. Выбор репозитория не должен превращать его отсутствие в вымышленную сущность. Определите настоящую папку, её назначение и честно укажите, что Git-ревизии нет. Идентичность нужных файлов всё равно можно проверить. Отсутствие commit меняет доступные доказательства, но не отменяет задачу и не оправдывает интерфейс, который заставляет выбирать посторонний репозиторий для продолжения.

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

Task в GrantTap остаётся стабильной пользовательской единицей работы, даже когда разные execution используют разные типы папок. Интерфейс должен честно показывать отсутствие репозиторных метаданных и позволять выбрать правильную рабочую область. Не предлагайте инициализировать Git только ради удовлетворения селектора, если пользователь не просил контроль версий. Создание репозитория — самостоятельное решение о процессе работы. Оно не заменяет нормальную поддержку папки без Git и не должно незаметно менять исходный запрос пользователя. Особенно это важно при переносе Task на компьютер с другой организацией каталогов.

Проследите входы сборки до готового артефакта

После подтверждения корня посмотрите, что именно читает сборочная команда. Сайт может использовать сгенерированный каталог контента вместо исходного Markdown. Нативное приложение может собирать другую схему или target. Пакет способен разрешить локальную workspace-зависимость в соседнюю папку. Образ контейнера может копировать файлы из build context, который отличается от текущего каталога оболочки. Запишите конкретную важную связь для своего случая. Не предполагайте, что любой файл внутри репозитория автоматически участвует в каждом результате, который разработчик запускает из этого репозитория.

В примере с доставкой изменённый Swift-файл действительно относится к приложению, но первая сборка использовала проект из другой рабочей копии. Указание правильного проекта устраняет видимое противоречие. В случае сайта редактирование статьи без запуска генерации контента оставляет корректный, но устаревший выходной каталог. Исправление состоит в обновлении нужного выходного состояния и повторной сборке. Массовая очистка package-кэшей займёт больше времени и скроет реальную причину: пропущенный шаг, который связывает исходный текст с теми файлами, которые сервер действительно умеет отдавать посетителю.

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

Разделяйте редактирование, доставку и развёртывание

Между изменением файла и результатом на телефоне есть несколько самостоятельных этапов. Commit фиксирует историю исходников. Push делает commit доступным в удалённом репозитории. Сборка создаёт артефакт. Загрузка или развёртывание предоставляет его через конкретный канал. Установка либо открытие выбирает ту версию, которую реально наблюдает пользователь. Успех одного этапа не означает автоматический успех следующего. Сообщайте подтверждённый этап, особенно когда телефон по-прежнему использует старую TestFlight-сборку. Именно здесь фраза «всё исправлено» чаще всего расходится с честным, но ограниченным доказательством coding-агента.

Для сайта проверьте, какой неизменяемый образ или каталог релиза использует обслуживающий процесс. В main уже может находиться свежий код, пока сервер отдаёт вчерашний образ. Возможна и обратная ситуация: экстренное развёртывание работает, но его происхождение ещё не согласовано с main. Посмотрите обе идентичности и запишите связь. Не печатайте значения deployment-environment. Обычно достаточно исходной ревизии, идентичности образа, проверки маршрутов и видимого поведения страницы. Этот набор позволяет объяснить результат без публикации секретной конфигурации или вмешательства в соседние сервисы того же сервера.

То же относится к интеграции агента. Обновление исходников MCP-пакета в репозитории не меняет уже запущенный процесс компьютера. Установленная версия, время старта процесса и активный runtime могут отличаться от самого нового кода на GitHub. Проверьте эти факты прежде, чем называть слияние исходников доставленным исправлением. Devices и наблюдения доставки в GrantTap помогают организовать такую проверку, но зелёное подключение не доказывает, что каждый локальный компонент работает на последней доступной версии. Оно сообщает о конкретном состоянии соединения, а не заменяет учёт версий всех процессов.

После transfer проверяйте папку назначения

Transfer сохраняет назначение Task и видимую историю в пределах реализованного контракта переноса. Он не гарантирует, что другой компьютер получил те же незакоммиченные файлы, зависимости, разрешения и установленные инструменты. До продолжения редактирования попросите destination-execution назвать папку и важную ревизию, которые он действительно видит. Сравните их с исходной записью. Если требуется передать патч или обновить репозиторий, выполните это отдельным понятным шагом и проверьте получившиеся файлы. Не считайте общий разговор доказательством того, что локальное файловое состояние автоматически синхронизировалось вместе с ним.

Хороший вопрос приёмки можно проверить на стороне назначения: какой корень открыт, какой commit выбран, какие нужные файлы отличаются и какая небольшая проверка чтения подтверждает наличие исправления? Ответ «я понял передачу» слабее такого набора фактов. Не добавляйте секреты в handoff-summary и не просите destination обходить правила подтверждения ради удобного теста. Успешное продолжение включает и правильный код, и правильную политику действий. Если источник требовал отдельного разрешения на публикацию, смена провайдера не должна превращать это требование в молчаливое согласие.

Для нашей Task destination-Claude может открыть delivery-worktree, найти helper повторной передачи и запустить связанный тест. Если он открывает стабильную папку и не видит helper, следующий шаг — исправление выбора рабочей области. Просьба заново реализовать функцию создаст дублирующую работу. Сохраните ту же Task и восстановите связь execution с нужными исходниками. Пользователю не должно требоваться повторно объяснять весь запрос только потому, что изменился провайдер. Но и агенту нельзя делать вид, что непрерывность Task автоматически устранила реальные различия между компьютерами, каталогами и локальными сборками.

Интегрируйте изменения с учётом их назначения

Когда работа готова для main, составьте список веток и HEAD рабочих копий, затем изучите отличия от текущей базы интеграции. Поведение старой ветки может быть уже заменено более новой реализацией, даже если её commit ещё не входит в ancestry main. Решение требует проверки и истории, и текущего поведения. При конфликтах сохраняйте поздние исправления и объясняйте, почему старый вариант уступил место новому. Отсутствие конфликтов приятно, но не доказывает, что два независимых корректных изменения правильно взаимодействуют после совместной сборки и выполнения.

Перед интеграцией сохраните относящиеся к задаче незакоммиченные изменения по правилам авторства репозитория. Не добавляйте в общий commit приватные генерируемые кэши, ключи, посторонние эксперименты и чужие незавершённые файлы. Если рабочая папка принадлежит активному execution, сначала согласуйте доступ. Для объединения удобна отдельная копия, исходники которой остаются неизменными на время release-проверок. Это особенно полезно при длинном прогоне нативных UI-тестов: результат не должен относиться к случайной движущейся смеси исправлений. Стабильная база экономит время на повторных проверках и делает ошибки воспроизводимыми.

После объединения проверьте, что каждый предназначенный HEAD представлен в итоговой истории и важные незакоммиченные изменения не остались забытыми. Затем выполните совместные поведенческие проверки. После обновления удалённого main локальные main-копии всё ещё могут быть старыми и потребовать чистого fast-forward. Не удаляйте все worktree вместо доказательства завершения. Сохранённая папка с понятной связью с main не мешает разобраться в работе. Удалённая папка, уникальные изменения которой никто не проверил, создаёт риск потери результата и не делает процесс интеграции автоматически более аккуратным или понятным.

Проверяйте результат короткой последовательностью

Начните с проверки чтения, которая определяет ожидаемый файл и идентичность исходников. Следом запустите узкий поведенческий тест, который не проходил бы без исправления. Затем соберите приложение и пройдите затронутый пользовательский сценарий в нужной среде. Если запрос включает развёртывание, отдельно проверьте доставленный артефакт. Такой порядок уменьшает бесполезную работу: неизвестный корень нужно выяснить до дорогой полной сборки, а провал целевого теста исправить до production-развёртывания. Быстрые ранние проверки не заменяют остальные этапы, но не дают тратить их время на заведомо неправильные исходники.

Для интерфейсного исправления выбирайте наблюдаемое утверждение: появилась подпись, после подтверждения исчезла ожидающая строка, повторная передача сохранила исходный ID сообщения. Проверка наличия имени helper в тексте исходника слабее реального поведения. Для релиза запишите точный артефакт и среду, в которой сценарий прошёл. Если Simulator успешно проверен, но требуется физическое устройство, укажите оставшийся этап. Похожие скриншоты разных сборок не являются взаимозаменяемыми доказательствами. Даже один репозиторий способен породить разные продукты из-за схемы, входных данных и времени создания конкретного артефакта.

Итоговый отчёт можно оставить коротким: что изменилось, какая ревизия интегрирована, какие проверки выполнены, какой артефакт наблюдался и какое существенное ограничение осталось. Тогда разработчик отличит правильный патч, ожидающий распространения, от уже развёрнутого изменения, которое не прошло приёмку. Следующий агент тоже получит хороший старт. Вместо неопределённого указания «опять исправь старый экран» он увидит конкретное отсутствующее звено: установленный пакет прежней версии, release-процесс со старым образом или приложение, собранное из другой рабочей копии. Это позволяет продолжать работу без повторного создания уже готовых изменений.

Учитывайте локальную конфигурацию без раскрытия секретов

Одинаковые исходники могут давать разное поведение из-за входных настроек. Это не причина сразу копировать весь environment между компьютерами. Сначала определите имена параметров, которые действительно читает конкретный процесс, и наличие нужного разрешённого источника конфигурации. В отчёте достаточно указать, что обязательная настройка присутствует либо отсутствует, не выводя её значение. Если проблема связана с адресом тестового API, сравните назначение окружения и допустимый endpoint. Не подменяйте production-настройку ради удобного зелёного теста: такой результат ничего не скажет о версии, которую пользователь продолжает запускать в настоящем окружении.

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

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

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

Не превращайте расследование в отдельную систему управления проектами. Обычно хватает пяти строк рядом с Task: рабочая директория, ревизия и локальное состояние, нужное изменение, команда проверки, состояние артефакта или развёртывания. Обновляйте запись при изменении этих фактов. Подробные логи храните отдельно и добавляйте ссылку по необходимости. Длинный пересказ, который агенты копируют между собой, быстро устаревает. Короткие актуальные наблюдения легче сопоставить с тем, что destination-execution действительно может прочитать на своём компьютере, не доверяя только унаследованному описанию предыдущей работы.

Главная привычка — спрашивать, к каким файлам и какому результату относится утверждение. «Изменено», «проверено», «слито», «развёрнуто» и «установлено» описывают разные связи. Когда связи названы явно, загадка невидимых правок обычно превращается в конкретное расхождение пути или версии. GrantTap помогает сохранить цель Task, пока вы устраняете это расхождение. Условие приёмки остаётся прежним: пользователь получает нужное поведение в нужном приложении, подтверждённое правильными исходниками и артефактом. Ещё одно успешное редактирование в каталоге, который никто не запускает, не приближает к этому результату без проверки всей оставшейся связи.