Base de connaissances des sessions

Cette page présente la « Base de connaissances des sessions », l’« Historique des synthèses » et les « Sessions archivées ». La gestion, la modification et l’importation de fichiers Markdown locaux sont traitées dans Bases de connaissances locales.

La base de connaissances des sessions conserve des connaissances, des décisions, des contraintes et des enseignements, organisés selon la hiérarchie projet → session → article. Les articles générés sont stockés séparément : ils ne changent pas lorsque leur session source change, et vous pouvez les modifier manuellement. La base de connaissances des sessions appartient au serveur VelaTerm auquel vous êtes connecté et est partagée entre ses projets et ses sessions ; lorsque vous vous connectez à un autre serveur, vous voyez la base de connaissances de ce serveur.

Elle est distincte de la recherche dans le contenu des sessions. La recherche dans les sessions trouve du texte dans les conversations d’origine, tandis que la base de connaissances ne recherche que dans les articles enregistrés. VelaTerm organise, stocke et affiche les articles lorsque vous le lui demandez ; il n’ajoute pas automatiquement d’articles aux nouvelles sessions.

Organisation d’une session

Cliquez avec le bouton droit sur une session dans la barre latérale ou sur son onglet, puis choisissez « Organiser dans la base de connaissances des sessions ». La même action est disponible pour les sessions archivées.
Choisissez l’« Agent » : Claude, Codex, Grok Build, OpenCode, Pi ou OMP. VelaTerm utilise le chemin de l’exécutable défini dans Paramètres ▸ Agents, ou recherche le programme dans le PATH. Un agent introuvable est signalé comme « Non installé ou non configuré » et ne peut pas être sélectionné.
Choisissez éventuellement un « Modèle (facultatif) » et un « Effort de réflexion ». « Modèle par défaut » et « Valeur par défaut de l’agent » laissent le choix à la configuration propre de l’agent. La liste des modèles est celle qui est utilisée lors de la création d’une session, et les niveaux d’effort n’apparaissent que pour les modèles qui en proposent. VelaTerm mémorise le dernier agent, le dernier modèle et le dernier effort utilisés. L’agent doit être connecté et avoir accès au modèle choisi.
Cliquez sur « Organiser et enregistrer ». L’agent sélectionné reçoit le texte de la session et le traite au moyen de sa propre configuration de modèle.
Suivez la tâche dans « Historique des synthèses ». La fermeture de la boîte de dialogue n’arrête pas la tâche.

VelaTerm lit l’historique de conversation de l’agent lorsqu’il est disponible. Sinon, il utilise l’enregistrement du terminal de la session (voir Utilisation du terminal), débarrassé des codes de contrôle du terminal. Lorsqu’aucun des deux n’est lisible, il signale « Aucune conversation lisible n’est disponible pour cette session. » Un enregistrement du terminal contient le texte visible à l’écran et peut inclure du contenu redessiné ; l’agent chargé de l’organisation ne doit donc pas considérer cette sortie comme un fait vérifié.

Un instantané source conserve le texte lu pour l’organisation. Les noms du projet et de la session sont enregistrés lors du premier ajout d’une session et ne sont pas mis à jour lorsque le projet ou la session est ensuite renommé, déplacé, archivé ou supprimé ailleurs.

Organiser de nouveau une session relit la session et remplace les articles générés précédemment à partir de celle-ci, y compris vos modifications manuelles ; cela se produit même lorsque le texte et les réglages du modèle n’ont pas changé. Si la session a déjà une tâche inachevée, la nouvelle tâche la remplace. Lorsque l’ancienne tâche est déjà en cours d’exécution, la nouvelle démarre automatiquement après l’arrêt de l’ancien processus (« Cette tâche démarrera automatiquement une fois la tâche précédente de cette session arrêtée. ») ; l’ancienne tâche reste dans l’historique.

Fonctionnement de l’organisation

L’organisation comporte trois étapes, qui s’affichent comme progression de la tâche :

Extraction des thèmes : la session est lue par sections, et les connaissances réutilisables en sont extraites. Les thèmes ne sont fusionnés qu’au sein de cette tâche ; les articles d’autres sessions et les modifications manuelles antérieures ne sont pas utilisés.
Fusion des connaissances : les contributions relatives à chaque thème sont combinées, en conservant les connaissances, les contraintes et les incertitudes. L’agent a pour consigne de tenir compte des corrections et des contradictions ultérieures et de ne pas inventer de conclusions.
Enregistrement des articles : VelaTerm vérifie les champs, les sources, les liens et les versions, puis remplace les articles générés de la session en une seule transaction de base de données. Un article portant le même titre conserve son identité et reçoit une nouvelle révision. Les articles qui ne sont plus générés sont supprimés avec leur historique des révisions, et les liens qui pointent vers eux sont retirés. Lorsque l’organisation réussit sans rien trouver de réutilisable, les anciens articles générés de la session sont effacés (« Aucune connaissance réutilisable n’a été extraite. Les entrées précédemment générées pour cette session ont été supprimées. »). Un échec de vérification, une annulation ou un conflit de versions laisse les articles précédents inchangés, et aucun résultat partiel n’est enregistré.

L’agent renvoie un contenu structuré, et VelaTerm effectue toutes les modifications de la base de données. Les articles sont liés entre eux, et les listes « Liens vers cet article » sont calculées automatiquement. Les instantanés source et l’historique des révisions restent disponibles même si la session d’origine est supprimée.

La qualité des connaissances organisées reste soumise à votre jugement. Si une information est erronée, modifiez l’article ou restaurez une révision antérieure ; la restauration crée une nouvelle révision et conserve la version remplacée.

Historique des synthèses

« Historique des synthèses » répertorie les tâches d’organisation, à raison de 40 par page. Chaque tâche indique l’agent, le modèle (« Modèle par défaut » si aucun n’a été choisi), l’effort de réflexion et l’heure ; une tâche en cours indique aussi son étape actuelle (« Extraction des thèmes », « Fusion des connaissances » ou « Enregistrement des articles »). L’état d’une tâche est « En attente de démarrage », « En cours », « Annulation en cours », « Terminé », « Échec » ou « Annulé », et son « Instantané source » ainsi que les articles qui en résultent peuvent être ouverts depuis la liste.

« Annuler » arrête une tâche en attente ou en cours. Une tâche en cours affiche « Annulation en cours » jusqu’à l’arrêt du processus de l’agent. L’annulation ne supprime pas l’instantané source.
« Réessayer » relance une tâche échouée ou annulée avec le même instantané source, le même modèle et le même effort de réflexion. L’historique affiche les réglages avec lesquels la tâche a été créée ; un choix par défaut signifie que l’agent a décidé, et non que VelaTerm a déterminé un modèle précis.

Plusieurs sessions peuvent être organisées en parallèle. Chaque session exécute une tâche à la fois, et une nouvelle soumission ne conserve que la tâche en attente la plus récente au lieu de constituer une file d’attente. Les tâches en attente sont enregistrées dans la base de données et reprennent après un redémarrage de l’application. Une tâche en cours qui n’a signalé aucune progression pendant deux minutes est marquée comme interrompue (« La synthèse a été interrompue. Réessayez à partir de l’instantané source enregistré. »). Le temps d’attente n’est pas pris en compte dans la limite de durée de la tâche.

Vous pouvez modifier des articles pendant une organisation. Si quelqu’un modifie ou supprime les articles générés de la session pendant une tâche, celle-ci signale un conflit de versions, vos modifications sont conservées, et vous pouvez réessayer ensuite. Plusieurs sessions peuvent utiliser le même titre d’article ; les titres doivent être uniques au sein d’une même session.

Consultation et gestion des articles

Ouvrez la base de connaissances depuis le panneau de droite (voir Bases de connaissances locales) et dépliez « Base de connaissances des sessions » par projet, session et article. Cliquez sur un projet ou une session pour afficher la liste de ses articles, et sur un article pour le lire. Le bouton « Remonter d’un niveau » ramène à la page parente.

La page de liste propose une recherche (« Rechercher dans les titres et le contenu… »), un filtre par étiquette (« Toutes les étiquettes »), un tri par « Mise à jour récente » ou « Titre », et l’actualisation. La recherche porte sur les titres, les résumés, les corps et les étiquettes, accepte plusieurs mots (tous doivent correspondre) et classe en premier les correspondances dans le titre ; chaque résultat indique aussi ses articles directement liés. En l’absence de correspondance exacte, des correspondances approximatives sont affichées, comme dans la recherche des bases de connaissances locales.
Les articles d’une session sont affichés à raison de 40 par page ; les listes de projets et de sessions ne sont pas tronquées par cette limite, et les longues listes de l’arborescence proposent « Charger la suite ».
La page d’un article affiche le corps Markdown, « Articles associés », « Liens vers cet article », « Sources » et « Historique des révisions ». Vous pouvez modifier le corps directement et l’enregistrer avec ⌘S / Ctrl+S, « Modifier » le titre, le résumé et les étiquettes, « Exporter en Markdown », « Copier dans un carnet local » ou « Supprimer ». La suppression d’un article supprime aussi son historique des révisions, mais conserve la session source et ses instantanés.
« Nouvel article » crée un article manuellement ; ces articles apparaissent dans le groupe « Création manuelle ».

L’arborescence permet aussi des actions de gestion :

Cliquez avec le bouton droit sur un article pour le renommer ou le supprimer ; faites-le glisser sur une autre session pour le réattribuer.
Cliquez avec le bouton droit sur le groupe d’un projet ou d’une session pour le renommer ou supprimer ses articles. Renommer un groupe renomme aussi le projet ou la session réels. La suppression d’un groupe ne retire que ses articles de connaissance : « Supprimer les N articles de connaissance de ce groupe ? Le projet ou la session est conservé. »
Faire glisser une session sur un autre projet déplace la session réelle vers ce projet.
Les groupes « Création manuelle », « Entrées fusionnées précédemment » et « Projet source inconnu » ne peuvent pas être renommés.

Les pages d’article, les formulaires de modification, les instantanés source, les révisions, la boîte de dialogue d’organisation et l’historique des synthèses disposent tous de leur propre URL, et le projet, la session, la recherche, le filtre, le tri et la page sélectionnés font partie de l’URL.

Sessions archivées

Les sessions archivées sont gérées dans la base de connaissances. « Sessions archivées » apparaît dans l’arborescence de la base de connaissances à côté de la « Base de connaissances des sessions » et regroupe les sessions archivées selon leur projet d’origine ; le bouton « Sessions archivées » de l’en-tête de la barre latérale ouvre le même emplacement.

La zone principale répertorie toutes les sessions archivées par projet. Une session ouverte comporte deux onglets : « Conversation » affiche la conversation complète, et « Articles de connaissance » affiche les articles générés à partir de celle-ci.
« Rechercher dans les archives… » porte uniquement sur le texte intégral des sessions archivées et regroupe les correspondances par session.
Une session archivée ouverte propose « Restaurer en session normale », « Organiser dans la base de connaissances des sessions », « Exporter le contexte complet en Markdown » (pour les sessions Claude et Codex) et « Supprimer définitivement (avec l’enregistrement) ». La suppression définitive prend effet immédiatement, sans étape de confirmation.
L’archivage, la restauration et la suppression d’une session ne modifient pas les articles de connaissance existants, car les articles et les instantanés source sont stockés séparément. Une session restaurée peut poursuivre sa conversation.

Données des versions précédentes

Lors de la mise à niveau des anciennes données, VelaTerm a attribué les articles ayant une seule session source à cette session. Les articles qui combinaient déjà plusieurs sessions ont été conservés intacts dans le groupe « Entrées fusionnées précédemment » ; ils ne sont pas scindés et ne sont jamais remplacés par une nouvelle organisation de l’une de ces sessions. Les articles sans source ont été placés dans « Création manuelle ». Les informations de projet encore disponibles ont été complétées une fois lors de la mise à niveau ; les sources dont le projet n’a pas pu être déterminé sont répertoriées sous « Projet source inconnu » avec leurs noms de session et leurs instantanés d’origine.

Données et limites

La base de connaissances des sessions est stockée dans la base de données SQLite de l’application (tables memory_*), séparément de l’index de recherche des sessions. L’interface ne conserve que ce qu’elle affiche et les saisies de formulaire non enregistrées ; la validation, les contrôles de version, la détection des doublons et toutes les écritures ont lieu sur le serveur.

Une source peut contenir jusqu’à 2 000 000 caractères, chaque section d’extraction jusqu’à 24 000 caractères, le texte transmis au modèle en un appel jusqu’à 350 000 caractères et le corps d’un article jusqu’à 200 000 caractères.
Chaque appel d’agent peut durer jusqu’à 10 minutes, et chacun de ses flux de sortie peut produire jusqu’à 8 Mio.
Pour OpenCode, Pi et OMP, le texte transmis en un seul appel est limité à 128 Kio.
Si un agent renvoie une sortie qui ne correspond pas à la structure attendue, VelaTerm la lui redemande, jusqu’à trois fois.

Tout dépassement de ces limites provoque un échec explicite (« La source, le contexte ou la sortie dépasse la taille prise en charge. Aucun contenu n’a été tronqué ni enregistré. ») ; rien n’est tronqué ni enregistré.

L’organisation est consignée dans logs/runtime-*.log, dans le répertoire de données de l’application. Lorsque VLX_LOG_DIR n’est pas défini, VLX_MEMORY_LOG_DIR définit le répertoire. VLX_MEMORY_LOG_LEVEL=error ne consigne que les erreurs, et off désactive le journal de ce module. Le journal enregistre les tâches et les étapes, le nombre d’entrées et de sorties, les durées, le nombre de caractères, les empreintes SHA-256 et les chiffres d’utilisation des jetons. Il n’enregistre jamais les invites complètes, le texte source, les réponses du modèle, les identifiants de connexion ni la sortie d’erreur ; les instantanés source conservent les données d’origine.

Liens avec le graphe du code

Les articles de connaissance peuvent être associés à des symboles du code, et « Références au code » sur la page d’un article mène au graphe du code. Lorsque le fichier associé change, l’article indique qu’il doit être vérifié ; la confirmation de la vérification ne modifie pas le texte de l’article. Les agents d’une session peuvent interroger le code et les articles avec vkb. Voir Graphe du code et base de connaissances.