Tesserae v0.28.3 — la limite d'un tour de l'extracteur, et ce qu'elle coûtait en silence

<!-- translations:start -->

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

<!-- translations:end -->

Released 2026-07-31 · PyPI · GitHub release · pip install --upgrade tesserae==0.28.3

Un seul drapeau. Il était dans l'extracteur Claude depuis le tout premier commit du pipeline et, sur une machine où des serveurs MCP sont configurés, il empêchait purement et simplement l'extraction par LLM de fonctionner — sans jamais faire échouer la compilation.

--max-turns 1 n'a jamais été une décision

Les deux points d'appel du CLI Claude lançaient :

claude -p --output-format text --max-turns 1

--max-turns compte les appels d'outils, pas les réponses. Si le répertoire de configuration du CLI contient des serveurs MCP ou des hooks, le premier geste du modèle peut être un appel d'outil — et l'unique tour est consommé. Le CLI sort alors en code 1 avec Reached max turns (1), sans avoir émis le moindre octet de JSON.

Tesserae intercepte cela et se replie sur l'extraction déterministe, car une panne de fournisseur ne doit jamais interrompre une compilation. La compilation réussissait donc, le graphe semblait plausible, et le LLM n'y avait rien apporté.

Ce drapeau n'a jamais été choisi. Il est arrivé avec le commit initial du pipeline, et ClaudeCLIJsonClient l'a recopié tel quel trois mois plus tard, parce que sa docstring indique qu'il « reprend le motif de run_claude_cli ». Aucun message de commit ne le mentionne.

--strict-mcp-config est ce que « un seul coup » veut réellement dire

L'intention derrière la limite était « réponds une fois, ne lance pas de boucle d'agent ». La bonne façon de l'exprimer est de ne charger aucun serveur MCP : il n'y a alors aucun outil sur lequel dépenser le tour.

claude -p --output-format text --strict-mcp-config

La première réponse du modèle est la réponse, et un serveur MCP configuré ne peut plus affamer l'appel. Les deux points d'appel sont corrigés, et un test de régression vérifie que la limite de tours ne revient dans aucun des deux.

Vérifiez si cela vous a coûté un graphe

L'échec est invisible dans le résumé de compilation — il ne vit que dans le journal :

grep -c 'Reached max turns' <votre journal de compilation>

Toute valeur supérieure à zéro signifie que ces fichiers ont été extraits de façon déterministe ; une recompilation sur cette version les récupère. Sur le graphe du projet lui-même, le rétablissement d'une vraie extraction LLM l'a fait passer de 5 155 à 13 182 nœuds — le repli déterministe coûtait environ 60 % du graphe.

Qu'une compilation annonce un succès tout en perdant l'extraction LLM sur la plupart de ses fichiers est un défaut distinct, suivi dans #92 et non corrigé ici. Cette version supprime une cause du repli silencieux, pas le silence lui-même.

Mise à niveau depuis la v0.28.2

Remplacement direct. Aucun changement d'API, de schéma ou de configuration. Si vos compilations précédentes ont été touchées, recompilez pour récupérer l'extraction manquante : les réponses LLM mises en cache dans ~/.tesserae/llm_cache sont réutilisées, seuls les fichiers qui s'étaient repliés ont donc un coût.