Проекты и управляемые worktree

Проект ThreadCells — это зарегистрированный Git-репозиторий и канонический источник полномочий на исходный код. Он даёт сессиям, профилям, статистике и рабочим процессам устойчивое место принадлежности, но не является обычным writable-каталогом нового supervisor. ThreadCells не делает репозиторий безопасным, просто зарегистрировав его, поэтому начинайте с чистого статуса и понимайте предоставляемую границу записи.

Регистрация проекта

Используйте селектор проектов в Spawn Agent, чтобы выбрать существующий репозиторий или добавить репозиторий через поддерживаемый элемент управления проектом. Используйте абсолютный канонический путь и убедитесь, что runtime user ThreadCells может его читать.

Перед первым агентом:

git -C /path/to/project status --short
git -C /path/to/project worktree list

Ожидаемый результат: вы можете отличить уже существующие изменения и worktree от всего, что ThreadCells создаст позднее. Существующая незафиксированная работа принадлежит оператору; агенты не должны её отбрасывать.

Зачем нужны управляемые worktree

Два автора в одном checkout могут перезаписывать правки друг друга, даже если их запросы не связаны. Управляемый Git worktree даёт каждому ограниченному автору собственный checkout и ветку, используя общую объектную базу репозитория.

Canonical repository
  ├── operator checkout
  ├── Session A supervisor worktree
  ├── Session B supervisor worktree
  ├── developer worktree
  └── reviewer worktree or read-only context

ThreadCells записывает эту связь, а не рассматривает временные каталоги как анонимные. Это делает очистку и атрибуцию результатов безопаснее.

Каждая новая supervisor-сессия, связанная с Проектом, включая первую, получает уникальные управляемый worktree и ветку на точно записанной базовой ревизии. Вторая сессия того же Проекта получает другой worktree; resident capacity остаётся глобальной. В одной Сессии по-прежнему может быть только один primary supervisor, а у одного writable-контекста/worktree — не более одного writer lease. Замена непригодного supervisor для того же контекста выполняется через явный recovery takeover и сохраняет worktree этого контекста, а не создаёт независимый.

Активные legacy-сессии, созданные до этого контракта, остаются в существующем рабочем пространстве. При обновлении ThreadCells не перемещает, не сбрасывает, не очищает, не stash-ит и не копирует их dirty-состояние; новые сессии используют управляемые worktree.

Полномочия на запись

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

Проверка точной ревизии связывает и сохранённую попытку review, и физический checkout reviewer. Перед доставкой задания ThreadCells блокирует ввод терминала, проверяет чистый reviewer-worktree, принадлежащий Сессии, переводит его на запрошенный commit в detached-режиме и повторно проверяет ревизию при передаче провайдеру. Повторное использование reviewer для сфокусированной коррекции создаёт новую попытку и подготавливает новую ревизию; предыдущий результат остаётся историей и не может одобрить коррекцию.

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

Возврат работы

Сохранённый результат должен называть изменённые файлы и проверки, но Git остаётся источником истины для кода. Перед слиянием или cherry-pick в обычном процессе репозитория проверьте статус, diff и commits worktree.

ThreadCells не выдаёт полномочия на публикацию. Успешный результат исполнителя не разрешает push, tagging, deployment или переписывание истории.

Очистка

Обслуживание удаляет управляемый worktree только если может доказать, что worktree больше не защищён активным терминалом, рабочим процессом, writer lease или невключённым результатом. Неизвестное владение закрывается с отказом.

Если использование диска высоко, сначала постройте план обслуживания. Не удаляйте каталог worktree напрямую: это может оставить метаданные Git и состояние ThreadCells несогласованными.

Частые ошибки

• Начинать с грязного репозитория, не зафиксировав существующие изменения.
• Давать двум агентам полномочия на запись в один checkout.
• Считать worktree security sandbox.
• Удалять worktree до включения его результата и commits.
• Предполагать, что управляемая ветка автоматически слита или отправлена.

См. Рабочие процессы и сохранённые результаты, чтобы узнать, как результаты worktree поступают координатору.