Tesserae v0.7.2 — el descubrimiento y la compilación ya no se cuelgan

<!-- translations:start -->

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

<!-- translations:end -->

Publicado el 2026-06-12 · PyPI · GitHub release · pip install --upgrade tesserae==0.7.2

Una versión de corrección de errores que elimina tres formas en que Tesserae podía atascarse en máquinas con grandes historiales de sesiones de agentes: un descubrimiento de sesiones que nunca retornaba, subprocesos de agentes CLI que se quedaban colgados para siempre al expirar el tiempo, y compilaciones concurrentes que se apilaban sobre el mismo estado del proyecto.

1. tesserae sessions discover retorna — incluso con decenas de GB de historial

El descubrimiento solía analizar por completo el JSON de cada transcripción de todos los proyectos bajo cada raíz de cuenta antes de filtrar. En una máquina con ~57 GB de historial de Claude Code / Codex, eso significaba que el comando en la práctica nunca retornaba.

Tres correcciones que se multiplican entre sí:

• Prefiltro por marcador — una transcripción solo puede pertenecer al proyecto enfocado si la ruta del proyecto aparece literalmente en el archivo, así que las transcripciones ajenas ahora se criban con un escaneo de bytes en crudo (~50× más rápido que el análisis) antes de cualquier trabajo con JSON.
• Deduplicación de raíces con symlink — que ~/.claude apunte a ~/.claude-personal1 ya no hace que cada transcripción se escanee dos veces.
• Caché de escaneo basada en mtime — los resultados del cribado persisten en ~/.cache/tesserae/discovery_scan.sqlite (sobreescribible con TESSERAE_DISCOVERY_CACHE), de modo que las ejecuciones repetidas solo releen transcripciones nuevas o modificadas.

Medido en la máquina del problema: nunca retorna → 3 m 16 s en frío → 1 m 26 s en caliente, 4.048 sesiones encontradas. tesserae refresh y la importación de sesiones comparten la misma ruta y se aceleran por igual.

2. Los tiempos de espera de los agentes CLI ya no pueden colgar una compilación

Las llamadas a codex exec / claude -p usaban subprocess.run(capture_output=True, timeout=...), que al expirar el tiempo mata solo al hijo directo y luego drena las tuberías de salida sin tiempo límite. Los CLI de agentes generan sus propios hijos que heredan esas tuberías, así que un timeout podía dejar una compilación bloqueada al 0% de CPU indefinidamente (observado: ~2 días) detrás de nietos huérfanos.

Las llamadas a los CLI de LLM ahora se ejecutan en su propio grupo de procesos, y un timeout mata al grupo entero con un drenaje acotado — un timeout siempre significa muerto, nunca colgado.

3. Una compilación por proyecto a la vez

ProjectWiki.compile ahora mantiene un bloqueo exclusivo sobre .tesserae/compile.lock. Un refresh disparado por un hook mientras ya hay una compilación en marcha falla rápido con un mensaje claro que nombra el pid del poseedor, en lugar de apilarse silenciosamente sobre el mismo estado de .tesserae. Configura TESSERAE_COMPILE_LOCK_WAIT=<segundos> para esperar el bloqueo en su lugar. El bloqueo se basa en flock(2), así que una compilación que se cae nunca deja un bloqueo obsoleto.

4. tesserae --version

La ayuda raíz ahora comienza con la versión instalada, y tesserae --version (también -V / version) la imprime directamente.

Actualización desde v0.7.1

Reemplazo directo. Sin cambios de configuración. El primer sessions discover / refresh tras actualizar paga una pasada de cribado única para poblar la caché de escaneo; las ejecuciones posteriores son rápidas.