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, sa provenance, 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.
Ce que le store contient.
La projection vectorielle et la densité des tags, calculées depuis le store. Aucun graphe par tags partagés : deux entrées qui portent la même étiquette ne sont pas liées pour autant ; les liens réels vivent dans le graphe natif.
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.