La mémoire, inspectable.
La mémoire de Grimoire est une base de connaissances — … entrées : décisions, learnings, contradictions, failures, handoffs. Cette page est un Obsidian pour la mémoire agentique : on voit le contenu, ses liens, son graphe, sa santé et le backend en place. Réelle en local, snapshot démo sur la vitrine. La mémoire est inspectable et vérifiable — pas une boîte noire.
Ce que contient la mémoire.
Backend détecté, extras installés, topologie du Memory OS et répartition des entrées par type. La couche sémantique nous appartient ; l'admin brut du moteur reste aux consoles natives.
Les backends absents sont masqués des consoles.
« mémoires » est le type de base : les 141 entrées au total. Learnings, failures, contradictions et decisions en sont les sous-types gouvernés.
Comment les souvenirs se lient.
Chaque entrée est un nœud ; les arêtes sont les tags partagés — réelles, calculées depuis le store. Survolez un nœud pour isoler son voisinage, cliquez pour l'ouvrir dans le vault.
DÉMO — sans embeddings. Le store n'a pas encore de vecteurs extraits ; ces points sont factices. À remplacer par un UMAP / t-SNE sur embeddings réels.
pour voir son détail, ses tags et ses liens.
Vérifier, rediriger, gouverner.
memory-lint expose drift, doublons et contradictions non résolues. Pour l'admin brut du moteur, on redirige vers les consoles natives. Le pilotage (édition, infra) reste au cockpit local.
On possède la couche sémantique (browse, lien, graphe, recherche). On redirige vers les consoles natives pour l'admin brut — Redis étant un pur cache, redirection seule. Seuls les backends détectés sont actifs.
Toute écriture passera par l'API Memory OS — jamais de SQL ni d'accès brut — localhost uniquement, jamais sur la vitrine. Cette page détecte son mode et masque toute action hors cockpit local. C'est le hook du lot suivant.