Archivos que ralentizan a un asistente

A un asistente le cuesta más trabajar en algunos archivos que en otros, y por lo general la causa no es el código en sí. Una ruta en tu documentación que cambió de lugar. Un archivo generado que no se puede editar de forma segura. Un directorio que requiere un permiso que el agente no tiene. Más o menos ya sabes cuáles son esos archivos, porque te han dado dolores de cabeza. Pathrule lo registra con precisión.

Qué se registra

Cuando falla una herramienta que llama un asistente, se almacenan tres cosas: el tipo de herramienta, el archivo en el que estaba trabajando y un código corto que indica cómo falló. file_not_found, permission_denied, timeout, rate_limit, token_limit, syntax_error, o unknown cuando el fallo es real pero nada lo reconoce.

Ese es todo el registro. No el comando. No el mensaje de error. No el archivo. Un conteo y un código, asociados a una ruta. En un espacio de trabajo de Cloud, estos conteos y códigos se almacenan junto con el espacio de trabajo en Pathrule Cloud.

El fallo se observa, no se informa. El hook de herramientas de Pathrule vigila la llamada en sí, así que el conteo no depende de que el asistente note su propio error, recuerde una sesión o llame a algo después. Un asistente que falla en silencio y sigue adelante queda registrado exactamente igual que uno que lo anuncia. La duración de la llamada forma parte de la misma observación, y eso es lo que permite distinguir un comando que se colgó de uno que fue rechazado. Esto aplica a los clientes en los que Pathrule tiene hooks de herramientas: Claude Code, Codex, Cursor y GitHub Copilot. Windsurf no tiene hooks de Pathrule, así que sus llamadas a herramientas no se observan de esta forma.

Primero, la ruta se normaliza a una forma relativa al espacio de trabajo, algo más importante de lo que parece. En una laptop, una ruta absoluta es /Users/<name>/…, y ese nombre no tiene por qué viajar al conocimiento compartido. Las rutas relativas también hacen que el mismo archivo se agrupe correctamente en todo un equipo, en lugar de una vez por máquina.

Para qué se usa

Una imagen de dónde se atasca el trabajo. Con el tiempo, los fallos se agrupan por archivo, herramienta y código. El resultado es una lista corta más que un gráfico: los archivos en los que un asistente falla más, y cómo. Un archivo que aparece una y otra vez con file_not_found suele indicar una ruta desactualizada en algún lugar de tus propias instrucciones. Uno con syntax_error suele ser un archivo que realmente es difícil de editar. Uno con permission_denied suele ser un problema de configuración que puedes resolver una sola vez.

Aprendizaje de recuperación. Si un turno recibió conocimiento de Pathrule y aun así tuvo fallos, ese conocimiento recibe una señal negativa, y algunos tipos de fallo cuentan más que un error común porque suelen indicar que la guía mandó al asistente a un lugar al que no podía ir. La señal se suma al ciclo descrito en cómo la recuperación encuentra el conocimiento correcto. El conocimiento que sigue apareciendo en turnos que salen mal se vuelve gradualmente menos probable de ser elegido, sin que nadie tenga que revisarlo.

Qué no puede ver la señal

Esta parte depende del asistente que uses, y no es uniforme.

Las herramientas de archivos informan los fallos correctamente. Una lectura, edición o escritura que falla llega con su mensaje, se clasifica y queda asociada al archivo correcto. Ese es el caso que importa, porque la ruta del archivo es lo que hace que un conteo sea útil para actuar.

Los comandos de shell muchas veces no. Algunos asistentes no informan ningún código de salida, así que un comando que falla y uno que tiene éxito llegan con el mismo aspecto. Pathrule no infiere un fallo a partir del texto de salida: un resultado de búsqueda puede contener legítimamente las palabras "no such file or directory", y un fallo equivocado asociado a un archivo es peor que uno que falta. Cuando el asistente no informa un fallo, no se registra nada, y cuando informa uno que ninguna regla reconoce, el código es unknown en lugar de una suposición.

Qué no hace

Registrar un fallo no bloquea una llamada a una herramienta ni aparece en el contexto del asistente. Un fallo es un hecho sobre tu código, registrado después de que ocurre. No cambia lo que el asistente tiene permitido hacer, y un archivo con un mal historial no se considera vedado. Nada de esto es una calificación asociada a una persona: el registro trata sobre archivos, no sobre quién trabajaba en ellos.