User Intelligence

Workspace Intelligence guarda el proyecto. User Intelligence guarda a la persona que hay detrás del trabajo.

Dos ingenieros en el mismo repositorio no quieren lo mismo de un agente, y la diferencia no es cosmética. Tiene que ver con cuánto debe decidir el agente por su cuenta, cuándo debe detenerse y ofrecer opciones en lugar de implementar, cuánta verificación se considera suficiente y por qué camino ir cuando dos diseños son igual de defendibles.

Eso es un conjunto real de conocimiento y, si no tiene dónde guardarse, termina viviendo en las correcciones que vuelves a escribir en cada sesión nueva.

Qué modela

Preferencias de ejecución

Si quieres un refactor incremental o estás abierto a reescribir. Si esperas ver opciones antes de una implementación o prefieres que el agente simplemente avance con cierto tipo de cambio. Cuánta abstracción consideras justificada. Qué tipos de cambio esperas que te consulten antes de hacerse.

Patrones de decisión

Qué compromisos sueles elegir. Rendimiento frente a mantenibilidad. Construir frente a adoptar. Qué tan estricto eres con la compatibilidad hacia atrás. Qué pesas primero cuando una decisión de producto se cruza con una técnica.

Expectativas de calidad

Cuántas pruebas esperas. Cuándo quieres un benchmark en lugar de un argumento. Cuándo la investigación es suficiente y cuándo se ha convertido en un sustituto de entregar. Qué entiendes por terminado y qué nivel de validación va con eso.

Estilo de colaboración

Qué tan autónomo debe ser el agente. Cuándo esperas una pregunta. Cuándo esperas que te den a elegir. Cómo quieres que te reporten el trabajo y con qué nivel de detalle en las explicaciones.

Lo que no modela

No modela quién eres. Ni datos demográficos, ni personalidad, ni nada que se infiera sobre ti como persona. La unidad es una preferencia de trabajo sobre cómo debe hacerse el trabajo de software, y cada una es algo que podrías haber dicho en voz alta.

Hay tres tipos de afirmación que se rechazan directamente en lugar de guardarse:

• Cualquier dato personal. Salud, religión, política, sexualidad, etnia, finanzas y relaciones privadas quedan fuera de lo que Pathrule conserva, sin importar de qué trataba la frase.
• Una regla disfrazada de preferencia. Una preferencia es un consejo para un agente. Una afirmación formulada como prohibición ("nunca", "no debe", "prohibido") se leería como un requisito del proyecto que no tiene autoridad para ser, así que no se guarda. Si algo realmente no debe ocurrir nunca en un proyecto, su lugar es ahí, como regla.
• Un hecho sobre un proyecto. "En este repositorio usamos el helper de configuración compartido" es cierto para un código en particular, no para ti. Si se guardara como tuyo, te seguiría hasta el repositorio de un cliente donde es falso. Eso es conocimiento del espacio de trabajo, y se queda en el espacio de trabajo.

Cómo aprende

Se lo enseñas tú. Ejecuta pathrule me teach con la frase que, de otro modo, seguirías escribiendo en cada sesión nueva:

pathrule me teach "Show me options before implementing anything that changes a public API"

El modelo local opcional lee la frase en tu propia máquina y la convierte en una preferencia de trabajo estructurada. Lo que concluya tiene que estar presente en tus propias palabras: no puede parafrasearte hasta convertir lo que dijiste en una preferencia que nunca expresaste, y si no puede señalar lo que escribiste, no se guarda nada y la CLI te explica por qué.

What you teach
      |
Checked against your own words
      |
Refused, or stored as a preference
      |
Active, and delivered where it applies

En concreto, si repites alguna versión de "no conviertas cada implementación en un proyecto de investigación", la representación útil no es una cita guardada. Es una preferencia de trabajo:

Prefer implementation once the primary correctness
questions are resolved.

Source:     you told Pathrule
Applies:    across workspaces

Para enseñar se necesita una Mac con Apple Silicon y el modelo local instalado. Todo lo demás en esta página, incluida la entrega, funciona sin él.

Cuando cambias de opinión

Cuando enseñas una preferencia nueva que contradice otra anterior sobre el mismo tipo de trabajo, la nueva reemplaza a la anterior. La antigua se retira, no se elimina, y conserva una referencia a la que la reemplazó, de modo que la pregunta "¿por qué cambió esto?" siempre tiene respuesta. Dos preferencias sobre tipos de trabajo distintos simplemente conviven.

Quién es "el usuario"

Las preferencias se redactan sobre ti, así que cuando hablas de las personas que usan lo que construyes, la redacción podría convertirlas en ti sin que nadie lo note. "Resuelve las cosas sin mostrar errores a los usuarios" un agente lo leería como "no me muestres errores", que es justo lo contrario de lo que querías decir. Cuando tus propias palabras se referían a tus usuarios, la preferencia sigue diciendo "usuarios finales".

Dónde se aplica una preferencia

User Intelligence te pertenece a ti, no a un repositorio. Dónde se aplica cada preferencia es otra cuestión.

• Lo que enseñas se aplica en todas partes. No se aprendió de un proyecto, así que no se guarda en uno.
• Puedes limitar una preferencia a un espacio de trabajo. pathrule me scope <id>, ejecutado dentro de un repositorio, limita esa preferencia al espacio de trabajo donde lo ejecutas. pathrule me scope <id> --everywhere hace que vuelva a aplicarse en todos los espacios de trabajo.

Cómo llega una preferencia a un agente

Antes de cada turno, Pathrule elige las preferencias que aplican al trabajo que está por hacerse.

• Solo las activas. Una preferencia que todavía no está en uso aparece en pathrule me list y nunca llega a un agente. Tampoco se usan las retiradas ni las rechazadas.
• Solo las que están en el alcance del espacio de trabajo, como se explicó arriba.
• Solo las que tratan sobre esta tarea. Una preferencia sobre cómo trabajar contigo aplica a cualquier tarea. Una preferencia sobre un tipo de trabajo, como arquitectura o migraciones, llega a un agente solo cuando la tarea trata de eso.
• Unas pocas por turno, de la más fuerte a la más débil. Si aplican más, las que quedan fuera son las más débiles.
• Cada una indica de dónde viene, para que el agente pueda darle a "tú lo dijiste" el peso que realmente tiene.

Llegan a través del hook de prompt, cada una una sola vez por sesión, bajo un encabezado que le indica al agente que las reglas y las verificaciones obligatorias del espacio de trabajo van primero. Hoy eso significa sesiones de Claude Code y Codex. Cursor y GitHub Copilot tienen hooks de sesión y de herramientas, pero no hook de prompt, y Windsurf no tiene hooks, así que las preferencias no les llegan. Consulta cómo funcionan los hooks.

Autoridad: qué pasa cuando tú y el proyecto no están de acuerdo

Una preferencia del usuario no se impone sobre la verdad del proyecto.

User Intelligence
Prefer minimal testing.

Workspace Intelligence
Rule: run migration verification before completion.

Se aplica la regla. Es un requisito del espacio de trabajo, y una preferencia por menos verificación no es motivo para omitirla.

La regla general, que vale la pena decir con claridad:

• Workspace Intelligence representa la verdad y los requisitos del proyecto. Sus reglas y verificaciones obligatorias son requisitos estrictos.
• User Intelligence da forma a la colaboración: cómo se aborda el trabajo, cuánto se hace de manera autónoma y cómo se reporta. No redefine qué significa que algo esté correcto.

Cuando ambas tratan solo de estilo, se aplica tu preferencia. Cuando el espacio de trabajo establece un requisito de seguridad o de corrección, ese requisito se mantiene.

Lo mismo ocurre aunque no haya una regla en el espacio de trabajo. Una preferencia que podría implicar menos verificación se retiene siempre que el trabajo toque autenticación, pagos, migraciones de datos, criptografía o seguridad. Ahí los errores pasan desapercibidos y salen caros, y una preferencia que se formó con código cotidiano no dice nada sobre si es segura en ese terreno.

Qué controlas tú

Todo. User Intelligence se puede inspeccionar, no queda implícita. Para cada preferencia puedes ver:

• Su estado: candidata, activa, retirada o rechazada.
• De dónde viene y qué tan segura es.
• Dónde se aplica: en todos los espacios de trabajo o solo en uno.
• Por qué: las palabras en las que se basa, con fechas.

Y puedes:

• Enseñar una preferencia directamente.
• Olvidar una. Deja de usarse y se conserva como rechazada para que la misma afirmación no la traiga de vuelta enseguida. Agrega --delete para eliminarla por completo.
• Limitar una a este espacio de trabajo, o dejar que se aplique en todas partes.
• Comprobar qué recibiría un agente para una tarea antes de empezarla.

Una inferencia que nunca ves es una inferencia que no puedes discutir, y por eso cada preferencia está a un comando de distancia.

Desde la línea de comandos

pathrule me list                    # what is in use, and what is not yet
pathrule me teach "I prefer incremental refactors"
pathrule me explain <id>            # the evidence behind one preference
pathrule me scope <id>              # keep it to the workspace you run this in
pathrule me scope <id> --everywhere # let it apply in every workspace
pathrule me forget <id>             # stop using it
pathrule me forget <id> --delete    # remove it entirely
pathrule me context "add a payments webhook"

pathrule me context muestra exactamente lo que recibiría un agente para esa tarea, además de qué preferencias se retuvieron y por qué. Es la forma más rápida de comprobar que una preferencia llega al trabajo para el que la pensaste, y solo a ese trabajo. Todos los subcomandos aceptan --json.

Al moverte entre proyectos

Abre otro repositorio y el conocimiento del proyecto que te rodea cambia por completo. Las preferencias que enseñaste, salvo que hayas limitado alguna a un solo espacio de trabajo, se van contigo.

Ahí es donde ambas se encuentran en un turno: el espacio de trabajo aporta lo que es cierto y obligatorio aquí, tú aportas cómo debe hacerse el trabajo, y la entrega mantiene los requisitos del proyecto por encima de tus preferencias. Consulta Agent IR.

Límites que conviene conocer

• La coincidencia es por palabras, no por significado. Una preferencia llega a una tarea que comparte sus términos. Una formulada de manera muy distinta a la tarea puede no llegar.
• Para enseñar se necesita el modelo local, que solo funciona en Macs con Apple Silicon.
• Las preferencias solo llegan a clientes con hook de prompt: Claude Code y Codex.
• Prefiere abstenerse antes que adivinar. Una frase que no puede fundamentar en tus propias palabras no se guarda. Perder una preferencia te cuesta escribir una frase más; inventarla te representaría mal ante cada agente con el que trabajas.

Privacidad

La inferencia que convierte lo que enseñas en una preferencia estructurada se ejecuta en tu propio dispositivo, y tus preferencias se guardan en un almacenamiento privado en tu máquina.

Si compartes un espacio de trabajo con un equipo, lo que se sincroniza es el conocimiento del espacio de trabajo, no tus preferencias de trabajo personales. Y cuando usas Claude Code, Codex u otro agente, a todo lo que le llega a ese agente se le aplican los límites de su propio proveedor. La página de seguridad mantiene esos límites por separado, porque reducirlos a una sola frase es justo lo que hace que una afirmación deje de ser cierta.

Qué leer a continuación

• Workspace Intelligence: lo que aporta el proyecto y por qué sus requisitos tienen prioridad.
• El modelo local: qué se ejecuta en tu dispositivo y cómo instalarlo.
• Referencia de comandos de la CLI: todos los subcomandos de pathrule me junto con el resto de la CLI.