Cómo demuestra Pathrule sus afirmaciones más exigentes

El estándar técnico de Pathrule es sencillo: una afirmación sobre el producto necesita una entrada acotada, un comportamiento definido cuando falta evidencia y un resultado que pueda comprobarse de forma independiente.

Esta página reúne esos contratos sobre cómo entra el conocimiento en Pathrule, cómo se selecciona y cómo se entrega. Una conexión de Remote MCP tiene un límite de entrega distinto: no instala hooks, así que el conocimiento llega cuando el agente llama a las herramientas de Pathrule.

La calidad del conocimiento pasa por varios filtros

Pathrule no mete cada archivo Markdown en cada prompt. El conocimiento pasa por controles independientes:

1. Descubrimiento selectivo. Cuando tu agente ejecuta el escaneo del proyecto, los archivos de instrucciones activos, su cadena de importaciones, las reglas de herramientas y los registros de decisiones se distinguen de la documentación general. La documentación amplia se ofrece para revisión en lugar de importarse por defecto como instrucción activa.

2. Revisión antes de persistir, con las excepciones explícitas. El conocimiento inferido espera a una persona: los candidatos del escaneo del proyecto solo se agregan cuando se aprueban, las sugerencias de Team Intelligence llegan a los agentes solo cuando una persona las verifica, las correcciones de conocimiento desactualizado no cambian nada hasta que se resuelve una tarea de actualización, y una restricción ejecutable que un agente propone para una regla se guarda como propuesta y no se aplica hasta que una persona la aprueba. Lo que escribe un asistente por su cuenta pasa por las herramientas de escritura de Pathrule y queda marcado como escrito por un asistente, versionado y reversible. Los hallazgos del aprendizaje del proyecto se comparten sin paso de revisión, como consejos que hay que verificar y nunca como reglas. Dos cosas se escriben sin preguntar, solo en un espacio de trabajo de Cloud y solo la primera vez que un agente pide contexto profundo: los pares de rutas de archivos leídos del historial reciente de git, que alimentan qué archivos cambian juntos, y memorias breves de tecnología en la raíz del espacio de trabajo, reconocidas a partir de nombres de archivo. En ninguno de los dos casos se leen contenidos de archivos, diffs ni mensajes de commit. Consulta Cómo se acumula el conocimiento.

3. Pertenencia a una ruta. Una entrada pertenece a la ruta más específica del espacio de trabajo que la contiene. El trabajo fuera de esa ruta no la recibe solo porque exista en el mismo repositorio.

4. Relevancia para la solicitud. Una entrada tiene que calificar para la solicitud actual, cada vez. La elegibilidad y el orden se deciden por separado y nunca intercambian papeles: uno decide si una entrada es elegible y el otro decide el orden entre las que ya lo son. El aprendizaje solo afecta el orden. Puede llevar una memoria probada del cuarto lugar al primero; no puede hacer que se entregue algo que no es elegible. El volumen también está acotado: la entrega se ajusta a un presupuesto por prompt, así que la cantidad entregada no crece con el tamaño de la base de conocimiento.

   Por eso no hace falta escribir con disciplina para tener un prompt limpio. Una entrada vaga o mal escrita no se convierte en ruido; simplemente nunca califica para una solicitud con la que no tiene nada que ver. El costo visible de una memoria débil es que no aparece.

5. Entrega y uso medidos. Pathrule registra lo que entregó y lo que consultó el asistente. Las capas derivadas informan cuándo recibieron datos por última vez, de modo que se puede distinguir un sistema en calma de uno desconectado.

   La misma disciplina se aplica a por qué una entrada no se entregó. "Nada calificó", "la llamada de priorización agotó el tiempo de espera", "la respuesta estaba mal formada" y "no había nada que priorizar" se registran como resultados distintos y no con una sola palabra, porque son situaciones diferentes con soluciones diferentes. Un momento de lentitud se informa como tal, así que nunca se confunde con una base de conocimiento vacía.

   Cuando el conocimiento relevante no cabe en el presupuesto, o su cuerpo todavía no está en la máquina, se ofrece por título en lugar de descartarse, para que el asistente pueda obtenerlo de forma deliberada. Este diseño busca evitar justamente eso: descartar una respuesta correcta solo porque no estaba a mano.

6. Mantenimiento revisable. El conocimiento que un agente detecta como desactualizado, contradicho por el código, duplicado o poco claro se envía a revisión como tarea de actualización, y no se cambia nada hasta que esa tarea se resuelve. Las escrituras quedan versionadas, los conflictos son explícitos y la eliminación es reversible.

Estos filtros convierten el conocimiento compartido en un sistema operativo pequeño e inspeccionable para un repositorio. Gracias a ellos, un proyecto puede acumular decisiones sin convertir todo su archivo de documentación en contexto por defecto. Consulta Cómo se acumula el conocimiento y Sugerencias y autoauditoría.

Verificación con fecha

El 23 de agosto de 2026, las comprobaciones automatizadas específicas de estos contratos pasaron en el repositorio principal del producto Pathrule, entre ellas el descubrimiento de conocimiento, el orden de las importaciones y la exclusión de fuentes ruidosas.

El benchmark público de entrega de contexto se puede reproducir por separado en github.com/pathrule/benchmarks. Cómo medimos publica su método, los artefactos sin procesar y los resultados, que son mixtos. Los resultados medidos describen las configuraciones en las que se midieron; no son garantías para tu repositorio.

Una regla útil para evaluar

Ante cualquier afirmación de Pathrule, hazte tres preguntas:

1. ¿Qué evidencia entra en la decisión?
2. ¿Qué pasa cuando esa evidencia falta o es ambigua?
3. ¿Qué resultado puede cambiar o bloquear el trabajo?

Los contratos anteriores responden las tres. Esa es la diferencia entre la descripción de una función y una afirmación de ingeniería.