Одна Task, несколько исполнений

Что передаётся вместе с Task

Полезная передача содержит ограниченный набор: цель, текущего владельца, применимые решения, блокеры, claims на ресурсы и маршрут следующего исполнения. Она не копирует скрытые рассуждения и не требует общего приватного transcript у всех провайдеров. Человек видит одну Task и последовательность выполнявших её executions.

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

Зачем нужны ветки и receipts

Параллельные агенты могут менять один репозиторий. Отдельные ветки или worktrees и claims на ресурсы показывают пересечения до конфликта при слиянии. Receipt передачи говорит, что следующее execution приняло работу. Он ещё не доказывает, что агент усвоил решения или что изменения кода прошли проверку.

После завершения Task проверьте итог, тесты и неизвестные факты. Текст в stdout не означает успех, если процесс завершился с ошибкой. Доставка, исполнение и подтверждённый результат — разные события.

Телефон для точечных решений

Телефон удобен, чтобы ответить на конкретный вопрос, разрешить или запретить ограниченное действие и увидеть текущую точку Task. Ему не нужно хранить всё состояние coding runtime. Исполнение остаётся на компьютере; контроллер переносит полномочия и краткую историю для следующего шага.

Task хранит историю запроса

Представьте просьбу исправить падающий тест. Агент изучает файлы, поручает дочернему агенту узкий поиск и останавливается, когда для команды требуется разрешение. Это события внутри одного запроса человека. Если окно провайдера закрывается, исходная цель не становится новой целью. Стабильная Task позволяет телефону показывать ту же работу, следующее решение и историю исполнений, не превращая каждую смену сессии в отдельное поручение.

Различие особенно важно, когда в работу входит второй провайдер или компьютер. Новое execution должно знать, какую Task оно обслуживает и какие факты были намеренно переданы. Нельзя требовать от него невидимых рассуждений прежнего агента или считать краткое резюме полным transcript. Видимая человеку запись сохраняет цель, решения, блокеры и ссылки на evidence, а провайдер продолжает использовать собственную native session. Непрерывность означает прослеживаемую работу, а не тождественное внутреннее состояние.

Передача, которую можно проверить

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

Целевая сторона должна явно подтвердить приём вместо молчаливой видимости продолжения. Приём означает, что маршрут дошёл до совместимой сессии; он не означает понимания каждой детали или завершения Task. Если запуск невозможен из-за недоступной машины, неподдерживаемого провайдера или другого checkout, причина остаётся видимой в Task. Тогда действие в очереди не выглядит как уже выполняющаяся работа.

Состояние репозитория — часть маршрута

Задача о коде зависит не только от названия. Следующему execution нужно знать репозиторий и checkout, наличие незакоммиченных изменений и пересечение с работой другого агента. Один путь к папке неоднозначен на разных компьютерах; одинаковое имя ветки не гарантирует одинаковое содержимое. Добавьте к маршруту revision и сведения о занятых ресурсах, а принимающая сторона пусть сообщит, что она действительно видит до первой правки.

Допустим, два агента готовят изменения одного модуля. Разные worktrees разделят файлы, но не примут продуктовое решение, какой результат нужен. Claims заранее показывают вероятное пересечение, а последующее review разрешает его. Receipt со словом «принято» поэтому не является результатом merge. Task должна показывать цепочку от маршрута до проверки кода и тестов, оставляя место конфликту и неизвестности.

Какие решения подходят телефону

Телефон удобен для небольших конкретных действий: продолжить Task на названном компьютере, ответить на запрос разрешения или посмотреть последний результат. До нажатия нужно видеть цель и последствия. Кнопки «продолжить» недостаточно, когда доступно несколько компьютеров и провайдеров. Человеку важно понимать, возобновляется ли существующее execution, запускается ли поддерживаемое новое или сообщение лишь ставится в очередь до восстановления связи.

Телефон не заменяет просмотр diff, повтор падающего теста и внимательную оценку опасной команды на компьютере, когда для этого нужен широкий контекст. Краткий статус может вести к evidence и ясно формулировать следующее действие человека. Он также должен уметь сообщить «неизвестно»: отсутствие наблюдения о вызове отличается от наблюдаемой ошибки, а оба состояния отличаются от подтверждённого результата.

Как проверить весь сценарий

Для пробного запуска выберите небольшую Task и запишите её цель. Пусть один провайдер исследует проблему, зафиксирует решение или блокер, после чего запросите поддерживаемый handoff на конкретное второе execution. Изучите capsule и receipt принимающей стороны. Проверьте, что новая сессия видит нужный репозиторий и может объяснить следующий шаг. В конце осмотрите изменение кода и повторите нужный тест. Каждый этап проверяет отдельное обещание.

Если провайдер или host не поддерживает удалённый старт, остановитесь на этой границе и воспользуйтесь поддерживаемым путём продолжения. Текущее покрытие handoff в GrantTap зависит от провайдера и цели; концептуальная схема его не расширяет. Иллюстрация выше показывает последовательные рабочие места, а снимок приложения ниже сделан на детерминированных демоданных. Ни один из них не заменяет реальный receipt и доказательства изменения вашей Task. Ценный итог — цепочка решений, к которой можно вернуться.

Когда продолжение лучше отложить

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

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

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