Les nouveaux modèles pilotent toute votre roadmap pendant des heures, voire des jours, sans perdre le fil. C'est précisément pour cela que la dérive d'état compte davantage, pas moins : plus un agent en fait entre vos points de contrôle, plus l'état qu'il a consigné peut cesser de correspondre à git, en silence. casp check est la barrière déterministe qui bloque le push dès que c'est le cas — avec Claude Code aujourd'hui, et chaque modèle qui sortira demain.
Vous revenez sur un projet après une semaine — ou vous en jonglez cinq à la fois. L'agent lit un fichier d'état qui ne correspond plus à la réalité, se lance avec assurance dans un travail déjà livré, et vous brûlez un après-midi à le défaire.
Les tableaux, les cartes et les tableurs ne vous sauvent pas : reconstituer le contexte est manuel, et l'agent ne peut rien en lire. L'état doit être lisible par machine, natif git — et vrai de façon prouvable.
CASP donne à chaque projet un fil unique qui survit d'une session à l'autre — et ne peut pas dévier en silence.{
"phase": "13 — camera streaming",
"next_prompt": "phases/14-camera.md",
// shipped in v13.4
"last_commit": "a1f3c9",
// not in git history
"migrations": ["0001"…"0007"],
// git stops at 0006
}
L'espace voisin — Mem0, Letta, Zep, les nouveaux projets de « mémoire » natifs git — stocke tout ce qui s'est passé. Presque aucun ne vérifie que l'état stocké correspond encore à la réalité de git. Cette vérification, c'est casp check — et elle est obligatoire avant chaque push.
Votre next_prompt pointe vers un fichier déjà livré — ou qui n'existe pas. CASP refuse de démarrer la mauvaise session.
last_commit absent de l'historique, liste des migrations désynchronisée, état non commité — confronté à git lui-même, pas à une estimation.
Aucun score de similarité approximatif. Une barrière pass/fail dure et répétable qui arrête le push tant que l'état ment.
CASP ne remplace rien dans votre workflow. Il comble la seule lacune que rien d'autre ne couvre — le présent validé d'un projet, sous une forme que votre agent peut lire et exploiter.
Pas de base de données. Pas de service. Pas de magasin vectoriel. Trois fichiers simples qu'un agent peut lire dès la première ligne de n'importe quelle session.
Lisible par machine, par projet : phase actuelle, phase suivante, le next-prompt exact à exécuter, les phases livrées, les migrations appliquées, le dernier commit, le dernier identifiant de session.
Le « où j'en suis à l'instant T » sur un seul écran. Ouvrez-le, retrouvez le fil en cinq secondes — sans archéologie.
Les 3 prochaines à livrer plus un tableau de bord des phases. L'agent connaît toujours l'ordre du travail.
session-prompt, session-log et audit-brief font que chaque session — humaine ou agent — produit des artefacts de même forme. La structure est imposée, pas suggérée.Un vrai produit, ce n'est pas une seule fonctionnalité. C'est des dizaines de phases réparties entre l'API, le client web et le mobile, livrées sur des semaines par des sessions et des agents qui se relaient. CASP maintient un ordre validé unique sur l'ensemble — pour que n'importe quel agent sache quelle phase vient ensuite, et ne relivre jamais une phase déjà livrée.
Et la boucle se referme d'elle-même : à la fin de chaque session, l'agent écrit pour vous le prompt de la session suivante — vous ajustez une ligne, vous ne rédigez pas de zéro — ajoute un journal de session et incrémente l'état. Ouvrez la session suivante et elle reprend exactement là où la précédente s'est arrêtée. La roadmap s'exécute ; vous supervisez.
Chaque chiffre ci-dessous est lu directement dans le state.json de chaque projet — le même fichier que l'agent lit, validé face à git au dernier push. Aucun calcul marketing.
Un ERP de gestion de flotte destiné aux clients d'une entreprise de transport en Côte d'Ivoire — web + mobile, multi-module, multi-rôle : chauffeurs, véhicules, conformité, caisse, garage, contentieux, comptabilité.
Chaque module est une phase validée. L'agent lit le cockpit, lance la phase suivante depuis next_prompt, et n'a jamais relivré un module déjà livré — même sur une journée à six sessions.
La plateforme interne d'ops & d'orchestration des lancements de ZeroSuite — une roadmap sur plusieurs mois menée par une vraie équipe, avec gating en mode lancement et un backlog post-lancement suivi.
Un fil validé unique sur 40+ phases et trois personnes — plus 58 éléments explicitement reportés après le lancement, aucun perdu. C'est le cas du « gros projet multi-utilisateurs » pour lequel CASP a été conçu.
Même protocole, deux produits très différents. Le cockpit est la seule chose qu'ils partagent.
Les outils de mémoire retiennent qui vous êtes. CASP suit où en est votre projet — et le prouve. Artefact différent, opération différente, défaillance différente qu'il prévient.
Une syllabe, aucun homographe, les mêmes en anglais, en français ou en espagnol.
state.next_prompt.CASP fournit des slash-commands Claude Code pour que l'état vive là où vous travaillez déjà.
Statut en lecture seule — l'agent lit le fil actuel avant d'écrire la moindre ligne.
Démarre automatiquement la session suivante directement depuis state.next_prompt. Aucun copier-coller, aucune supposition.
Compatible avec Claude Code · Cursor · Aider · Continue — tout ce qui lit des fichiers.
Un agent qui fait la mauvaise chose coûte un après-midi. Cent agents qui le font sur cent dépôts coûtent un trimestre. CASP est le garde-fou déterministe que vous insérez dans la boucle d'automatisation — la même forme dans chaque projet.
casp check occupe le même emplacement que le lint et les tests. Un état qui ment ne peut pas être mergé — la dérive est bloquée au niveau de l'organisation, pas laissée à la discipline de chacun.
Les agents autonomes multiplient les erreurs. CASP remet à chacun d'eux le même fil validé à lire et la même barrière dure avant qu'il ne pousse. L'automatisation sans la taxe du travail en double.
Chaque transition d'état est un commit git. Un registre complet, comparable et réversible de la façon dont chaque projet a avancé — git log est votre piste de conformité.
100 % local, zéro télémétrie, pas de cloud, pas de compte. Rien à auditer, rien à exfiltrer. La revue de sécurité tient en une ligne : il ne quitte jamais la machine.
jobs: state-check: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: { fetch-depth: 0 } # casp checks against full git history - run: npx @justethales/casp check # ✗ fails the build the moment state drifts
Un protocole, tous les dépôts. La même forme validée, à l'échelle de l'organisation.
Un protocole gagne son adoption en étant prévisible. Ces règles ne plient pas.
CASP contrôle ce que votre dépôt est, jamais ce que vous comptiez faire. Les faits face à git, à chaque fois.
Les artefacts canoniques sont imposés, pas suggérés. Chaque session ressort avec la même forme.
Le validateur n'est pas optionnel. Un état qui ment n'atteint jamais votre remote.
Déterministe, natif git, 100 % local. Zéro télémétrie. Pas de cloud, pas de compte, pas de facture.
Installez, initialisez, et votre agent lit la vérité dès sa première ligne.
$ npm i -g @justethales/casp $ casp init # scaffold the layer $ casp status # where am I right now $ casp check # prove the state is true