Lo que registra una sesión de IA

La mayor parte de lo que Pathrule aprende sobre tu proyecto lo aprende del trabajo, no de lo que se escribe. Cuando una sesión de IA termina un trabajo, registra una entrada breve y estructurada, y esa única entrada es la base sobre la que se construyen varias otras funciones.

Esta página explica qué contiene esa entrada, qué se deja fuera a propósito y qué funciones alimenta después.

Qué se registra

Cada entrada tiene unos pocos campos, todos pequeños:

• Área, acción y alcance. Qué tipo de cosa se tocó (ui, backend, database, infra, config, test, docs), qué se le hizo (create, update, fix, refactor, delete, style) y a qué nivel (un componente, una página, una API, una migración, un servicio).
• Temas. Hasta cinco palabras clave en minúsculas, como etiquetarías el trabajo en una conversación.
• Un resumen de una sola oración. Qué cambió y por qué, en una línea.
• Las rutas que tocó, agrupadas por área.
• En qué cliente de IA se ejecutó la sesión, y cuándo.
• Cómo fue el turno: cuántas llamadas a herramientas hizo, cuántas fallaron y un código corto para cada tipo de fallo (timeout, exit_nonzero, not_found y similares). Solo conteos y códigos, nunca el comando ni el texto del error.

Ese es el registro completo. Está pensado para leerse de un vistazo meses después, y por eso también se mantiene breve. La vista Recent Activity de Pathrule para VS Code muestra las entradas más recientes del espacio de trabajo.

El asistente escribe la oración. Pathrule adjunta la medición. El resumen, el área y las rutas vienen de la sesión que hizo el trabajo, mientras que el conteo de llamadas a herramientas, los fallos y cuáles de las entradas entregadas se consultaron realmente los observa la capa que las entregó. Esa división importa: un asistente puede olvidarse de mencionar que fallaron cuatro comandos, y el conteo queda registrado de todos modos.

Qué nunca se registra

Tu código no está ahí. Ni contenido de archivos, ni diffs, ni parches, ni mensajes de commit, ni texto de prompts. Las rutas están para que las funciones posteriores puedan saber dónde ocurrió el trabajo; el contenido del cambio no se guarda.

Además, las rutas se normalizan antes de guardarse. Una ruta llega tal como la vio el agente en esa máquina y se convierte a su forma relativa al espacio de trabajo, así que /Users/you/projects/app/src/api.ts pasa a ser src/api.ts. Nada propio de una máquina llega al conocimiento compartido del equipo, y el mismo archivo es el mismo archivo sin importar quién lo haya tocado.

Qué alimenta una entrada

Lo que hace que valga la pena conservar el registro es quién lo lee:

• Episodios de trabajo. Las entradas relacionadas de una misma sesión de trabajo se agrupan en un registro con título de algo que tu equipo resolvió, que una sesión posterior puede recuperar.
• Archivos que cambian juntos. Las rutas de cada entrada son lo que le enseña a Pathrule qué archivos van en pareja.
• Aprendizaje de recuperación. Cuando se le presentó conocimiento a un agente y luego el agente trabajó en esa misma área, eso es evidencia de que el conocimiento era relevante. Con el tiempo esto ajusta la prioridad, como se describe en cómo funciona la recuperación.

Ninguna de ellas requiere un paso adicional de tu parte. Todas salen de la misma entrada breve.

El registro nunca bloquea el trabajo

Vale la pena destacar una decisión de diseño deliberada, porque se nota en cómo se comporta la herramienta. El registro nunca falla por tamaño. Si un resumen es demasiado largo o una tarea tocó decenas de archivos, la entrada se recorta en el servidor y se guarda, en lugar de rechazarse.

Rechazarla sería peor que recortarla. Un agente que recibe un error de validación lo interpreta como "corrige los argumentos y vuelve a intentarlo", y dedica los siguientes turnos a reescribir un resumen en vez de terminar tu tarea. Por eso los límites se aplican de forma silenciosa, al recibir la entrada, y la respuesta le indica al agente qué se guardó.

Para qué se usan los conteos de fallos

Los conteos de llamadas a herramientas y de fallos son la forma en que Pathrule responde "¿en qué archivos de este código le cuesta más trabajo a un asistente?" a partir del trabajo real y no de opiniones. Hay dos cosas que los leen.

La primera es una agrupación semanal. Cada fallo se registra como una terna: el tipo de herramienta, el archivo en el que trabajaba y un código corto que indica cómo falló. Agrupado por semana, eso se convierte en una lista sencilla de los archivos en los que un asistente falla con más frecuencia y qué tipo de fallo encuentra ahí. Un archivo que aparece una y otra vez bajo file_not_found suele ser una ruta desactualizada en tu propia documentación o un módulo que se movió sin que nadie actualizara las referencias. Uno bajo syntax_error suele ser un archivo difícil de editar de forma segura.

La segunda es el aprendizaje de recuperación. Si un turno recibió conocimiento de Pathrule y aun así tuvo fallos de herramientas, eso cuenta en contra del conocimiento que se le dio. Esa señal se suma al mismo ciclo de aprendizaje descrito en qué hace que el conocimiento tenga mayor prioridad, de modo que el conocimiento que sigue apareciendo en turnos que salen mal deja de elegirse poco a poco.

Qué puede ver y qué no un conteo de fallos

Esto depende del asistente que uses, y la respuesta honesta no es la misma para todos.

Las herramientas de archivos informan correctamente. Una lectura, edición o escritura fallida llega con su mensaje, así que se clasifica y se atribuye al archivo correcto. Ese es el caso que vale la pena tener, porque la ruta del archivo es lo que permite actuar sobre el número.

El código de salida de la shell, en cambio, muchas veces no llega. Algunos asistentes no informan en absoluto un código de salida distinto de cero: un comando que falla y uno que tiene éxito llegan exactamente iguales. Pathrule no adivina. Registra lo que el asistente realmente informó y clasifica el resto como desconocido en lugar de inventar un fallo, porque un fallo incorrecto atribuido a un archivo es peor que uno que falta.

Acceso y alcance

Las entradas se guardan en el espacio de trabajo en el que se registraron, detrás del mismo control de acceso por usuario que las memorias, las reglas y las skills. Un compañero de equipo ve la actividad de los espacios de trabajo que ya puede ver, y nada más. Las entradas más antiguas se eliminan según un calendario en lugar de acumularse para siempre.