Tesserae v0.28.3 — el límite de un turno del extractor y lo que costó en silencio

<!-- translations:start -->

English · 한국어 · 中文 · 日本語 · Русский · Français · Deutsch

<!-- translations:end -->

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

Una sola bandera. Llevaba en el extractor de Claude desde el primer commit del pipeline y, en una máquina con servidores MCP configurados, impedía por completo que la extracción por LLM funcionara — sin hacer fallar la compilación.

--max-turns 1 nunca fue una decisión

Ambos puntos de llamada al CLI de Claude ejecutaban:

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

--max-turns cuenta llamadas a herramientas, no respuestas. Si el directorio de configuración del CLI tiene servidores MCP o hooks, el primer movimiento del modelo puede ser una llamada a herramienta, y ahí se agota el único turno. El CLI termina con código 1 y Reached max turns (1) sin emitir un solo byte de JSON.

Tesserae captura eso y recurre a la extracción determinista, porque un fallo del proveedor nunca debería abortar una compilación. Así que la compilación tenía éxito, el grafo parecía plausible y el LLM no había aportado nada.

La bandera nunca se eligió. Llegó con el commit original del pipeline y ClaudeCLIJsonClient la copió literalmente tres meses después, porque su docstring dice que «replica el patrón de run_claude_cli». Ningún mensaje de commit la menciona.

--strict-mcp-config es lo que «una sola pasada» significa de verdad

La intención del límite era «responde una vez, no ejecutes un bucle de agente». La forma correcta de expresarlo es no cargar ningún servidor MCP, de modo que no haya herramienta en la que gastar el turno:

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

La primera respuesta del modelo es la respuesta, y un servidor MCP configurado ya no puede dejar la llamada sin turno. Ambos puntos de llamada están corregidos y un test de regresión afirma que el límite de turnos no vuelve a ninguno de los dos.

Comprueba si esto te costó un grafo

El fallo es invisible en el resumen de la compilación: solo vive en el log:

grep -c 'Reached max turns' <tu log de compilación>

Cualquier valor por encima de cero significa que esos archivos se extrajeron de forma determinista, y recompilar con esta versión los recupera. En el grafo del propio proyecto, restaurar la extracción real por LLM lo llevó de 5.155 nodos a 13.182 — el repliegue determinista venía costando alrededor del 60% del grafo.

Que la compilación informe éxito mientras pierde la extracción por LLM en la mayoría de sus archivos es un defecto aparte, registrado en #92 y no corregido aquí. Esta versión elimina una causa del repliegue silencioso, no el silencio.

Actualizar desde v0.28.2

Sustitución directa. Sin cambios de API, esquema ni configuración. Si tus compilaciones anteriores se vieron afectadas, recompila para recuperar la extracción que faltaba: las respuestas del LLM cacheadas en ~/.tesserae/llm_cache se reutilizan, así que solo cuestan los archivos que se replegaron.