Aller au contenu principal

Faire entrer votre dépôt en mémoire

Vous avez installé @mnemosyne_os/mcp depuis un annuaire, et votre agent tient maintenant des outils qu'il ne peut pas encore utiliser. Cette page dit ce qui marche déjà et à quoi sert l'application. Puis quoi faire pour que votre code soit devant votre agent demain matin.

Ce qui répond sans rien installer d'autre​

Trois outils lisent les fichiers de transcript que votre harnais d'agent écrit déjà sur le disque :

  • mnemosyne_agent_list nomme les sessions qui tournent sur cette machine, dans quel dépôt et sur quelle branche, et marque celle à qui vous parlez.
  • mnemosyne_agent_collisions dit si un autre agent travaille dans le même arbre de travail git. L'index est partagé par tous les processus d'un arbre, donc un commit de l'un emporte ce que l'autre a préparé.
  • mnemosyne_agent_files liste les fichiers qu'une session a écrits, par appel d'outil et par commande shell.

Aucune application, aucun coffre, aucun jeton, aucun appel réseau. Demandez à votre agent ce qui tourne d'autre dans ce dépôt et vous avez une réponse du premier coup.

Tout le reste refuse tant que l'application ne tourne pas. Le refus dit lequel des deux problèmes vous avez : elle n'a jamais été installée ici, ou elle est installée et fermée. Ce sont deux prochaines étapes différentes, donc deux phrases différentes.

Pourquoi il y a une application​

Question légitime quand on est venu chercher un serveur. Trois choses doivent vivre quelque part, et aucune ne tient dans un relais.

Il faut quelque chose qui détienne le contenu. Un texte devient récupérable une fois découpé, vectorisé et indexé, et cet index est une base de données sur votre disque. Le serveur MCP ne garde aucun état : il ouvre une socket et fait passer des messages. S'il détenait votre dépôt à la place, vous auriez une seconde copie de votre code dans un processus où vous ne pouvez pas regarder. Aucune liste de ce qui est entré. Aucun moyen d'en ressortir une chose.

Il faut quelque chose qui récupère bien. Une simple recherche par similarité rend le passage qui ressemble à la question, qui n'est souvent pas celui qui y répond. Le moteur derrière la socket fait tourner un canal lexical et un canal vectoriel, et fusionne leurs classements. Ça demande un vrai index plutôt qu'une enveloppe autour d'un appel de vectorisation.

Il faut quelqu'un qui décide. Quels dossiers sont surveillés. Dans quel coffre ils atterrissent. Quels coffres un agent peut lire, et lesquels ne doivent jamais être mélangés au reste. Quel modèle répond. Ce sont des décisions sur votre propre matière, et un serveur sans écran devrait les prendre à votre place dans un fichier que vous éditez à l'aveugle.

Donc oui, une application de bureau. Ce qu'elle vous donne : chaque chronique entrée est visible, et retirable une par une. Elles vivent sur le même plateau que les cartes qui montrent ce que font vos agents.

Faire entrer votre matière​

Vos fichiers : code, notes d'architecture, décisions​

Vous déclarez un dossier, l'application le surveille, et ce qui y atterrit est ingéré dans le coffre que vous avez choisi. Rien n'est lu que vous n'ayez nommé.

C'est l'étape qu'on manque. Installer l'application donne des coffres vides, et c'est la déclaration du dossier qui les remplit. Voir Premiers pas et DocWatch.

Vos commits​

mnemosyne_git_log lit le dépôt au moment où vous l'appelez. Rien n'est ingéré et rien n'est stocké. L'historique que voit votre agent n'est jamais périmé ni dupliqué.

Ce que vos agents ont noté​

Leurs notes, les règles du projet, leurs fichiers de session : Connecter la mémoire de votre agent de code.

Ce qui va où​

Route par route, parce qu'une seule phrase sur la confidentialité serait fausse pour l'une d'elles.

  • Les coffres sont des fichiers sur votre disque, sous votre compte. Ils sont lus par l'application et par ce que vous branchez dessus.
  • Le serveur MCP ouvre une socket, 127.0.0.1:7799, et ne stocke rien. Il est sous licence MIT, donc vous pouvez lire exactement ce qu'il envoie.
  • Le modèle qui répond est celui que vous avez choisi. Un modèle local garde la question sur la machine. Un fournisseur cloud que vous avez configuré avec votre propre clé reçoit la question et les passages récupérés pour elle. C'est le même échange que n'importe quel autre appel d'API que vous faites.

Et ensuite​