Перенос задачи между агентами

Transfer to передаёт стабильную задачу другому агенту или компьютеру. Цель и идентичность Task сохраняются, а destination получает отдельное исполнение. Это управляемая передача состояния, а не простое переименование чата и не автоматическое слияние веток.

Открыть форму передачи#

В списке Now или Tasks свайпните карточку влево и нажмите Send, либо откройте предусмотренное действие передачи в управлении задачей. Форма называется Transfer to.

1. Проверьте исходную задачу, компьютер и репозиторий.
2. Выберите destination computer и доступного провайдера.
3. Выберите модель и Effort из того, что сообщил именно destination computer. Automatic оставляет выбор провайдера.
4. Добавьте Comment for the next agent: что уже сделано, что проверить и какой следующий шаг нужен.
5. Изучите предупреждения и выбор checkpoint, затем подтвердите передачу.

Если форма предлагает несколько допустимых репозиториев, выберите настоящий исходный checkout. Похожее имя папки не заменяет проверку Git identity. Недоступный репозиторий не должен молча подменяться другим.

Что переезжает вместе с задачей#

Передача использует зашифрованную Task Capsule: идентичность, цель, известный статус, выбранное назначение, сведения о committed revision и контекст продолжения. Destination подготавливает отдельную рабочую область и сохраняет видимый контекст для нового агента.

Успешная подготовка сама по себе не запускает новый агентский ход. Подготовленный destination chat начинает нативное исполнение с вашим первым сообщением. Поэтому состояние «чат готов» отличается от «агент уже работает».

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

Незакоммиченная работа и checkpoint#

Без checkpoint передаются committed факты. Незакоммиченные изменения остаются на исходном компьютере; предупреждение объясняет, что destination их не получил. Это предупреждение для вашего решения, а не автоматический запрет любой передачи.

Если хотите включить такие изменения, используйте явный выбор checkpoint. Компьютер перепроверяет реальное состояние при отправке, поэтому устаревшее чтение телефона не должно отменять выбранный checkpoint.

Checkpoint создаёт отдельный commit на отдельной ветке через временный индекс. Исходные HEAD, текущая ветка и рабочее дерево не должны переключаться на него. Файлы, распознанные как секретные по защищаемым именам, исключаются; результат может быть частичным. Если checkout разделяется несколькими работами, состав checkpoint требует вашего внимания: он может включать изменения шире одной задачи.

Не считайте такой снимок универсальным поиском секретов. Перед разрешённой публикацией проверяйте состав изменений и требования своего проекта. Введение в границы доступа находится в Governance и Безопасности.

Ожидание и подтверждение#

После отправки форму можно закрыть: задача сохраняет состояние подготовки, в том числе после перезапуска приложения. Статус различает сохранённый запрос, подтверждение исходной стороны и validated destination receipt.

Saved on relay не равно готовому destination. Только подходящая квитанция подтверждает подготовку; открытие чата также зависит от доступной записи назначения. Check again читает уже существующее состояние и не создаёт второй перенос.

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

Продолжить исходную ветку#

В исходном чате появляются Transferred или Transfer queued, а также Open destination и Continue anyway. Предпочтительный путь после подтверждённой передачи — открыть destination.

Continue anyway требует отдельного подтверждения. Оно разрешает продолжить исходную ветку параллельно. Destination при этом не останавливается: обе стороны могут независимо менять файлы и состояние. Это не автоматический возврат владения и не слияние их результатов.

Если действительно хотите снова работать у прежнего провайдера, сначала определите, нужна ли параллельная ветка либо новая управляемая передача. Не путайте свайп Send с отменой уже принятой передачи.

Проверка после переноса#

1. Убедитесь, что задача сохранила прежнюю цель и проект.
2. Проверьте destination provider, computer, workspace и revision.
3. Прочитайте comment и предупреждения об оставленных изменениях.
4. Отправьте один следующий шаг и проверьте его доставку.
5. Сравните реальный результат в новом исполнении; старую историю открывайте как историческую.

Для упражнения используйте тестовый проект и небольшой committed README. Сначала изучите форму без отправки, затем выполните один перенос при доступном destination. Не используйте production-ветку для первой проверки механизма.

Разницу Task и Execution объясняет предыдущая глава. Хранение решений и контекста описано в Knowledge.