.projectstore

.projectstore / метод / 3

Багато сесій. Багато людей. Один vault.

Контекст належить команді, а не чату одного розробника. ADR і специфікації проходять через пул-реквести, як код. На рев’ю потрапляють саме міркування.

Чотири способи працювати

Кілька сесій, один 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.

пізніше, коли ваша робота зосередиться на «Saved cards are listed at checkout»:
projectstore: this session looks like "checkout-saved-cards-are-listed-at-checkout"
  → /rename checkout-saved-cards-are-listed-at-checkout

Кожен бачить більше, ніж свою частину.

Розробник, техлід і QA працюють з одними й тими самими рішеннями та критеріями. Людині без агента потрібен лише GitHub або редактор Markdown: це просто файли.

Контекст доступний усій команді, а не лише власникові чату.

Спільні контракти. Окремі ділянки роботи.

В одному проєкті команди API, Web і Platform ведуть власні епіки на основі спільних ADR і специфікацій. Зміну спільного контракту обговорюють на рев’ю з командами, які ним користуються. ProjectStore показує, які сторі від нього залежать.

Хто відповідає за які артефакти і хто затверджує контракти — вирішує команда.

Різні агенти. Спільна основа.

Планувальник читає рішення і мапу коду. Виконавець — сторі та специфікацію. Рев’юер — диф і критерії. Кожен отримує потрібний йому контекст, а не всю історію чужої сесії. Сесії в одному vault попереджають одна одну.

Запуск агентів і передавання роботи між ними — завдання вашого середовища (harness) або оркестратора.

Приклад організації роботи, а не оркестрація в реальному часі

vault в окремому репозиторії

Як це виглядає в git

Розробники з власними агентами прив’язуються до одного vault в окремому git-репозиторії. ADR і специфікації проходять рев’ю як пул-реквести. Колега без агента робить рев’ю на GitHub або в Obsidian. setup 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 і специфікацій у пул-реквестах: рев’ю проходить «чому», а не лише код
Тримайте vault в окремому репозиторії. Кожен встановлює ProjectStore, прив’язується до того самого vault і зберігає зміни лише після схвалення. Колега без агента робить рев’ю на GitHub або в Obsidian.
Налаштування

Налаштування для команди, крок за кроком

  1. 01

    Окремий репозиторій для vault

    Один репозиторій проєктних документів на проєкт, а не на людину. Він лежить поруч із репозиторієм коду.

  2. 02

    Власні робочі копії, один vault

    Кожен клонує репозиторій vault, потім запускає npx projectstore setup у своїй робочій копії коду й вказує цей клон як vault. Прив’язка лишається на тій машині й не комітиться.

  3. 03

    Гілка і пул-реквест

    Кожне рішення, перш ніж його приймуть, переглядає людина. Critic перевіряє рішення ще до пул-реквесту, а ваша команда — уже в ньому.

  4. 04

    Doctor у CI

    npx projectstore doctor --json працює в CI без агента і без токенів. Якщо є проблеми, крок завершується з помилкою. reconcile --write може там само перебудувати дошку.

Claude Code і Codex можуть працювати над одним проєктом пліч-о-пліч: прив’язка в них спільна, а моделі агентів і стан сесій кожен має власні.

Як це працює →Чому це працює →Встановити →