Synchroniser la mémoire

Ce parcours sert à garder la mémoire à jour entre vos postes, avec git : voir où en est le dépôt, synchroniser, commiter vos changements, résoudre un conflit. L'application le fait en un clic ; l'agent le fait par quatre outils, avec des garde-fous.

Ce que vous demandez à l'agent

Vous demandez à l’agent

« Où en est la synchronisation Git de ma mémoire ? Interroge le distant d'abord. »

→ L’agent appellemem_git_status

• fetch = true

Vous demandez à l’agent

« Synchronise ma mémoire avec le distant. »

→ L’agent appellemem_git_sync

Vous demandez à l’agent

« Commite mes changements avec le message « notes de la session » et pousse. »

→ L’agent appellemem_git_commit

• message = notes de la session

Vous demandez à l’agent

« Il y a un conflit avec le distant : montre-moi les trois versions de chaque fichier. »

→ L’agent appellemem_git_resolve

La synchronisation n'est pas automatique : c'est l'agent qui appelle mem_git_sync, quand vous le lui demandez (« synchronise la mémoire », « où en est git ? ») ou quand il le juge utile. Les procédures livrées (voir Connecter l'agent) l'invitent à le faire au début d'une session, avec la reprise, et en fin de session, avec l'archive ; un agent qui ne les suit pas ne le fera pas de lui-même.

Ce que fait l'agent

1. mem_git_status rend l'état du dépôt : branche, distant (sans identifiants), avance et retard, changements non commités, opération en cours, fichiers portant des marqueurs de conflit, état du greffon Obsidian Git. Il n'écrit rien et n'utilise pas le réseau par défaut ; fetch: true interroge d'abord le distant. Si git est introuvable, l'état le dit avec la commande d'installation, et l'agent vous la relaie sans la lancer.

2. mem_git_sync (aucun paramètre) récupère, rebase vos commits locaux si le distant a avancé, puis pousse. Jamais forcé, jamais de mise de côté automatique. Un vrai conflit annule le rebase : le dépôt revient à l'état d'avant, aucun marqueur n'est laissé, et les fichiers en cause sont rendus. Il est refusé si des changements non commités empêchent le rebase.

3. mem_git_commit commite les changements non commités (paths pour une partie seulement, sinon tous) avec message (non vide, 1 000 caractères au plus), puis pousse (push: false pour ne pas pousser). Il n'est à appeler qu'avec l'accord explicite de l'utilisateur : ces changements sont les vôtres. Il refuse un fichier qui porte des marqueurs de conflit, sauf allow_markers: true pour un fichier qui ne fait que les citer. Le modèle de l'origine Agent IA ne peut qu'entourer le message, qui est toujours conservé : voir Le modèle de message de commit.

4. mem_git_resolve résout un conflit réel, en deux temps :

   • sans resolutions, il inspecte : il rend, pour chaque fichier en conflit, ses trois versions (base, local, distant) et une empreinte, puis annule : le dépôt ne change pas ;
   • avec resolutions (le texte résolu de chaque fichier, ou keep: "local" ou "distant") et l'empreinte rendue (à redonner dans fingerprint), il refait la fusion, écrit les textes, commite et pousse. Si le dépôt ou le distant a bougé entre-temps, rien n'est fait ; aucun marqueur n'est jamais accepté ni laissé.

   Le catalogue demande de ne l'employer qu'avec l'accord de l'utilisateur sur le texte fusionné.

Ce que l'agent ne fait pas

• Initialiser le dépôt et connecter un distant sont des gestes de l'application (Réglages › Synchronisation) : aucun outil ne les fait.
• Il ne force jamais une poussée et ne commite pas vos changements de sa propre initiative.

L'automatisme sur chaque écriture

Quand la mémoire est un dépôt git et que la case Automatisme (« Les agents commitent et synchronisent automatiquement ») est cochée, chaque outil d'agent qui écrit est encadré : avant d'écrire il vérifie le distant, après il commite ce qu'il a touché, et lui seul, puis pousse. Vos changements non commités ne partent pas avec lui, sauf un fichier que vous aviez déjà modifié et que l'outil réécrit : celui-là part avec le commit, qui le nomme (ligne Kessho-Embarque), et l'agent doit vous le dire. Les outils de lecture ne lancent pas git ; mem_git_sync, mem_git_commit et mem_git_resolve sont hors de cet encadrement parce qu'ils sont eux-mêmes le geste.

La première ligne du commit est composée par le modèle de l'origine Automatisme (par défaut kessho({outil}): {objet} {demande}) ; le corps, qui liste les fichiers, et les lignes Kessho-Outil, Kessho-Embarque et Kessho-Repris restent toujours, quel que soit le modèle.

Le résultat d'un outil d'écriture porte alors un compte rendu de synchronisation, que l'agent lit à chaque fois :

statut	Ce que cela veut dire	Ce que fait l'agent
synchronise	Commité et poussé.	Rien.
commite_local	Commité ici, pas poussé (hors ligne, pas de distant, authentification refusée…).	Vous le dit en une ligne, avec le motif.
en_attente	Commité, mais vos changements non commités empêchent la mise à jour depuis le distant.	Vous le dit et propose mem_git_commit après que vous les avez relus.
ignore	Git n'a rien fait (automatisme désactivé, pas de dépôt, git introuvable…).	Rien, sauf pour relayer la commande d'installation de git.
conflit	Un conflit réel : le rebase est annulé et l'outil n'a rien écrit.	S'arrête et passe par mem_git_resolve, avec votre accord.
erreur	Dépôt occupé, opération déjà en cours, ou reprise impossible.	Vous le dit et réessaie un peu plus tard ; il ne supprime jamais index.lock.

Le modèle de message de commit

Dans Réglages › Synchronisation, chaque origine de commit a un modèle de message. Deux concernent l'agent :

• Agent IA : pour mem_git_commit, le modèle par défaut est Message de l'agent, {message}. Le message de l'agent est toujours conservé : il est rogné, un message vide ou blanc est refusé avant tout rendu, et le modèle de l'agent ne peut que l'entourer (il doit contenir {message}, sinon il est ignoré avec un avertissement). Le sujet d'un agent n'est jamais coupé.
• Automatisme : le modèle ne règle que la première ligne du commit de chaque outil d'écriture.

Le message de mem_git_resolve n'est jamais concerné.

Ce que l'agent peut constater : quand le modèle choisi n'a pas pu servir (introuvable, refusé, sans {message}, ou configuration illisible), Kessho commite avec le message de l'agent tel quel, et la réponse de mem_git_commit porte une liste signalements qui dit pourquoi. Sans repli, ce champ est absent : la forme de la réponse ne change pas. Pour un outil d'écriture, le même signalement figure dans le compte rendu de synchronisation. L'agent vous relaie ces signalements ; il ne modifie jamais les modèles, qui se règlent dans l'application. Les variables de contenu ({zones}, {projets}, {fichiers}) et {appareil} écrivent dans l'historique git, poussé sur votre dépôt distant : aucun modèle livré n'en contient.

L'agent n'appelle pas mem_git_commit de lui-même : c'est quand vous le lui demandez, ou quand il le juge utile et avec votre accord.

Ce que vous voyez

L'application montre le même dépôt, et c'est elle qui fait en un clic ce que mem_git_sync fait par l'agent : le bouton Synchroniser la mémoire de la barre d'état commite, récupère, puis pousse. Le champ GIT dit où en est le dépôt (à jour, N à pousser, N à récupérer, conflit…), et Réglages › Synchronisation porte les gestes Synchroniser, Récupérer, Pousser, le Message de commit, le distant, la case Automatisme et les Messages de commit (un modèle par origine). Tout est décrit dans Synchronisation.

Une différence à connaître : le bouton commite tout ce qui a changé sous le message que compose le modèle de l'origine Un clic (par défaut « vault backup: … »), alors que l'agent ne commite vos changements qu'avec votre accord.