.projectstore / метод / 3
Много сессий. Много людей. Один vault.
Контекст принадлежит команде. Не чату одного разработчика. ADR и спеки проходят через pull request, как код. На ревью — ход рассуждений.
Четыре способа работы
Несколько сессий, один vault
Два агента или два человека в одном vault одновременно — это нормально. Каждая сессия знает о других, а несколько простых правил не дают им мешать друг другу.
- Никаких тихих перезаписей. Перед сохранением нового файла ProjectStore проверяет, что его ещё нет. Две сессии на одну тему получат конфликт, а не две копии.
- Каждая строка статуса показывает свою работу. 2–6 сессий рядом — и каждая видит ровно свой эпик и свою стори.
- Имя сессии предлагается, а не навязывается. Когда сессия сосредоточилась на одной задаче, она предлагает для неё имя. Редко: не больше двух раз за сессию, 12 предложений на девять записанных сессий.
разработчик A работает над CHECKOUT с 13:35. вы открываете вторую сессию: ⚠ Multi-session warning — 1 other projectstore session active. Run /projectstore:search <topic> before creating new artifacts. позже, когда работа сосредоточится на «Сохранённые карты показаны при оформлении заказа»: projectstore: this session looks like "checkout-sohranennye-karty-pokazany-pri" → /rename checkout-sohranennye-karty-pokazany-pri
Каждый видит не только свою часть.
Разработчик, техлид и QA работают с одними и теми же решениями и критериями. Человеку без агента достаточно GitHub или редактора Markdown: это всего лишь файлы.
Контекст доступен всей команде, а не только владельцу чата.
Общие контракты. Свои зоны работы.
В одном проекте API-, Web- и Platform-команды ведут свои эпики на основе общих ADR и спек. Изменение общего контракта обсуждают на ревью с командами, которые им пользуются. ProjectStore показывает, какие стори от него зависят.
Ответственных за артефакты и согласование контрактов определяет команда.
Разные исполнители. Общие основания.
Планировщик читает решения и карту кода. Исполнитель — стори и спеку. Ревьюер — диф и критерии. Каждый получает нужный ему контекст, а не всю историю чужой сессии. Сессии в одном vault предупреждают друг друга.
Запуск агентов и передача работы между ними — задача вашего harness или оркестратора.
Пример организации работы, а не оркестрация в реальном времени
Как это выглядит в git
Командная настройка по шагам
- 01
Отдельный репозиторий vault
Один репозиторий проектных документов на проект, а не на человека. Он живёт рядом с репозиторием кода.
- 02
Свои копии кода, один vault
Каждый клонирует репозиторий vault, затем запускает
npx projectstore setupв своей копии кода и указывает этот клон как vault. Привязка остаётся на этой машине и не коммитится. - 03
Ветка и pull request
Прежде чем решение примут, его смотрит человек. Критик проверяет решение до pull request, ваша команда — уже в нём.
- 04
Doctor в CI
npx projectstore doctor --jsonработает в CI без агента и без токенов. Если он находит проблемы, шаг падает.reconcile --writeможет там же пересобрать доску.
Claude Code и Codex могут работать над одним проектом бок о бок: у них общая привязка, а модели агентов и состояние сессий у каждого свои.