Code du systeme de memoire multi-LLM sur Trilium : - trilium_api.py : wrapper trilium-py (notes, labels, relations) - mcp_server.py : serveur MCP Starlette (19 tools, OAuth + Bearer) - api_context.py : API REST FastAPI - trilium_context.py : workflow CLI - watchdog.sh, start_*.sh : supervision et demarrage - skills, docs et ontologie associes Secrets (.env, oauth_state.json) exclus via .gitignore.
5.4 KiB
SKILL — Réflexe de continuité Trilium
Skill universel de mémoire de projet. Décrit quand lire le contexte et quand capitaliser proactivement dans Trilium au fil d'une session. Orienté comportement — le « comment » technique est dans le skill de référence API Trilium.
Réutilisable pour tout projet suivi dans le système Context Continuity (Trilium comme base pivot, partagée entre Claude et Le Chat).
Le principe
Trilium est la mémoire longue du projet, partagée entre LLMs. Une conversation ne doit jamais être la seule détentrice d'une décision ou d'un fait : tout ce qui compte est capitalisé dans Trilium au fil de l'eau, pour qu'une nouvelle conversation (même sur un autre LLM) puisse reprendre sans perte.
L'agent ne se contente pas de répondre : il tient la mémoire à jour proactivement aux moments clés, et lit le contexte en début de session.
Deux chemins d'accès selon le LLM
Côté Le Chat (Mistral) : accès natif via MCP. Les tools
(get_contexte, add_decision, add_history, etc.) sont appelés directement
par l'agent.
Côté Claude : le connecteur MCP n'est pas disponible (le serveur n'implémente pas OAuth, requis par Claude). L'accès se fait donc par relais humain : l'agent propose à Bastien la commande exacte à lancer, Bastien l'exécute sur GrosseBertha et colle le retour. C'est transparent côté comportement — seul le mécanisme diffère.
Quand l'OAuth sera ajouté au serveur MCP, Claude pourra accéder directement et ce relais deviendra inutile.
EN DÉBUT DE SESSION — lire le contexte
Au démarrage d'une session sur un projet existant, récupérer le briefing de reprise avant de travailler :
- Le Chat : appeler le tool
get_contexte(projet="SlidingAutomation", llm_cible="Le Chat Large"). - Claude : proposer à Bastien :
puis lire le briefing qu'il colle.
python trilium_context.py generate-context --projet SlidingAutomation --llm-cible "Claude Sonnet" --note-id <ID_DERNIERE_CONV> --version <N>
Le briefing contient : décisions actives, historique valide, glossaire, backlog actif. Confirmer en 3 lignes : (a) objectif, (b) prochaine action, (c) incertitude — avant de continuer.
Optionnel mais recommandé : créer la note de conversation dès le début
(new_conversation) pour pouvoir la clôturer ensuite.
PENDANT LA SESSION — capitaliser aux moments clés
L'agent surveille activement ces déclencheurs et propose la capitalisation sans attendre la fin :
Déclencheur : une décision est actée
Dès qu'un choix technique ou architectural est tranché (« on fait X plutôt que Y ») :
- Le Chat :
add_decision(projet, enonce, justification) - Claude : proposer
python trilium_context.py add-decision --projet SlidingAutomation --enonce "Énoncé court et actionnable" --justification "Pourquoi ce choix"
Déclencheur : un test est effectué ou une contrainte découverte
Dès qu'un test valide/invalide quelque chose, ou qu'une limite est rencontrée :
- Le Chat :
add_history(projet, enonce, type_historique, detail) - Claude : proposer
python trilium_context.py add-history --projet SlidingAutomation --type "Test effectue" --enonce "Ce qui a été testé" --detail "Résultat observé"
type_historique ∈ { Fait etabli, Test effectue, Hypothese invalidee,
Contrainte decouverte } (sans accent, exactement ces libellés).
Déclencheur : une tâche future émerge
Dès qu'un « il faudra faire X » apparaît :
- Le Chat :
add_backlog(projet, titre, priorite) - Claude : proposer la commande équivalente.
priorite∈ {haute,moyenne,basse}.
Déclencheur : une tâche change d'état
Quand un item passe en cours / fait / bloqué : update_backlog(note_id, statut).
statut ∈ { a faire, en cours, bloque, fait, abandonne }.
EN FIN DE SESSION — clôturer
Quand Bastien signale que la limite de tokens approche (l'agent se répète, oublie une contrainte, perd en précision), produire une synthèse de clôture de 150-200 mots, format concis sans markdown complexe :
Synthèse de clôture :
- Objectif de la session : ...
- Accompli : ...
- En cours : ...
- Bloqué : ...
- Prochaine action : ...
Puis l'enregistrer :
- Le Chat :
close_session(note_id, synthese) - Claude : proposer
python trilium_context.py close-session --note-id <ID_CONV> --summary "COLLE ICI LA SYNTHÈSE"
Enfin, générer le briefing de reprise (generate-context) pour la prochaine
session ou la bascule vers l'autre LLM.
Règles de capitalisation — à respecter strictement
Ces règles évitent que les filtres de Trilium ratent les notes :
- Nom de projet sans espaces :
SlidingAutomation, jamaisSliding Automation. - Valeurs de statut en minuscules :
actif,active,a faire— jamais de majuscule. encoreValide:true/falseen minuscules.typeHistorique: exactement un des 4 libellés sans accent.- Énoncés courts et actionnables — une ligne, pas un paragraphe.
Posture de l'agent
Capitaliser n'est pas optionnel ni réservé à la fin. L'agent propose l'enregistrement au moment où l'information naît, brièvement (« Je note cette décision dans Trilium ? » + la commande prête). Il n'attend pas que Bastien le demande. La mémoire du projet est une responsabilité continue, pas une corvée de clôture.