Разные агенты не должны делить одно дерево

Проблема параллельных агентов

Уроки s09–s11 позволяют запускать несколько teammate одновременно, но здесь есть скрытая ловушка: все они работают в одном рабочем каталоге. Alice правит auth.py, Bob тоже правит auth.py — git-конфликты, перепутанные файлы, взаимное загрязнение тестов.

Решение из s12 — git worktree: в одном репозитории команда git worktree add позволяет делать checkout разных веток в разные каталоги. Каждый агент получает свой worktree, работает в своём каталоге и не видит чужих изменений.

my-repo/                           # главная рабочая область (lead)
.worktrees/
  alice-auth/                      # изолированный каталог Alice
    (branch: wt/alice-auth)
  bob-api/                         # изолированный каталог Bob
    (branch: wt/bob-api)
  index.json                       # реестр worktree
  events.jsonl                     # журнал событий жизненного цикла

Разделение на две плоскости

s12 явно делит систему на две плоскости:

• Плоскость управления (control plane): JSON-файлы в .tasks/. Task — абстрактная единица «что делать»: зависимости, owner, status.
• Плоскость исполнения (execution plane): каталоги в .worktrees/. Worktree — физический контейнер «где делать»: один каталог + одна ветка.

Они связаны двусторонне через task.worktree и worktree.task_id.

Такое разделение позволяет: переиспользовать механизм управления задачами, заменив среду исполнения (например, Docker-контейнер вместо git worktree). Или заменить механизм задач, сохранив worktree (например, база данных вместо JSON-файлов).

Демонстрация жизненного цикла

Ниже пройдём полный путь: create task → create worktree → run commands → keep или remove. Каждый шаг фиксируется в журнале событий (events.jsonl), который в production обеспечивает наблюдаемость системы.

keep vs remove

Когда worktree выполнил свою задачу, есть два исхода:

• remove: git worktree remove --force — каталог удаляется, ветка обычно тоже. Означает «этот эксперимент не нужен».
• keep: в .worktrees/index.json ставится status: kept, физический каталог сохраняется. Означает «результат нужен, жду слияния».

Типичная схема: subagent делает экспериментальный рефакторинг → результат хороший → keep → человек смотрит → вливает в основную ветку → ручной remove. Результат плохой? remove сразу.