Tesserae v0.4.0 — Boucle de rétroaction d'extraction, mode recherche, évolution activée par défaut

<!-- translations:start -->

English · 한국어 · 中文 · 日本語 · Русский · Español · Deutsch

<!-- translations:end -->

Publié le 2026-05-26 · PyPI · GitHub release · pip install --upgrade tesserae==0.4.0

Tesserae 0.4.0 transforme la base de connaissances en quelque chose que l'utilisateur peut corriger, faire croître et auquel se fier par défaut. La vedette est une boucle de rétroaction d'extraction : les corrections que l'utilisateur apporte dans le coffre Obsidian sont collectées comme des FeedbackEvent typés, regroupées en directives formulées par LLM, puis réinjectées dans l'extraction suivante, de sorte que le moteur cesse de refaire la même erreur. À ses côtés est livré le mode recherche (tesserae project research) — une boucle agentique de style dzhng planifier → chercher → réfléchir → synthétiser qui frappe des nœuds typés OpenQuestion / SessionHypothesis afin qu'un fil de recherche survive aux compilations. Deux passes d'évolution qui étaient optionnelles en v0.3.0 — les résumés de communauté et le linker prose-vers-code discusses — sont désormais activées par défaut, et le backend LLM reçoit un lot de corrections de robustesse (auto-découverte des identifiants ~/.claude*, gestion gracieuse quand le CLI Claude n'est pas connecté). Tout est additif, sans changement cassant.

Table des matières :

1. Boucle de rétroaction d'extraction (fonctionnalité E)
2. MD0 — mode recherche agentique (fonctionnalité G)
3. Évolution activée par défaut — communauté + liaison d'insights
4. Robustesse du backend LLM + fondations de la vue graphe
5. Migration depuis la v0.3.0
6. Contexte stratégique

1. Boucle de rétroaction d'extraction (fonctionnalité E)

Ce que c'est

Une boucle de correction fermée entre l'utilisateur et l'extracteur. Quand vous éditez le corps d'un nœud dans le coffre Obsidian — corriger un type erroné, supprimer un fait halluciné, reformuler un insight brouillé — la superposition de coffre de Tesserae enregistre l'édition comme un FeedbackEvent typé dans un magasin JSONL dédupliqué. Ces événements sont regroupés, un LLM formule chaque groupe en une courte directive d'extraction (avec un filtre négatif pour que le bruit ne devienne pas une règle), et cette directive est découpée et injectée dans le prompt à la compilation suivante. L'effet net : une correction faite une fois cesse de récurrer, au lieu de devoir être réappliquée après chaque réextraction.

La boucle a quatre parties mobiles :

Comment l'utiliser

La boucle est branchée sur l'aller-retour normal du coffre. Éditez les nœuds dans Obsidian, lancez un obsidian-sync (ou la chaîne de rafraîchissement), et les corrections sont collectées automatiquement. À la prochaine tesserae project compile, les directives accumulées sont en jeu.

# 1. Éditez les corps de nœuds dans le coffre Obsidian (corrigez les types, élaguez les hallucinations)
# 2. Resynchronisez le coffre — les corrections sont collectées comme FeedbackEvents
tesserae project obsidian-sync

# 3. Recompilez — les directives regroupées sont injectées dans l'extraction
tesserae project compile

Quand l'activer

• Vous curez le coffre à la main et êtes las que la même erreur d'extraction réapparaisse après chaque compilation.
• Votre corpus a un phrasé spécifique au domaine que l'extracteur générique continue de mal typer — quelques corrections lui apprennent vos conventions.

Où elle se trouve

Implémentation centrale : tesserae/feedback/ (le modèle FeedbackEvent, le magasin JSONL, la construction/rendu/parsing/découpage des directives) et le chemin de collecte de la superposition de coffre. La spécification de conception et le plan TDD en 7 tâches ont été conçus avec Codex et fusionnés dans la PR #20.

Mises en garde

• L'extracteur de base déterministe n'honore encore les directives que via le chemin LLM ; avec le backend LLM éteint, les corrections sont enregistrées mais pas encore réinjectées. (Honorer les directives sur le chemin déterministe est suivi comme travail ultérieur.)
• Les directives sont cachées ; un changement important dans vos schémas de correction peut prendre une ou deux compilations avant d'être pleinement reflété à mesure que les clusters se reforment.

2. tesserae project research — mode recherche agentique (fonctionnalité G)

Ce que c'est

Une nouvelle sous-commande tesserae project research <query> qui exécute une boucle bornée en largeur/profondeur planifier → chercher → réfléchir → synthétiser contre le graphe compilé et écrit un rapport markdown cité dans .tesserae/research/<slug>.md. Elle est modelée sur le motif de recherche profonde de dzhng, mais ancrée dans votre propre base de connaissances plutôt que sur le web ouvert.

De façon cruciale, la boucle frappe des nœuds et arêtes typés au fil de l'eau, de sorte qu'une compilation ultérieure peut récupérer le fil de recherche :

• un OpenQuestion par sous-question (avec metadata.parent_question_id pour les suivis et des arêtes derived_from),
• un SessionHypothesis par hypothèse générée par le LLM, avec des arêtes references vers les id de nœuds de preuve sur lesquels elle s'est appuyée,
• et (lorsqu'un backend WebFetcher est branché) un SourceDocument par résultat web.

Tous les backends sont injectés via des Protocols, de sorte que la boucle est entièrement déterministe sous test et ne touche jamais le réseau à moins de brancher un fetcher.

Comment l'utiliser

tesserae project research "Comment notre pile de récupération classe-t-elle les candidats ?"
# → écrit .tesserae/research/...md et frappe des nœuds OpenQuestion / SessionHypothesis
#   récupérables à la compilation suivante

La recherche web est intentionnellement reportée en v1 : --no-web est un no-op compatible vers l'avant jusqu'à ce qu'un backend WebFetcher soit livré.

Quand l'activer

• Vous voulez une synthèse citée sur votre propre graphe, pas une recherche d'un seul nœud ni une réponse plate de ask.
• Vous voulez que les questions et hypothèses de recherche persistent comme nœuds de graphe pour que les sessions futures s'appuient dessus au lieu de redemander.

Où elle se trouve

Implémentation centrale : tesserae/research/ (réutilise LLMJsonClient, LLMWikiMCPServer.search_nodes, ResearchGraphBuilder et stable_id). Câblage CLI : le sous-parseur research dans tesserae/cli.py. Douze tests couvrent planifier/chercher/réfléchir/synthétiser, le câblage du graphe, le plafond max_iters et les replis en cas d'échec du planificateur/de la synthèse. Fusionné dans la PR #18.

Mises en garde

• v1 ne synthétise que sur le graphe local ; le niveau web est un no-op compatible vers l'avant jusqu'à ce qu'un backend fetcher atterrisse.
• Les écritures disque atomiques utilisent le motif PID + suffixe temporaire aléatoire de batch._write_manifest, de sorte que des exécutions de recherche concurrentes n'entrent pas en collision.

3. Évolution activée par défaut — communauté + liaison d'insights

Deux passes qui étaient optionnelles en v0.3.0 sont désormais activées par défaut, de sorte que le graphe prêt à l'emploi est plus riche sans flags supplémentaires :

• Résumés de communauté (PR #14) — la détection de communautés Louvain plus les résumés LLM s'exécutent désormais dans la compilation par défaut au lieu d'être derrière un flag. Le graphe livre des aperçus au niveau cluster par défaut.
• Linker prose-vers-code discusses (PR #13) — le linker insight-symbole de la fonctionnalité H de v0.3.0 (TESSERAE_INSIGHT_SYMBOL_LINK) est activé par défaut en v0.4.0, de sorte que les session findings sont liés aux symboles de code qu'ils mentionnent sans que vous ayez à définir la variable d'environnement. (Vous pouvez toujours le désactiver explicitement si votre corpus est surtout de la prose avec peu de discussion de code.)

L'intention est qu'une première compilation produise un graphe qui possède déjà des aperçus de communauté et des arêtes prose-vers-code, conforme à la mission « base qui s'améliore d'elle-même, prête à remettre aux agents » au lieu d'exiger de l'utilisateur qu'il découvre et bascule chaque passe.

4. Robustesse du backend LLM + fondations de la vue graphe

Un lot de corrections de fiabilité du backend LLM, plus une spécification pour la vue graphe à venir :

• Auto-découverte des identifiants ~/.claude* (PR #19) — le chemin LLM par défaut trouve désormais les identifiants Claude à travers les répertoires ~/.claude* et peuple l'environnement du backend par défaut, de sorte que la configuration initiale sur les machines multi-comptes est moins fastidieuse.
• « Claude CLI non connecté » avec grâce (PR #17) — quand le CLI Claude est installé mais non authentifié, Tesserae se dégrade proprement avec un message exploitable au lieu de planter en pleine compilation.
• Hook PostToolUse sync-code (PR #15) — complète le hook SessionStart sync-code de v0.3.0 pour que le graphe de code se rafraîchisse aussi après des éditions par outil au sein d'une session.
• Spécification de vue graphe v1 — la conception qui porte l'encodage HypePaper et un tiroir de nœud sur le site Tesserae a été conçue avec Codex et a atterri comme spécification + plan, préparant le travail de graphe visuel qui suit.

Migration depuis la v0.3.0

pip install --upgrade tesserae==0.4.0

C'est toute la mise à niveau — v0.4.0 est additif, sans changement cassant. Le seul changement de comportement à connaître est que les résumés de communauté et le linker prose-vers-code discusses s'exécutent désormais par défaut ; si vous comptiez auparavant sur leur désactivation, désactivez-les explicitement.

Nouvelle sous-commande CLI à intégrer à votre mémoire musculaire :

tesserae project research "<question>"   # planifier→chercher→réfléchir→synthétiser agentique sur votre graphe

Comportement désormais activé par défaut (auparavant optionnel) :

• Résumés de communauté (Louvain + LLM).
• Arêtes prose-vers-code discusses (la passe TESSERAE_INSIGHT_SYMBOL_LINK de v0.3.0).

Tout le reste — graph_ppr, search_nodes hybride, sync-code, le hook SessionStart en direct, embedding_status, fresh_insights, le scoring de décroissance, supersedes, schema-drift, les commandes slash, la projection wiki / Obsidian — reste inchangé depuis la v0.3.0.

Contexte stratégique

v0.3.0 a connecté les décisions en prose aux symboles de code qui les implémentent. v0.4.0 est la version où la base commence à se corriger et à croître d'elle-même : la boucle de rétroaction d'extraction comble l'écart entre « l'utilisateur l'a corrigé une fois » et « l'extracteur l'a appris », et le mode recherche laisse l'agent faire croître le graphe avec ses propres questions et hypothèses typées au lieu de seulement ingérer ce qui existe déjà. Activer par défaut les résumés de communauté et le linker discusses est le même thème côté produit — le moteur devrait remettre aux agents une base riche sans obliger l'utilisateur à chasser des flags.

C'est la version pont. v0.3.0 a prouvé le graphe typé prose-vers-code ; v0.5.0 transforme l'ensemble en un moteur en exécution continue avec un compilateur de contexte à la demande. v0.4.0 est l'endroit où le pilier d'auto-amélioration obtient sa première vraie surface (corrections de rétroaction, fils de recherche agentiques) en amont de la colonne vertébrale de v0.5.0 qui fait tourner tout cela en continu.

Voir aussi :

• Notes de version v0.3.0 — liens prose-vers-code, graphe de code polyglotte, synchronisation en direct
• Feuille de route du moteur de contexte — le plan par phases que livre v0.5.0
• Audit du moteur de contexte — l'analyse des écarts que ces versions comblent
• Aperçu de l'architecture — carte des modules et pipeline
• Intégration MCP — liste complète des outils MCP