Tesserae v0.28.0 — hooks que no pueden gastar tu dinero accidentalmente

<!-- translations:start -->

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

<!-- translations:end -->

Lanzado 2026-07-27 · PyPI · GitHub release · pip install --upgrade tesserae==0.28.0

Actualiza por el primer punto. Es un error de gasto, y fue reproducido en una máquina real.

La trampa de $HOME

Una base de conocimiento en ~/.tesserae hace que $HOME parezca la raíz del proyecto. La función resolve_project_root() del plugin caminaba hacia arriba desde el directorio de trabajo hacia el primer .tesserae/ que encontraba — así que cualquier sesión iniciada fuera de un proyecto registrado se resolvía en $HOME, y el hook PostToolUse lanzaba tesserae compile --changed-only sobre todo el directorio de inicio.

15k archivos, un gráfico de 795 MB, aproximadamente 10 horas de gasto en LLM, desde un proceso setsid que sobrevivió a la sesión que lo generó. Se ejecutaba en cada Edit/Write.

El fallback lo empeoraba de lo que parece. Cuando no se encontraba .tesserae/, el resolver hacía esto:

echo "$PWD"
return 0

Afirmaba que cualquier directorio era un proyecto. Los llamadores luego probaban -d "$root/.tesserae" — que pasaba para cualquier directorio de trabajo bajo $HOME. Esa prueba fue la última línea de defensa y el fallback la atravesó directamente.

Ahora hay dos rechazos. $HOME nunca es una raíz de proyecto, por la ruta de caminata o por la ruta de raíz git. Y una falta de coincidencia devuelve vacío con un estado distinto de cero, así que los llamadores no-op en lugar de adivinar.

Los hooks que gastan son opt-in. TESSERAE_HOOK_AUTOCOMPILE=1 permite compilaciones automáticas; ausentes, no hacen nada. Aplicado solo a los dos que realmente gastan — posttooluse-edit.sh y session-end.sh. session-start.sh ejecuta code sync determinístico y pretooluse-compile.sh solo intercepta una compilación que escribiste, así que ninguno está puesto bajo control.

Un hook que lanza trabajo del modelo debe activarse deliberadamente, no desactivarse después de que llegue la factura.

El CLI de Python nunca tuvo este error: ProjectWiki.load() usa la ruta que se le da y no camina hacia arriba, así que un tesserae compile manual fuera de un proyecto falla limpiamente. La trampa solo estuvo en los hooks de shell.

OKF v0.2

Google's Open Knowledge Format v0.2 hace que la procedencia, confianza, ciclo de vida y atestación sean de primer nivel. Tesserae ahora emite v0.2 y aún consume v0.1.

Emitido: generated: {by, at} desde marcadores de extractor y agente; sources con las señales de credibilidad (usage_count de conteos de sesión, usage_window, last_modified, y author solo donde existe exactamente una persona authored_by); status: deprecated y stale_after derivados de aristas supersedes.

No emitido: verified, y por lo tanto sin nivel de confianza por encima de unverified. Tesserae no tiene un evento de verificación registrado con un actor y una marca de tiempo. Sus cuatro clases de procedencia son propiedades de arista — qué tan fuertemente el gráfico licencia un triple — mientras que la familia de confianza de OKF es un evento de verificación por concepto. Ejes diferentes; mapear uno al otro laundaría confianza a través de una especificación. Verificado sobre 5,193 conceptos reales: verified emitido 0 veces, generated.by afirma human: 0 veces.

Se corrigen tres errores del consumidor, todos encontrados importando la Apéndice A de la especificación literalmente a través del CLI real, donde anteriormente se bloqueaba: las marcas de tiempo YAML sin comillas se resuelven a datetime y rompieron la serialización; el fallback de timestamp de v0.1 no-opped silenciosamente en esa misma forma sin comillas; y el enlace relativo al bundle recomendado de §6.1 (/tables/customers.md) produjo cero aristas, así que un bundle que sigue la especificación se importó como nodos desconectados.

Un validador escrito a partir de las propias cláusulas de la especificación pasa una exportación de 5,193 conceptos con cero fallos, sin pérdida y byte-idénticamente.

Los veredictos tautológicos están nombrados

Aproximadamente el 40% de los veredictos SUPPORTED de verify_claim eran aristas evidenced_by cuyo intervalo citado es el destino de la propia arista — "C evidenced_by S", confirmado leyendo S. Verdadero, no informativo, e indistinguible anteriormente de un veredicto genuinamente respaldado por documento.

La carga ahora dice cuál es. En todos los 15,284 aristas: cada evidenced_by SUPPORTED marcado, nada más marcado, y ningún veredicto cambió valor de verdad. Aditivo, así que el contrato de siete veredictos de v0.27.0 está sin cambios.

Actualización desde v0.27.0

Drop-in para la biblioteca. Reinstala el plugin para obtener la corrección del hook, y si quieres compilaciones automáticas de nuevo, establece TESSERAE_HOOK_AUTOCOMPILE=1.

Si existe un .tesserae extraviado en $HOME desde una compilación accidental anterior, ahora es inerte — pero también es grande, y eliminarlo es seguro una vez que hayas confirmado que tu registro y configuración viven en otro lugar.