Où vont les souvenirs de Claude : Cortex, tracé dans son code

Deux portes d’entrée, un seul store

Rien n’entre dans Cortex sans passer par l’une de deux portes. Les hooks du plugin se déclenchent seuls, à des moments fixes de la session, et parlent directement à la couche infrastructure³. Les outils MCP (remember, recall, wiki_adr et les autres) passent par le serveur, où seuls les handlers ont le droit de réunir le cœur pur et l’infrastructure¹. Le cœur ne fait aucune entrée-sortie : les variables d’environnement, le cache du modèle de reranking et le système de fichiers du wiki lui arrivent par des points d’injection qui lèvent une erreur s’ils ne sont pas câblés, et une seule fonction les câble tous à chaque point d’entrée².

Ce que les hooks lisent et écrivent

Vous ne voyez qu’une partie du travail : le bloc « Cortex Memory Context » en tête de session⁵. Six autres hooks lisent ou écrivent sans rien demander. Un seul, decision_gate, ne touche pas la base : il refuse une édition qui ajoute un long commentaire en prose, parce que la prose de décision appartient au wiki⁶.

Un souvenir franchit un portail de nouveauté

Le stockage a un gardien : il retient ce qui contredit ses attentes. Quatre signaux de nouveauté sont pondérés, puis comparés à un seuil de 0,4⁸. Le portail filtre surtout la capture automatique : un remember délibéré, la classe par défaut, le contourne, comme les décisions, les erreurs et un tag important⁹. Une décision écrite délibérément sous un agent_topic, depuis une origine de confiance, est aussi marquée globale pour que toute l’équipe d’agents la voie ; une page téléchargée ou une capture automatique qui contient seulement un indice de décision ne l’est pas¹⁰.

Une ligne de la table memories

Une ligne porte bien plus que son texte. La colonne la plus trompeuse est la chaleur : aucune colonne heat n’est stockée. La base garde heat_base et l’heure où elle a été fixée ; la fonction SQL effective_heat() applique la décroissance à la lecture, et les lignes protégées ou ancrées y échappent¹¹.

Le rappel est aussi une écriture

Un recall cherche d’abord une identité exacte (ADR-0042, un id de souvenir), puis fusionne cinq signaux dans une seule fonction de la base¹⁷. Sous PostgreSQL, les signaux sont normalisés par leur maximum puis additionnés avec des poids propres à l’intention ; sous SQLite, la fusion se fait par rangs, w/(k + rang), sans le signal trigramme¹³. La complétion de Hopfield, la similarité hyperdimensionnelle et l’activation diffusante reclassent le résultat, puis un cross-encoder a le dernier mot¹⁴. Les souvenirs rendus ne sortent pas intacts : leur chaleur, leurs compteurs et les arêtes entre leurs entités changent au passage¹⁵.

Une décision a une identité : ADR-NNNN

L’identifiant d’une page wiki est le seul index des décisions. Le code ne garde qu’un pointeur, et le rappel résout ce pointeur avant toute recherche floue¹⁷. Une décision peut emprunter trois chemins ; chacun laisse une trace à un endroit différent et revient par un chemin différent¹⁶.

Quatre mémoires, côte à côte

Ce que Claude apprend pendant une session n’atterrit pas à un seul endroit. Claude Code a sa propre mémoire de fichiers, distincte de Cortex ; Cortex la lit pour le profil cognitif et ne la copie jamais dans le store¹⁸.