.projectstore

.projectstore / método / 3

Muitas sessões. Muitas pessoas. Um vault.

O contexto pertence à equipe, não ao chat de um desenvolvedor. ADRs e specs passam por pull requests, como o código. O que se revisa é o raciocínio.

Quatro formas de trabalhar

Várias sessões, um vault

Dois agentes ou duas pessoas no mesmo vault ao mesmo tempo é algo normal. Cada sessão sabe das outras, e algumas regras simples evitam que uma atrapalhe a outra.

  • Nada é sobrescrito em silêncio. Antes de salvar um arquivo novo, o ProjectStore verifica se ele já existe. Duas sessões sobre o mesmo tema geram um conflito, não duas cópias.
  • Cada linha de status mostra o próprio trabalho. 2–6 sessões lado a lado veem, cada uma, exatamente o próprio épico e a própria história.
  • Nomes de sessão são sugeridos, não impostos. Quando uma sessão se concentra em um único trabalho, ela recebe a sugestão de um nome. Raramente: no máximo duas vezes por sessão, 12 sugestões em nove sessões registradas.
uma segunda sessão em your-project-vaultClaude Code
o desenvolvedor A trabalha no CHECKOUT desde as 13:35. você abre uma segunda sessão:

⚠ Multi-session warning — 1 other projectstore session active.
  Run /projectstore:search <topic> before creating new artifacts.

mais tarde, quando o seu trabalho se concentra em “Cartões salvos aparecem no checkout”:
projectstore: this session looks like "checkout-cartões-salvos-aparecem-no-checkout"
  → /rename checkout-cartões-salvos-aparecem-no-checkout

Todos enxergam mais do que a própria parte.

O desenvolvedor, o tech lead e o QA trabalham a partir das mesmas decisões e dos mesmos critérios. Quem não usa agente só precisa do GitHub ou de um editor de Markdown: são apenas arquivos.

O contexto está disponível para a equipe toda, não só para o dono do chat.

Contratos compartilhados. Áreas de trabalho separadas.

Em um mesmo projeto, as equipes de API, Web e Plataforma conduzem seus próprios épicos com base em ADRs e specs compartilhados. Uma mudança em um contrato compartilhado é discutida na revisão com as equipes que o usam. O ProjectStore mostra quais histórias dependem dele.

Quem é dono de quais artefatos e quem aprova os contratos é decisão da equipe.

Executores diferentes. Base comum.

O planejador lê as decisões e o mapa de código. O implementador lê a história e a spec. O revisor lê o diff e os critérios. Cada um recebe o contexto de que precisa, não todo o histórico da sessão de outro. Sessões no mesmo vault avisam umas às outras.

Iniciar agentes e passar trabalho entre eles é tarefa do seu harness ou orquestrador.

Um exemplo de organização do trabalho, não orquestração em tempo real

o vault em um repositório próprio

Como fica no git

Desenvolvedores com seus próprios agentes se vinculam a um único vault, que fica em um repositório git próprio. ADRs e specs são revisados em pull requests. Um colega sem agente revisa no GitHub ou no Obsidian. setup push / pull revisão e pull Dev AClaude Code + projectstoreagente Dev BCodex + projectstoreagente Dev Csem agenterevisa no GitHub/Obsidian your-project-vault repo git próprio · markdown puro adr/ decisões, com datas specs/ o comportamento epics/ · stories/ o backlog kanban.md o quadro graph.md todos os vínculos code-map.md épico↔código toda gravação é mostrada e aprovada git remote GitHub · GitLab · ou outro ADRs e specs revisados em pull requests: o porquê é revisado, não só o código
Coloque o vault em um repositório próprio. Todos instalam o ProjectStore, se vinculam ao mesmo vault e só salvam mudanças depois da aprovação. Um colega sem agente revisa no GitHub ou no Obsidian.
Configuração

Uma configuração de equipe, passo a passo

  1. 01

    Um repo separado para o vault

    Um repositório de documentos por projeto, não por pessoa. Ele fica ao lado do repositório de código.

  2. 02

    Checkouts próprios, um vault

    Cada pessoa clona o repositório do vault e roda npx projectstore setup na sua própria cópia do código, indicando esse clone como o vault. O vínculo fica naquela máquina e não entra no commit.

  3. 03

    Uma branch e um pull request

    Uma pessoa revisa cada decisão antes de ela ser aceita. O critic a verifica antes do pull request; a sua equipe a revisa no próprio pull request.

  4. 04

    Doctor no CI

    npx projectstore doctor --json roda no CI sem agente e sem tokens. Ele faz a etapa falhar quando encontra problemas. reconcile --write também pode reconstruir o quadro lá.

O Claude Code e o Codex podem trabalhar lado a lado em um mesmo projeto: compartilham o vínculo, e cada um mantém os próprios modelos de agentes e o próprio estado de sessão.

Como funciona →Por que funciona →Instalar →