Quand Hermes modifie un fichier, une bonne réponse dans le chat ne suffit pas à garantir que le résultat te convient. Un checkpoint est une capture de fichiers à un moment donné ; le rollback permet de restaurer une version issue de cette capture.
Nous allons essayer ce mécanisme sur un seul fichier sans enjeu, note.txt. Il contiendra d’abord Repère : A, puis Hermes remplacera cette ligne par Repère : B. Nous lirons la différence avant de restaurer la version A.
1. Préparer un premier essai local
Il te faut Hermes fonctionnel sur Linux ou WSL, un modèle capable d’utiliser les outils de fichiers, et Git disponible sur la machine. Ce parcours utilise le backend local, dans une conversation du terminal. Si tu travailles avec Docker ou une autre sandbox, commence par le tuto sur les environnements d’exécution : les checkpoints décrits ici ne capturent pas les fichiers de ces backends conteneurisés.
Nous utiliserons le profil default. S’il ne correspond pas à ton profil de travail, remplace ce nom dans les commandes. Garde une seule session active sur le dossier d’essai.
git --version
hermes -p default chat --help
hermes -p default config edit
La première commande doit afficher une version de Git. L’aide doit proposer --checkpoints. Dans la configuration, vérifie que terminal.backend vaut local ; une installation plus ancienne peut utiliser la clé terminal.env_type. Si tu dois changer ce réglage, note sa valeur initiale pour pouvoir la remettre après l’essai. Ferme l’éditeur avant de poursuivre.
Crée maintenant un dossier neuf. Le bloc suivant est prévu pour Bash sur Linux ou WSL : mktemp choisit un nom libre sous /tmp, sans réutiliser un projet existant.
essai_checkpoint=$(mktemp -d /tmp/hermes-checkpoint.XXXXXX) &&
cd "$essai_checkpoint" &&
printf 'Repère : A\n' > note.txt &&
pwd &&
cat note.txt
Note le chemin affiché : il désigne le dossier de cet essai. Le fichier doit contenir exactement Repère : A. Ce dossier temporaire sert uniquement à apprendre le mécanisme ; il ne convient pas pour conserver un travail durable.
2. Activer la capture pour cette conversation
Dans l’implémentation actuelle, les checkpoints sont à activer. Ne pars donc pas du principe qu’une capture accompagne chaque modification. Depuis le dossier que tu viens de créer, lance une nouvelle conversation :
hermes -p default chat --checkpoints
Cette option demande l’activation pour la session lancée. Elle ne remplace pas les vérifications de Git, du backend et du dossier réellement utilisé.
Le chemin doit être celui que tu as noté, et le contenu doit être Repère : A. Si ce n’est pas le cas, corrige le contexte avant de demander une écriture. Une simple lecture ne constitue pas une preuve qu’un checkpoint existe.
3. Comprendre quelle version sera récupérée
Quand ils sont actifs, les checkpoints sont tentés avant certaines écritures, notamment les outils write_file et patch. Hermes conserve ces captures dans un stockage Git interne, séparé du .git éventuel de ton projet. Au plus une capture par dossier et par tour est créée : ce n’est pas un historique de chaque petite retouche.
Revenir à une version capturée
Exemple : un seul fichier local, note.txt.
Vérifier le contenu après restauration.
Dans notre exemple, la version utile est A, capturée avant la modification. La restauration devra remettre cette version dans note.txt, à la place de B. Le schéma suppose que la capture a réussi et que le fichier en fait partie ; nous allons justement le vérifier.
4. Faire une modification limitée
Demande un seul changement, sans toucher toi-même au fichier pendant l’essai :
Attends la fin du tour. Vérifie que l’appel à patch a réussi et que la relecture montre B. Une phrase comme « c’est fait » ne suffit pas à confirmer l’écriture.
note.txt contient bien B, il reste à vérifier qu’une version A a réellement été conservée.5. Identifier le checkpoint et lire le diff
Dans la saisie de la conversation Hermes, entre cette commande slash. Elle se tape dans Hermes, pas dans Bash :
/rollback
Repère la capture correspondant au dossier d’essai et au moment précédant le patch. Vérifie le chemin affiché : en l’absence de checkpoint dans le dossier courant, le CLI peut montrer ceux d’autres dossiers. Leur présence ne valide pas notre essai.
Note le numéro du checkpoint retenu. Dans les deux commandes suivantes, N est un repère à remplacer par ce numéro réel, sans chevrons. Ce n’est pas forcément 1.
/rollback diff N
Le diff montre ce qui distingue la version capturée de l’état actuel. Ici, tu dois reconnaître note.txt et le passage de A à B. Si le chemin, le contenu ou le périmètre ne correspondent pas à cet essai, ne restaure rien : retrouve d’abord la bonne capture.
S’il n’y a aucun checkpoint exploitable, arrête l’essai à cette étape. Vérifie l’activation, Git, le backend, le dossier et les messages d’erreur. Ne tente pas de compenser avec une restauration plus large.
6. Restaurer le fichier et contrôler son contenu
Une fois le diff compris, utilise le même numéro N. Le chemin note.txt est relatif au dossier du checkpoint. Cette commande remplace le contenu actuel de ce fichier par la version capturée, y compris tes éventuelles retouches manuelles sur ce fichier.
/rollback N note.txt
Lis le résultat de la commande. En cas d’erreur, ne considère pas le fichier comme restauré. Le CLI actuel peut aussi retirer le dernier tour de conversation lors d’un rollback, y compris ciblé ; cela ne garantit pas que tout l’historique du chat correspond exactement à l’état des fichiers.
Quitte ensuite proprement la conversation :
/exit
De retour dans le terminal qui a lancé Hermes, vérifie le dossier puis le fichier :
pwd
cat note.txt
note.txt contient de nouveau Repère : A. Tu as observé le passage A → B, identifié une capture de A, puis vérifié le retour à A sur le disque.L’essai est terminé. Si tu avais changé le backend du profil, remets maintenant son réglage initial. Garde le chemin du dossier si tu veux relire le fichier ; aucun nettoyage global des checkpoints n’est nécessaire pour terminer ce parcours.
Quand élargir la restauration
Le retour ciblé suffit quand un seul fichier pose problème. Une restauration de dossier demande davantage d’attention : plusieurs fichiers ont pu changer dans le même tour, et certaines modifications peuvent avoir été faites par toi entre-temps.
| Besoin | Commande dans Hermes |
|---|---|
| Voir les captures | /rollback |
| Comparer avant d’agir | /rollback diff N |
| Restaurer un fichier | /rollback N note.txt |
| Restaurer le dossier | /rollback N |
Dans la version actuelle, le rollback de dossier utilise un registre des écritures d’Hermes pour tenter de préserver les retouches manuelles. Si ce registre est vide, il peut revenir à une restauration complète. L’option --all demande explicitement d’écraser aussi ces retouches. Ni l’un ni l’autre ne fait partie de notre premier essai : conserve ailleurs les changements que tu veux garder avant d’envisager ce retour plus large.
Relis la liste avant une nouvelle restauration : un instantané de précaution peut avoir été ajouté et les numéros peuvent changer. /undo, de son côté, agit sur la conversation sans remettre les fichiers en place.
Ce qui peut rester hors de la capture
| Situation | Conséquence pratique |
|---|---|
| Git absent ou capture en échec | Un outil peut avoir modifié le fichier sans point de retour utilisable. |
| Backend conteneurisé | Les chemins de la sandbox ne sont pas capturés par ce mécanisme ; diff et restauration sont refusés. |
| Dossier trop large ou fichier exclu | Le contenu attendu peut manquer. Le dossier personnel entier est notamment écarté ; la limite par fichier vaut 10 Mo par défaut. |
| Dépôt Git imbriqué | Le checkpoint du parent peut ne conserver qu’une référence au dépôt, pas ses modifications non commitées. Une restauration globale est alors refusée. |
| Ancienne capture supprimée | La rétention et les limites de stockage peuvent retirer un point de retour. |
Un message envoyé, une publication ou une opération réalisée dans un service externe ne sont pas annulés parce que tu remets un fichier local à son ancienne version. C’est le périmètre de l’action qui détermine ce qu’il faut vérifier ensuite.
Garder un point de retour durable
Le checkpoint aide à corriger une modification récente. Git conserve les versions que tu choisis de commiter et de partager. Une sauvegarde indépendante permet de retrouver des données quand le problème touche aussi le disque ou la machine. Le stockage local des checkpoints reste exposé à ces pertes.
Pour appliquer cette logique à une mise à jour, poursuis avec mettre à jour Hermes sans casser ce qui marche. Si ton besoin concerne surtout la continuité d’un travail, le parcours reprendre une mission interrompue distingue ce qu’il faut retrouver avant de repartir.
Les commandes et limites ont été recoupées avec la documentation officielle des checkpoints, le gestionnaire de captures et les commandes du CLI. Si ton installation ne propose pas ces options, vérifie sa version avant de suivre le parcours.