.projectstore / метод / 3

Много сессий. Много людей. Один vault.

Контекст принадлежит команде. Не чату одного разработчика. ADR и спеки проходят через pull request, как код. На ревью — ход рассуждений.

Четыре способа работы

Несколько сессий, один vault

Два агента или два человека в одном vault одновременно — это нормально. Каждая сессия знает о других, а несколько простых правил не дают им мешать друг другу.

  • Никаких тихих перезаписей. Перед сохранением нового файла ProjectStore проверяет, что его ещё нет. Две сессии на одну тему получат конфликт, а не две копии.
  • Каждая строка статуса показывает свою работу. 2–6 сессий рядом — и каждая видит ровно свой эпик и свою стори.
  • Имя сессии предлагается, а не навязывается. Когда сессия сосредоточилась на одной задаче, она предлагает для неё имя. Редко: не больше двух раз за сессию, 12 предложений на девять записанных сессий.
вторая сессия в your-project-vaultClaude Code
разработчик 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

Разработчики со своими агентами привязаны к одному vault в отдельном git-репозитории. ADR и спеки проходят ревью через pull request. Коллега без агента смотрит их на GitHub или в Obsidian. настройка push / pull ревью и pull Разработчик AClaude Code + projectstoreагент Разработчик BCodex + projectstoreагент Разработчик Cбез агентаревью в GitHub или Obsidian your-project-vault свой git-репо · обычный markdown adr/ решения, с датами specs/ как должно работать epics/ · stories/ бэклог kanban.md доска graph.md все связи code-map.md эпик ↔ код каждая запись показана и одобрена git remote GitHub · GitLab · что угодно ADR и спеки ревьюятся как pull request: ревью проходит «почему», а не только код
Положите vault в отдельный репозиторий. Каждый ставит ProjectStore, привязывается к тому же vault и сохраняет изменения только после одобрения. Коллега без агента проводит ревью на GitHub или в Obsidian.

Командная настройка по шагам

  1. 01

    Отдельный репозиторий vault

    Один репозиторий проектных документов на проект, а не на человека. Он живёт рядом с репозиторием кода.

  2. 02

    Свои копии кода, один vault

    Каждый клонирует репозиторий vault, затем запускает npx projectstore setup в своей копии кода и указывает этот клон как vault. Привязка остаётся на этой машине и не коммитится.

  3. 03

    Ветка и pull request

    Прежде чем решение примут, его смотрит человек. Критик проверяет решение до pull request, ваша команда — уже в нём.

  4. 04

    Doctor в CI

    npx projectstore doctor --json работает в CI без агента и без токенов. Если он находит проблемы, шаг падает. reconcile --write может там же пересобрать доску.

Claude Code и Codex могут работать над одним проектом бок о бок: у них общая привязка, а модели агентов и состояние сессий у каждого свои.

Как это работает →Почему это работает →Установка →