Lo que Pathrule calcula

Tú escribes tres tipos de cosas: memorias, reglas y skills. Esa parte es deliberada, curada y tuya.

También es la mitad más pequeña. La mayor parte de lo que guarda la capa en cualquier momento no la escribió nadie. Se deriva de cómo avanza realmente el trabajo, se mantiene por espacio de trabajo y se vuelve a calcular a medida que el trabajo continúa. Esta página nombra cada parte derivada, porque saber qué hay ahí explica por qué la recuperación se comporta como lo hace.

Una representación del significado de cada entrada

Cada memoria, regla y skill existe también como una representación calculada de lo que significa. Cuando llega una solicitud, se convierte en el mismo tipo de representación y se compara directamente con ellas.

Esta es la parte que hace funcionar la coincidencia entre idiomas. Un prompt en turco hace aparecer una memoria escrita en inglés cuando ambos comparten una idea y ni una sola palabra. La búsqueda por palabras clave no puede hacer eso, porque no hay ninguna cadena en común con la cual coincidir. La comparación ocurre en un espacio donde "the payment webhook retries twice" y "ödeme webhook'u iki kez deniyor" quedan cerca uno del otro.

Las entradas se vuelven a representar cuando cambia su contenido, de modo que la coincidencia refleja lo que la entrada dice ahora y no lo que decía cuando se creó.

Una ventana medida alrededor de cada entrega

Cuando Pathrule entrega conocimiento para un turno, abre un registro de esa entrega. Ese registro guarda qué entradas se enviaron, en qué ruta y para qué tipo de intención.

Después, el turno reporta de vuelta en esa misma ventana:

• cuáles de las entradas entregadas consultó realmente el asistente, frente a las que solo recibió
• cuántas llamadas a herramientas hizo el turno y cuántas fallaron
• qué archivos se editaron, en forma relativa al espacio de trabajo
• cómo se distribuyeron los fallos, como códigos breves y no como texto de error

Esa ventana es la materia prima de todo lo que viene después. También es la razón por la que Pathrule puede distinguir un turno que salió bien de uno que salió mal sin que nadie califique nada.

Pesos aprendidos, por tipo de trabajo

Las ventanas se acumulan. Con el tiempo, cada entrada tiene una posición para cada tipo de trabajo en el que se ha entregado, y esa posición se mueve con la evidencia: sube cuando la entrada se consultó en un trabajo que salió limpio y baja cuando se entregó en un turno que tuvo dificultades.

La consecuencia es que la prioridad no es un único número por entrada. La misma memoria puede tener prioridad alta para una migración y baja para un ajuste de interfaz, porque son tipos de trabajo distintos y la evidencia es distinta. Un único campo de "importancia" en un archivo no puede expresar eso, y una persona que lo mantuviera a mano tendría que adivinarlo.

El aprendizaje es conservador a propósito. Un resultado ambiguo no enseña nada en lugar de enseñar algo equivocado, un solo fallo claro baja la posición en lugar de borrar el historial, y la influencia se desvanece a medida que el código se aleja. Cómo la recuperación encuentra el conocimiento correcto explica ese comportamiento en detalle.

Un grafo de archivos que cambian juntos

A partir de las rutas que reportan los turnos, Pathrule arma una imagen de qué archivos suele cambiar tu equipo en el mismo trabajo. Así, el conocimiento vinculado a uno de esos archivos puede llegar a una sesión que trabaja en su vecino.

Nadie declara estas relaciones y no se abre ningún archivo para encontrarlas. Surgen del trabajo registrado, tienen un umbral de ruido para que una sola coincidencia no cuente y pierden peso cuando el emparejamiento deja de ocurrir. En un espacio de trabajo de Cloud, el grafo además arranca con ventaja: la primera vez que un agente pide contexto profundo, se inicializa con las rutas de archivos del historial reciente de git, así que es útil antes de que tu equipo haya registrado mucho trabajo. Consulta archivos que cambian juntos.

Un mapa de fricción

Los fallos se agrupan en un trío: el tipo de herramienta, el archivo y un código breve sobre cómo falló. Agrupado por semana, eso se convierte en una imagen de dónde y cómo se atasca una y otra vez un asistente en tu código, y alimenta la prioridad como señal negativa cuando un turno que recibió conocimiento igual tuvo problemas. Consulta archivos que ralentizan a un asistente.

Una medida de si el enrutamiento fue correcto

Cada prompt también recibe una ruta: las rutas donde es más probable que esté el trabajo, indicadas antes de que el asistente abra nada. Luego Pathrule registra si el asistente fue ahí. En una ventana móvil, eso se convierte en una única cifra de precisión, junto con cuánto trabajo con herramientas de archivos requiere una sesión enrutada en comparación con una que nunca se enrutó.

Es el único número que dice si señalar una ruta ayuda de verdad en lugar de solo parecer útil, y es la razón por la que el enrutamiento se puede ajustar con evidencia y no por gusto.

Cada capa dice si todavía recibe datos

Cada una de las capas derivadas anteriores depende de que le llegue trabajo, y una capa que deja de recibir datos no devuelve nada. Eso se ve exactamente igual que una capa que no tiene nada que reportar. Esos dos casos requieren respuestas opuestas, así que Pathrule no deja que se vean iguales.

A cada capa se le pregunta con regularidad cuándo recibió datos por última vez, y la respuesta se registra como uno de tres estados: al día, sin recibir nada últimamente o nunca alimentada. La misma verificación detecta turnos que llegan desde un cliente lo bastante antiguo como para ser anterior a parte del registro, de modo que una actualización que vale la pena instalar aparece como un conteo con nombre y no como resultados que empeoraron sin que nadie lo notara.

Por eso, que una capa derivada se quede en silencio es un estado reportado con fecha, y no algo que alguien descubre meses después al preguntarse por qué empeoró un resultado.

Episodios y juicios sobre vigencia

Hay dos capas derivadas más sobre la misma actividad.

Los episodios de trabajo unen turnos relacionados en la historia de cómo se resolvió algo, así que "¿cómo lo hicimos la última vez?" tiene una respuesta que no depende de la memoria de una persona. Consulta cómo resolvimos esto antes.

Los juicios de obsolescencia comparan lo que afirma una entrada con hacia dónde ha ido el código desde entonces, y presentan las que parecen superadas como ediciones propuestas en lugar de bajarles la prioridad en silencio. Consulta sugerencias y autoauditoría.

Preferencias personales, guardadas en tu máquina

Hay una capa que empieza contigo y no con el trabajo registrado. Cuando le dices a Pathrule cómo te gusta trabajar, por ejemplo pathrule me teach "I prefer incremental refactors", el modelo en el dispositivo opcional convierte la frase en una preferencia breve y con alcance definido. Se guarda en tu máquina, no se sube, y se entrega a tus agentes donde aplica.

Tú mantienes el control: pathrule me list muestra lo que está en uso, pathrule me explain muestra de dónde salió una preferencia, pathrule me scope la limita a un espacio de trabajo o permite que se aplique en varios, pathrule me forget hace que deje de usarse y pathrule me context muestra una vista previa de lo que recibiría un agente para una tarea. Consulta User Intelligence.

A partir de qué no se construye nada de esto

No del contenido de tu código fuente. El código fuente del repositorio no se sube automáticamente. Cada capa derivada anterior proviene de lo que tu equipo decidió escribir y de lo que el trabajo reportó sobre sí mismo, y no se guarda ningún diff ni mensaje de commit.

Se leen dos cosas de tu copia local, ambas solo en un espacio de trabajo de Cloud y ambas la primera vez que un agente pide contexto profundo:

• Rutas de archivos del historial reciente de git, para saber qué archivos cambiaron en el mismo commit. Los commits muy grandes, normalmente refactorizaciones o renombrados, se omiten. Los pares de rutas de archivos resultantes se guardan en el espacio de trabajo como punto de partida del grafo de cambios conjuntos. No se leen mensajes de commit, autores ni diffs.
• Nombres de archivos cercanos a la parte superior del árbol de carpetas, para reconocer las tecnologías en uso a partir de archivos de configuración, como una configuración de TypeScript, Vite, Docker o GitHub Actions. Cada tecnología que reconoce se convierte en una memoria breve en la raíz del espacio de trabajo, escrita sin preguntar. Es una memoria normal que puedes editar o eliminar.

Mientras el historial propio del espacio de trabajo todavía es escaso, esa misma respuesta profunda también indica las carpetas de nivel superior del proyecto y los archivos que más cambiaron en el historial reciente de git. Estos se leen de tu copia local y se entregan al agente para esa respuesta, pero Pathrule no los guarda.

Un espacio de trabajo local, que se mantiene en tu máquina sin cuenta, no hace nada de esto: su grafo de cambios conjuntos proviene únicamente del trabajo registrado.

Hay dos cosas más que salen de tu máquina en modo Cloud, y ambas se indican aquí:

• El inicio de cada prompt. La primera parte del prompt, aproximadamente sus primeros 1.000 caracteres, se envía a Pathrule Cloud para priorizar el conocimiento correspondiente.
• Una instantánea del proyecto, cuando tú o tu agente ejecutan pathrule snapshot. Sube el árbol de archivos, los manifiestos, muestras breves de la documentación y metadatos recientes de git. Solo se ejecuta cuando se invoca.

El escaneo del proyecto es un paso aparte que inicias tú, pidiéndole a tu agente que configure Pathrule para el proyecto. Tu agente lee el proyecto para proponer memorias, reglas y skills, y solo se guarda lo que apruebas.

Por otro lado, una CLI administrada con sesión iniciada puede enviar telemetría de uso anónima solo después de que la actives con pathrule telemetry enable. No contiene código, rutas, prompts, conocimiento, nombres de archivos, correos ni identificadores de cuenta. pathrule telemetry disable, NO_TELEMETRY=1 y DO_NOT_TRACK=1 la mantienen desactivada.

Las rutas de archivos se normalizan a forma relativa al espacio de trabajo antes de guardar cualquier cosa, así que tampoco viaja nada específico de tu máquina.

Por qué los mismos archivos en una carpeta no son lo mismo

Podrías poner las mismas memorias, reglas y skills en un directorio y apuntar un asistente hacia él. Hay equipos que lo hacen. Lo que ese directorio no puede hacer es nada de lo que describe esta página.

No sabe qué se entregó en el último turno, así que no puede saber qué ayudó. No tiene ninguna representación del significado, así que una pregunta formulada de otra manera no encuentra nada. No sabe qué archivos cambian juntos, así que el conocimiento registrado en un archivo nunca llega a su vecino. No puede distinguir un tipo de tarea de otro, así que todo tiene la misma prioridad para todo. Y crece: cada entrada que se agrega hace más pesado cada turno futuro, porque un directorio no tiene forma de enviar solo las pocas que importan.

Las entradas escritas son la parte que tú controlas. La capa derivada es lo que las convierte en las pocas correctas para este turno, y es la razón por la que la respuesta mejora a medida que el trabajo continúa en lugar de quedarse exactamente igual de buena que el día en que se escribió.