Re_gent : un système de versioning Git conçu pour les agents IA

Les agents IA de coding — Claude Code, Cursor, Cline ou Continue — disposent désormais d'un accès en écriture aux bases de code, mais sans aucun mécanisme natif de traçabilité propre à leur activité. Git enregistre les commits humains, pas les séquences de tool calls autonomes, ni les prompts qui ont motivé chaque modification. Re_gent comble ce vide en introduisant un système de versioning conçu spécifiquement pour les workflows agentiques.

Le projet, publié sous licence Apache 2.0 et développé en Go, s'installe via Homebrew ou directement depuis le dépôt. Il crée un répertoire `.regent/` dans le projet, structuré sur le même modèle que `.git/` : un object store adressable par contenu (hachage BLAKE3), un index SQLite pour les requêtes rapides, et des refs par session. Chaque action d'un agent — appel à un outil Edit, Write ou Bash — génère automatiquement un objet appelé Step, sans nécessiter de commit manuel. Ce Step encapsule le hash du Step parent, un snapshot de l'espace de travail, le delta de conversation, l'outil appelé, ses arguments et son résultat.

La structure résultante forme un DAG (directed acyclic graph). Chaque session d'agent dispose de sa propre branche dans ce graphe, ce qui permet de gérer plusieurs agents concurrents sans conflits — contrairement à Git où les branches concurrentes nécessitent une résolution manuelle. Les objets identiques entre sessions sont dédupliqués automatiquement par l'adressage par contenu.

Les trois commandes centrales définissent l'essentiel du cas d'usage : `rgt log` affiche l'historique chronologique des Steps avec le nom de l'outil, le fichier modifié et un résumé des changements ; `rgt blame <fichier>:<ligne>` identifie, ligne par ligne, quel prompt a produit chaque modification — une fonctionnalité sans équivalent dans Git standard ; `rgt show <hash>` expose le contexte complet d'un Step, incluant l'extrait de conversation entre l'utilisateur et l'agent au moment de l'action. Une commande `rgt rewind` permettant un retour non-destructif à un état antérieur est annoncée pour la phase 3, actuellement en développement.

L'intégration avec Claude Code repose sur un système de hooks transparents : l'agent n'a pas besoin d'être modifié, re_gent intercepte les appels aux outils au niveau du shell. La prise en charge d'autres agents (Cursor, Cline, Continue) est prévue en phase 4. L'implémentation courante représente environ 7 800 lignes de Go, avec les fonctionnalités core — init, log, sessions, status, show, blame — déclarées complètes et utilisées quotidiennement par les contributeurs du projet.

Une extension VSCode accompagne l'outil CLI : elle affiche des annotations de blame inline directement dans l'éditeur, avec des tooltips au survol donnant accès au Step complet (timestamp, nom de l'outil, arguments). Elle s'appuie sur une intégration SQLite directe, sans sous-processus, pour des accès sub-10 ms. La vue latérale expose une timeline de session, et l'historique de conversation est accessible en un clic.

La roadmap publiée décompose le projet en six phases. Les phases 1 et 2 (object store, intégration Claude Code) sont complètes. La phase 3, en cours, couvre `rgt fork` pour créer de nouvelles sessions depuis n'importe quel Step, et `rgt rewind`. Les phases suivantes prévoient le support multi-outils, le partage de sessions entre développeurs, et des fonctionnalités orientées entreprise (analytics d'équipe, reporting de conformité).

Plusieurs questions restent ouvertes à ce stade. La taille du répertoire `.regent/` sur des projets de grande envergure avec de nombreuses sessions n'est pas encore documentée — une commande `rgt gc` est prévue mais non implémentée. La gestion de la confidentialité des transcriptions de conversation (qui peuvent contenir des informations sensibles) n'est pas traitée explicitement dans la documentation actuelle. Enfin, la compatibilité avec des workflows où plusieurs agents modifient simultanément les mêmes fichiers reste à clarifier au-delà des garanties ACID de SQLite mentionnées.

Re_gent se positionne explicitement comme un complément à Git, non un remplaçant : les deux outils coexistent dans le même répertoire de projet, chacun traçant une couche distincte d'activité — humaine pour Git, agentique pour re_gent. Le projet est en développement actif, se définit lui-même comme à « production-quality code at POC-level feature completeness », et accepte les contributions externes.