GrantTapПроекты, репозитории и Mesh
Разделяем Account Mesh, Project Mesh и принадлежность задачи.
В этой главе · 7 разделов
Mesh — карта совместной работы#
Project Mesh объединяет задачи, компьютеры, repositories и правила проекта. Его задача — сохранить понятную структуру работы, когда несколько coding agents участвуют в одном результате. Открывая Mesh, вы видите не просто список окон чата, а связь между работой, её исполнителями и доступными фактами.
В учебном GrantTap Lab одна Task добавляет скидку HELLO10 в расчёт заказа, другая проверяет пустую корзину. Они могут выполняться разными провайдерами, но относятся к одному проекту и согласованным repository bindings. Если один агент уже работает с модулем, другой может увидеть соответствующее намерение и избежать лишнего пересечения.
Mesh не означает общую память без границ, доступ ко всему диску или автоматическое объединение любых похожих папок. Каждый Project остаётся отдельной областью координации и разрешений.
Account, Project, Task, Execution#
| Уровень | Устойчивый смысл |
|---|---|
| Account Mesh | Личная сеть устройств и компьютеров, вход через passkey |
| Project Mesh | Область работы, repositories, участников и Governance |
| Task | Стабильная человеческая единица работы |
| Execution | Конкретная native session одного провайдера на одном компьютере |
Одна Task может получить несколько executions: например, начаться в Claude Code и продолжиться в Codex. Заголовок Task остаётся полезным человеку, а original native conversations сохраняют собственные идентичности и историю.
Дочерние агенты отображаются внутри родительской Task как вложенные execution conversations. Они не являются Skills и не должны засорять основной список независимыми root Tasks. Подробнее о навигации — Task и Execution.
Репозитории и рабочие папки#
В Mesh / Repositories можно перейти от проекта к опубликованным repository identities и связанным chats. Один Mesh способен включать несколько repositories; один репозиторий может иметь разные checkouts. Приложение сохраняет исходные маршруты и права, даже когда помогает найти связанную работу.
Имя папки не доказывает Git identity. Если сведения отсутствуют или конфликтуют, это должно быть отмечено. Workspace без подтверждённого Git также не превращается автоматически в проверенный repository.
В учебном проекте сначала выберите один репозиторий с небольшим checkout. Проверьте branch, owning computer и текущую Task, прежде чем добавлять вторую рабочую папку. Это упрощает чтение Graph и Health и предотвращает путаницу с одинаковыми относительными путями.
Что видят агенты#
Поддерживаемый scoped Mesh context содержит bounded сведения: владельцев задач, зависимости, claims, вопросы, ответы и относящиеся к работе события. Он не должен рассылать всем агентам полные transcripts и скрытые рассуждения соседних conversations.
Caller attribution проверяет execution, которая действительно сделала вызов. Знание чужого Task ID не даёт агенту право действовать от его имени. Изменение ownership не является произвольной командой модели: оно связано с проверенным результатом runtime и handoff receipt.
Техническое согласование и advisory conflicts остаются внутри Mesh. Product, business, security, destructive решения, неразрешённые конфликты и failed handoff используют Needs You. Так интерфейс сохраняет роль человека там, где нужен выбор, а не требует ответа на каждый технический обмен.
Claims и пересечения работы#
Claim — ограниченное по времени заявление о намерении работать с ресурсом. Например, Task сообщает, что собирается менять order.mjs. Это помогает другому агенту заметить пересечение до merge.
Claim не доказывает, что файл уже изменён, и не является filesystem lock операционной системы. У него есть срок действия. Одинаковый order.mjs в двух разных repositories не означает конфликт. У другого checkout того же repository может быть coordination warning. Сравнение путей учитывает сегменты: order.mjs и order.mjs.bak — разные ресурсы.
В GrantTap Lab можно показать два учебных намерения для одного модуля, затем объяснить, кто продолжает работу и кто освобождает claim. Не стоит выводить из такой карточки, что агент уже внёс правку: результат проверяется отдельно через Files и историю.
Перенос задачи и новый владелец#
Handoff продолжает ту же Task в новой execution. Capsule описывает цель, решения и Git facts; отдельно подготовленный перенос сохраняет доступный видимый контекст разговора для destination. Это не копия всего диска и не перенос скрытых рассуждений.
Если source checkout содержит uncommitted changes, они остаются на исходном компьютере, а destination начинает с последнего commit. Интерфейс предупреждает об этом. Явно выбранный checkpoint позволяет включить такие изменения в отдельный commit; push требует своего подтверждённого выбора.
Только проверенный destination receipt меняет ownership. Старую execution после передачи нельзя считать текущей лишь потому, что provider продолжает сообщать о ней. Open destination открывает новую работу. Continue anyway в старом чате означает параллельную ветку и требует предусмотренного подтверждения компьютера.