Une boucle qui intègre une vérification indépendante.
Les agents écrivent vite du code, et rouvrent tout aussi vite des questions déjà tranchées : chaque nouvelle session arrive vide. La solution n'est pas un agent plus malin. C'est rassembler le contexte → agir → vérifier, appliqué au projet et pas seulement au code.
La boucle
Huit étapes. Deux d'entre elles sont des vérifications faites par un agent qui n'a pas écrit le brouillon.
La boucle ProjectStore. Décider : une tâche de votre part, un ADR, une spec ou une story, un critic indépendant, votre validation. Réaliser : le planner, l'implémentation, un reviewer indépendant, terminé. Chaque artefact arrive dans le vault, et la session suivante le voit.
01Vous dites ce que vous voulez. L'agent ouvre un artefact avant d'ouvrir un éditeur.
02Un ADR quand il y a quelque chose à décider, un epic et des stories pour le travail, une spec quand le « comment » n'est pas évident. Montré d'abord, puis écrit après votre oui.
03Un critic au contexte neuf, qui n'a rien à défendre dans le brouillon, l'attaque. Attendez-vous à un « revise ».
04Vous validez les corrections. L'artefact est marqué comme relu et arrive dans le backlog.
05Un agent prend une story. Le planner lit comment les epics précédents ont été implémentés dans le code et dit où ce changement a sa place.
06Du code et des tests, selon le plan de la story.
07Un reviewer au contexte neuf confronte le diff à chaque critère d'acceptation et demande une preuve.
08Terminé, avec une preuve sous chaque critère. Le tableau, la carte des liens et la carte du code se régénèrent.
Les agents
6agents.Tous sauf un ne peuvent que lire.
Les conseillers vérifient, planifient et rangent, sans rien modifier. Un seul clerk enregistre, après votre Oui, ce que vous avez validé et rien d'autre.
criticlecture seule · indépendant
Après l'écriture ou la modification d'un ADR, d'une spec, d'un epic, d'une story ou d'un document de conception
Cherche les points faibles, confronte chaque affirmation à la source et se demande comment le plan pourrait échouer. Sans complaisance.
opus · maxplannerlecture seule · indépendant
Avant le début du travail sur une story (story plan)
Regarde où vivent les epics précédents dans le code. Indique où le changement a sa place, quoi réutiliser, à quoi faire attention et dans quel ordre travailler.
opus · maxreviewerlecture seule · indépendant
Après le code, avant le commit ou story close
Demande une preuve pour chaque critère d'acceptation, y compris ceux de la spec. Vérifie ensuite l'exactitude, les régressions et les tests.
opus · maxlibrarianlecture seule · suggère
De temps en temps, avant les releases, quand le vault grossit vite
Trouve ce qu'aucune règle ne détecte : des notes de recherche qui contredisent un ADR accepté, des doublons, des liens manquants, des fichiers prêts à être archivés.
opus · maxarchaeologistlecture seule · suggère
Une fois, après la liaison d'une base de code existante
Retrouve les décisions que personne n'a écrites, dans le code, les fichiers de configuration et l'historique git. Propose des ADR pour les consigner, preuves à l'appui.
opus · maxclerkécrit · après votre Oui
Uniquement dans le flux d'une commande, uniquement après votre Oui
Enregistre exactement ce que vous avez validé, rien de plus. Puis reconstruit le tableau et lance les vérifications. N'écrit rien de son propre chef et ne demande rien.
sonnet · max
Les modèles par défaut sont ceux de Claude Code. Dans Codex, chaque rôle est un skill du même nom qui demande à Codex de lancer le rôle, par exemple $projectstore-critic pour le critic ; il utilise le modèle de la session, sauf si vous en définissez un.
Les garde-fous
Ce sont des mécanismes qui tiennent l'ensemble, pas la discipline.
Pas de story, un rappel
Un agent qui se met à modifier du code sans story ouverte reçoit un rappel pour en ouvrir une. Un changement de la taille d'une fonctionnalité commence dans le vault.
Ce qui n'est pas relu reste marqué
Un artefact qui demande une relecture porte review_status: pending jusqu'à ce qu'un passage du critic soit appliqué. « Pas encore relu » est un état que les outils savent lire, pas quelque chose dont quelqu'un doit se souvenir.
Un doctor sans IA
doctor vérifie de façon déterministe la cohérence mécanique du vault. En CI, il tourne sans agent et sans tokens.
Où regarder, généré
graph.md contient les liens de chaque artefact dans les deux sens ; code-map.md indique où vit le code de chaque epic. Avant un choix d'architecture, l'agent est d'abord dirigé vers l'index des ADR.
Après /compact, le vault revient
Dans Claude Code, après un /compact que vous lancez, la session repart avec l'orientation du vault, et avec les fichiers du vault que la conversation avait touchés auparavant.
Une deuxième session est prévenue
Une session qui démarre pendant qu'une autre travaille sur le même vault s'ouvre avec un avertissement multi-session : cherchez avant de créer quoi que ce soit de nouveau.
Terminé veut dire prouvé
Une story se clôt avec une preuve sous chaque critère.
---type: story
epic: "CHECKOUT"
title: "Les cartes enregistrées sont listées au paiement"
status:donecode_refs: ["src/billing/cards/", "tests/cards.test.ts"]
closed_at: "2026-07-14T16:02:11Z"
---## Critères d'acceptation
- [x] Les cartes enregistrées sont listées en premier — preuve : tests/cards.test.ts:21
- [x] Une carte refusée affiche le motif donné par la banque — preuve : tests/cards.test.ts:58
- [x] Aucun numéro de carte n'apparaît dans les logs — preuve : tests/cards.test.ts:73
Le planner a dit où le changement a sa place avant le code, et le plan a été ajouté à la story après votre oui ; le reviewer a ensuite vérifié le diff critère par critère. Chaque ligne de preuve est un test, une commande exécutée ou une ligne de code.
Tout agent peut lire ce registre, avec ou sans le plugin : par la CLI, qui répond en JSON et ne consomme aucun token, ou par les 8 outils en lecture seule du serveur MCP.
orientation
search
status
get_artifact
lineage
neighbors
code_refs
doctor
En petits caractères
En petits caractères
Faire tourner la boucle coûte des tokens : les brouillons, le critic et le reviewer s'exécutent sur le modèle que vous payez déjà. Le README chiffre ce coût.
Dans Claude Code, le critic et le reviewer sont des agents distincts, au contexte neuf. Dans Codex, les rôles sont des skills.
ProjectStore est un contexte de projet partagé et une manière de travailler. Ce n'est pas un orchestrateur d'agents : lancer les agents est le rôle de votre harness.