.projectstore / méthode / 3
Plusieurs sessions. Plusieurs personnes. Un seul vault.
Le contexte appartient à l'équipe, pas au chat d'un seul développeur. Les ADR et les specs passent par des pull requests, comme le code. Ce qu'on relit, c'est le raisonnement.
Quatre façons de travailler
Plusieurs sessions, un seul vault
Deux agents ou deux personnes dans le même vault au même moment : c'est normal. Chaque session sait que les autres existent, et quelques règles simples les empêchent de se marcher dessus.
- Pas d'écrasement silencieux. Avant d'enregistrer un nouveau fichier, ProjectStore vérifie qu'il n'existe pas encore. Deux sessions sur le même sujet tombent sur un conflit, pas sur deux copies.
- Chaque ligne de statut affiche son propre travail. 2–6 sessions côte à côte voient chacune exactement leur epic et leur story.
- Les noms de session sont proposés, pas imposés. Quand une session se concentre sur un travail précis, elle propose un nom. Rarement : deux fois par session au plus, 12 propositions sur neuf sessions enregistrées.
le développeur A travaille sur CHECKOUT depuis 13:35. vous ouvrez une deuxième session : ⚠ Multi-session warning — 1 other projectstore session active. Run /projectstore:search <topic> before creating new artifacts. plus tard, quand votre travail se concentre sur « Les cartes enregistrées sont listées au paiement » : projectstore: this session looks like "checkout-les-cartes-enregistrées-sont-listées-au" → /rename checkout-les-cartes-enregistrées-sont-listées-au
Chacun voit plus que sa propre partie.
Le développeur, le tech lead et la QA travaillent à partir des mêmes décisions et des mêmes critères. Une personne sans agent n'a besoin que de GitHub ou d'un éditeur Markdown : ce ne sont que des fichiers.
Le contexte est accessible à toute l'équipe, pas seulement au propriétaire du chat.
Des contrats partagés. Des périmètres de travail distincts.
Dans un même projet, les équipes API, Web et Plateforme mènent leurs propres epics en s'appuyant sur des ADR et des specs partagés. Un changement de contrat partagé se discute en revue avec les équipes qui l'utilisent. ProjectStore montre quelles stories en dépendent.
Qui possède quels artefacts et qui valide les contrats, c'est à l'équipe d'en décider.
Des exécutants différents. Des bases communes.
Le planner lit les décisions et la carte du code. L'implémenteur lit la story et la spec. Le reviewer lit le diff et les critères. Chacun reçoit le contexte dont il a besoin, pas tout l'historique de la session de quelqu'un d'autre. Les sessions sur un même vault se préviennent mutuellement.
Lancer les agents et faire passer le travail de l'un à l'autre, c'est le rôle de votre harness ou de votre orchestrateur.
Un exemple d'organisation du travail, pas une orchestration en direct
À quoi cela ressemble dans git
Une mise en place d'équipe, étape par étape
- 01
Un dépôt dédié au vault
Un dépôt de documentation par projet, pas par personne. Il se trouve à côté du dépôt de code.
- 02
Chacun sa copie du code, un seul vault
Chaque personne clone le dépôt du vault, puis lance
npx projectstore setupdans sa propre copie du code et désigne ce clone comme vault. La liaison reste sur cette machine et n'est pas commitée. - 03
Une branche et une pull request
Un humain relit chaque décision avant qu'elle soit acceptée. Le critic la vérifie avant la pull request ; votre équipe la relit ensuite, dans la pull request.
- 04
Doctor en CI
npx projectstore doctor --jsontourne en CI, sans agent et sans tokens. Il fait échouer l'étape s'il trouve des problèmes.reconcile --writepeut aussi y reconstruire le tableau.
Claude Code et Codex peuvent travailler côte à côte sur un même projet : ils partagent la liaison, et chacun garde ses propres modèles d'agents et son propre état de session.