PathruleReglas como barreras de protección
Cómo una regla de Pathrule con un patrón de bloqueo aprobado puede detener un cambio que no cumple antes de que se aplique, mientras las demás reglas acompañan como contexto.
En esta página
Una regla en Pathrule no es una nota que el asistente lee después. Es una barrera de protección que llega antes de que el asistente actúe. La mayoría de la documentación te cuenta qué salió mal cuando ya está en producción. Una barrera de protección puede detener el cambio antes de que se aplique.
Esta página explica la diferencia entre el contexto que informa un turno y una regla que puede bloquearlo. Para entender cómo los hooks entregan el contexto, lee primero Cómo funcionan los hooks. Esta página trata de lo que hace una regla estricta una vez que ese contexto ya está disponible.
Pull pide. Push llega.
El modelo anterior es pull. El asistente tiene que acordarse de pedir tus convenciones, llamar a una herramienta y leer el resultado antes de editar cualquier cosa. Si se le olvida, edita a ciegas y tú encuentras el problema en la revisión.
El modelo de hooks es push. En Claude Code y Codex, el contexto llega sin que el asistente lo pida cuando envías un prompt y justo antes de que el asistente use una herramienta. Cursor y GitHub Copilot no tienen un hook al enviar el prompt, así que ahí el hook de inicio de sesión entrega el contexto inicial y los hooks de herramientas entregan las reglas de la ruta que se está modificando. En cualquier caso, cuando el asistente está por escribir un archivo, las reglas vinculadas a esa ruta ya están frente a él. Windsurf no tiene hooks: lee el archivo de reglas de Pathrule y le pide más al servidor MCP local, así que en Windsurf las reglas informan pero no bloquean.
Dos niveles: consultivo y de bloqueo
No todas las reglas deberían interrumpir al asistente. Pathrule maneja las reglas en dos niveles.
- Las reglas consultivas acompañan como contexto. Aparecen junto al archivo que el asistente está por modificar, con su prioridad, para que el asistente las tenga en cuenta. No detienen nada. La mayoría de las reglas son consultivas, sin importar su prioridad.
- Las reglas estrictas pueden bloquear. Una regla se vuelve estricta cuando lleva un patrón de bloqueo aprobado por una persona: una forma prohibida en el contenido, como un import, un identificador, un nombre de clase o una declaración CSS, una ubicación prohibida para un archivo, o ambas. Cuando el asistente está por editar o escribir un archivo de una forma que coincide, el hook detiene la llamada a la herramienta antes de que se escriba el archivo y devuelve el motivo. El asistente lo lee y lo vuelve a intentar, esta vez dentro de la restricción.
La prioridad y el bloqueo son independientes. La prioridad (alta, media, baja) decide qué tan visible es una regla y qué reglas entran cuando falta espacio. No decide el bloqueo: se revisan todas las reglas estrictas de la ruta, sea cual sea su prioridad.
Cómo una regla se vuelve estricta
Un asistente no puede activar un patrón de bloqueo por su cuenta.
- Primero la regla se escribe en lenguaje natural, ya sea por ti o por un asistente al que se lo pediste.
- Un asistente puede proponerle un patrón de bloqueo mediante las herramientas MCP de escritura y actualización de reglas. La forma preferida nombra el texto prohibido tal como lo escribe la regla, con ejemplos reales que deben detectarse y casos parecidos que no. Pathrule construye el patrón a partir de eso y lo prueba contra ambos conjuntos; si alguno falla, la propuesta se rechaza con el motivo en lugar de debilitarse.
- La propuesta se guarda con la regla y no se aplica.
- Solo después de que una persona la aprueba, el hook empieza a bloquear, y la solución escrita para ella se convierte en el "haz esto en su lugar" que ve el asistente.
Una regla también puede llevar una verificación obligatoria: un comando de verificación que debe haberse ejecutado con éxito antes de que termine el turno, como la suite de pruebas de un paquete. Igual que un patrón de bloqueo, se propone y no se aplica hasta que una persona la aprueba. Una vez aprobada, en Claude Code y Codex el hook mantiene abierto el turno, con el comando exacto que hay que ejecutar, hasta que se ejecute con éxito.
Qué ve el asistente
Una edición bloqueada vuelve con el nombre de la regla, una vista previa breve de la regla, la solución aprobada y una referencia a la regla completa. Para una regla llamada "No direct database client in UI components", se ve así:
Pathrule blocked: "No direct database client in UI components"
UI components never import the database client. Data goes through the data layer hooks.
Do this instead: call the data layer hook for this resource.
Your edit matches this rule's forbidden pattern. Read the full rule via pathrule_read_rule(<id>) and retry without the violation.
Claude Code, Codex, Cursor y GitHub Copilot reciben esto como un rechazo de la llamada a la herramienta, en el formato de hooks propio de cada cliente. Windsurf no tiene hooks, así que ahí no se bloquea nada. El bloqueo se aplica a las ediciones y escrituras de archivos; un comando de shell sigue recibiendo la regla como contexto.
Esta división es intencional. Bloquear una edición de poco riesgo desperdicia el turno del asistente y el tuyo. El bloqueo se reserva para las reglas en las que una infracción es una regresión real y alguien aprobó exactamente qué cuenta como tal.
Antes y después
Piensa en una regla que dice que los secretos nunca van en archivos confirmados en el repositorio, con un patrón de bloqueo aprobado para el formato de clave que usa tu proveedor.
| Sin la barrera de protección | Con la barrera de protección | |
|---|---|---|
| La intención del asistente | Agregar una API key a un archivo de configuración para que una funcionalidad funcione | Igual |
| Qué pasa | La edición se aplica | El hook bloquea la llamada a la herramienta que coincide antes de que se escriba el archivo |
| Cuándo te enteras | Más tarde, en la revisión (o nunca) | En el mismo turno. El asistente ve el texto de la regla y cambia a una variable de entorno |
| Resultado en disco | Un secreto confirmado en el repositorio | La edición que coincidía no se escribió |
El mismo patrón aplica a cualquier regla que a un equipo le haya costado caro en producción: una política de acceso a datos que debe filtrar por usuario, una convención de migraciones, un archivo generado que no se debe editar a mano. La regla deja de ser un comentario que alguien espera que el asistente haya leído y se convierte en una verificación que se ejecuta antes de que se aplique la edición. Un patrón de bloqueo detecta las formas para las que fue aprobado, así que complementa la revisión en lugar de reemplazarla.
Los nombres de archivo traen la memoria correcta
No siempre tienes que esperar a una llamada a una herramienta. En Claude Code y Codex, cuando tu prompt nombra un archivo del que trata una memoria vinculada, el hook del prompt puede mostrar el contenido de esa memoria antes de que el asistente abra cualquier cosa. Nombrar el archivo en el que estás trabajando suele bastar para poner el contexto correcto frente al asistente desde el primer turno. Cuando más de una memoria coincide con el mismo nombre de archivo, el hook muestra las candidatas en lugar de adivinar.
Falla en modo abierto por diseño
Una barrera de protección que rompe tu flujo de trabajo cuando falla es peor que no tener ninguna. Pathrule falla en modo abierto. Si el hook no puede evaluar una regla, da error o se agota el tiempo de espera, no bloquea tu trabajo. El cambio sigue adelante. La aplicación de reglas es una red de seguridad, no una puerta en la que puedas quedarte atascado.
Tú mantienes el control. Si alguna vez quieres desactivar los hooks por completo, un solo archivo los apaga.
Compruébalo tú mismo
No tienes que creer en este comportamiento a ciegas.
Para ver qué hooks registró tu cliente de IA, lee su archivo de configuración. En Claude Code, Pathrule registra sus hooks en el proyecto:
cat .claude/settings.json
Cursor usa .cursor/hooks.json, Codex usa .codex/hooks.json y GitHub Copilot usa .github/hooks/pathrule.json.
Para desactivar al instante todos los hooks de Pathrule (el interruptor de apagado), crea un archivo:
touch ~/.pathrule/kill-hooks
La siguiente llamada a una herramienta pasa directo, sin intervención de Pathrule. Elimina el archivo para volver a activar los hooks:
rm ~/.pathrule/kill-hooks
Para confirmar que una regla realmente está vinculada a una ruta, ejecuta pathrule rule list en la carpeta, o abre la vista de contexto de Pathrule del asistente en tu editor. La regla aparece con su prioridad antes de que el asistente actúe sobre esa ruta, y una regla estricta muestra su bloqueo la primera vez que una edición coincide con ella.
Qué leer a continuación
- Cómo funcionan los hooks para conocer el mecanismo de entrega y el comportamiento cuando no hay contenido.
- Escribir reglas para aprender a redactar una regla que valga la pena aplicar.
- Descripción general de MCP para conocer la vía detallada que usa el asistente cuando el hook no es suficiente.