Task живёт дольше сессии агента: что должно перейти вместе с ней

Отделите цель от разговора

Целью может быть «починить упавший тест платежей, не меняя публичный API». Разговор с провайдером содержит множество проб, тупиков и выводов инструментов, значимых лишь временно. Если личностью работы считать только разговор, после смены провайдера или компьютера человеку придётся искать цель среди сотен сообщений. Task должна хранить краткую понятную цель, проект и последнее проверенное состояние. Транскрипт остаётся ценным evidence, но не становится идентичностью работы. Такой подход позволяет понять, что именно следует продолжать, даже когда старую сессию технически открыть невозможно.

Разделение полезно и внутри одного вендора. Руководство Claude Remote Control говорит, что подключённые устройства видят локальный разговор, и отдельно описывает поведение при очистке или переключении разговора. Документация Cursor указывает, что агенты, начатые на телефоне, появляются на компьютере и вебе; локальную работу можно перенести или направлять удалённо через поддерживаемые маршруты. Codex показывает подключённые threads и контекст проекта в мобильной предварительной версии. Всё это облегчает возврат к нативной сессии. Но новый сторонний провайдер не получает автоматически закрытые рассуждения, режим разрешений, установленные инструменты или точное состояние рабочей копии.

Укажите репозиторий и revision

Одного пути к папке недостаточно для идентификации работы. На двух компьютерах могут быть каталоги с одинаковым именем, но разными ветками, зависимостями и незакоммиченными правками. Облачный агент может работать в своей копии, пока ноутбук разработчика остаётся на предыдущем коммите. Перед handoff запишите идентичность репозитория, ветку или worktree, текущую revision и состояние коммитов. Если есть локальные правки, назовите место, где они находятся. Без таких фактов новый execution может убедительно отвечать по неправильному коду и всё равно выглядеть как «продолжение».

Границы Project и Task в GrantTap помогают организовать запись, но целевому провайдеру всё ещё нужны фактический доступ к репозиторию и совместимые инструменты. Привязанный проект не объединяет права на репозитории и незаметно не копирует файлы. Человеку, принимающему переход, следует проверить целевой компьютер и checkout. Пакет handoff не должен переносить секреты и полные архивы prompts без особой необходимости. Лучше включить краткие ссылки на файлы, выполненные команды, результаты тестов и нерешённые вопросы. Если целевая машина не видит нужную revision, она должна остановиться и сообщить об этом до новой правки.

Сохраняйте решения и ограничения

По мере работы копятся решения человека: отвергнутый подход, выбранный контракт API, срок, запрещённая команда или approval на одно действие. Они легко теряются, если пересказать всё словами «продолжи реализацию». Запишите устойчивые решения в handoff простым языком. Различайте решение для всей Task и разрешение, выданное одному execution. Разовое approval не превращается в широкое полномочие для другого провайдера. Равным образом глобальный запрет возможности на компьютере должен действовать и при новом execution на нём, независимо от того, кто запустил агента.

Принимающему агенту нужно понимать, что проверено, а что только заявлено. «Тесты прошли» слишком расплывчато: укажите команду, revision, время и среду запуска. «Развёртывание завершено» должно содержать назначение и независимую проверку, если она есть. Если прежний провайдер сообщил результат, но подтверждения хоста не поступило, пометьте его неподтверждённым. Это не многословие ради многословия. Так новый execution не примет гладкий пересказ за evidence и не начнёт работу на ошибочном предположении.

Осознанно возобновляйте, переносите или начинайте заново

Когда нужен тот же разговор и те же локальные инструменты, нативное возобновление или Remote Control может быть самым коротким путём. Руководство Claude описывает возобновление серверных сессий после остановки при оговорённых условиях. Cursor описывает перемещение облачной работы между телефоном и компьютером и отдельный Remote Control для личной машины. Подключённое мобильное состояние Codex обслуживает нативный процесс Codex. Перед использованием проверяйте актуальные требования продукта и компонент, который должен оставаться online. Не называйте просмотр той же сессии на другом устройстве миграцией между провайдерами только потому, что она теперь видна на телефоне.

Если исходная среда исчезла или работа должна перейти к другому провайдеру, запустите новый execution с пакетом handoff. Будьте готовы заново читать код и повторять тесты. GrantTap сохраняет Task видимой между поддерживаемыми executions и показывает переход; закрытое состояние модели он не пересаживает. Новый execution должен подтвердить цель, проверить доступ к репозиторию и назвать, какие факты взяты из пакета, а какие получены независимо. Такой честный новый старт часто безопаснее притворства, будто каждый скрытый токен контекста каким-то образом сохранился.

Проверьте преемственность управляемым прерыванием

Выберите безвредную задачу в репозитории с небольшой ожидающей правкой. Начните у одного поддерживаемого провайдера, запишите revision и упавший тест, затем прервите сессию. Сначала попробуйте возобновить её нативно с телефона. Отметьте, какие разговоры, diff, результаты инструментов и approvals доступны. Затем, если ваш процесс требует, передайте цель другому execution или компьютеру. Сравните его исходный контекст с пакетом handoff и попросите перечислить неизвестное до редактирования файлов. В конце повторите тест и проверьте рабочую копию.

Скриншот GrantTap ниже — детерминированная демонстрация интерфейса handoff. Он не доказывает копирование закрытого транскрипта провайдера или прохождение реального теста. Честное заявление о преемственности можно проверить: следующий execution называет правильную цель и репозиторий, соблюдает прежние ограничения, отличает подтверждённое от неподтверждённого и работает от явно указанной revision. Если элемента нет, интерфейс должен показать пробел. Преемственность означает не отсутствие прерываний, а способность восстановиться без выдуманного состояния.

Особенно внимательно проверяйте момент, когда две сессии одновременно продолжают одну Task. У них могут разойтись ветки, решения и ожидания пользователя. Перед параллельной работой выделите разные checkout или worktree и назначьте, кто отвечает за итоговое объединение. Handoff не должен стирать историю предыдущего execution: человек должен видеть, какая попытка дала патч, какая только исследовала проблему, а какая завершилась ошибкой. Если новая сессия исправила старую правку, запишите эту связь явно. Тогда позднее ревью сможет восстановить последовательность решений, не приписывая все изменения одному агенту.