Skip to main content
Narya comprueba un control delante de cada llamada a herramienta. Dos cosas deciden la respuesta: si confías en el directorio y lo que dicen las reglas.

​
La pregunta de confianza

El cliente pregunta ¿Confiar en este repositorio? una ida y vuelta después de abrirse. Pregunta solo cuando el directorio lleva algo gobernado: un archivo de instrucciones, un directorio de recursos o un .narya/config.toml. La pregunta muestra dos líneas de divulgación: qué llega al modelo y qué se ejecuta en esta máquina. Tienes cuatro respuestas:
  • y confía en esta carpeta.
  • p confía en esta carpeta y en su carpeta padre. El host calcula la carpeta padre, así que ningún cliente puede ampliar el alcance más allá de lo que te mostró.
  • n es un no duradero.
  • esc continúa sin confianza. Narya no guarda nada y vuelve a preguntar en el siguiente inicio.
Narya guarda una fila por ruta canónica. Una búsqueda sube por el árbol, y decide el ancestro más cercano con confianza o con rechazo. Escribe /trust para reabrir la pregunta.

​
Qué desbloquea la confianza

La confianza decide qué conjunto de reglas se ejecuta. Un directorio en el que nadie confía se ejecuta bajo un conjunto más estricto, y solo donde una persona puede responder. Una ejecución de un solo turno mantiene el conjunto de fábrica. Las lecturas siguen libres. Las acciones de shell, de escritura, de red y de herramienta preguntan. La confianza pone en su lugar el conjunto de fábrica. La confianza también controla el material propio del repositorio: sus archivos de instrucciones, sus hooks de .claude/settings.json y sus comandos, skills y agentes de .claude y .narya. Narya lo ignora todo en un repositorio sin confianza, en cualquier modo.

​
Cómo se lee una regla

Una regla es una tabla TOML con tres claves.
Existen cinco acciones, y no más: shell, read, write, network y tool. La acción decide qué compara Narya. Un glob de ruta corresponde a read y write. El texto del comando corresponde a shell, después de que Narya descompone la línea en los comandos que realmente ejecuta. Un host corresponde a network. Un nombre de herramienta corresponde a tool. Existen tres efectos: allow, ask y deny. No hay campo de orden. La posición en el archivo es la precedencia. Narya concatena cuatro ámbitos en este orden: su conjunto de fábrica, tu archivo global, el archivo del proyecto y la sesión. Gana la última coincidencia. Narya lee permissions.toml en tu home de Narya solo cuando config.toml define permission_mode = "custom". Un repositorio en el que confías aporta bloques [[rule]] a través de su .narya/config.toml.

​
La postura de fábrica

Los comandos de shell se ejecutan. Las llamadas a herramientas se ejecutan. Más de cuarenta reglas de shell preguntan primero, entre ellas rm -r, sudo, git push --force, chmod, dd y kill -9. Las escrituras dentro del repositorio se ejecutan, y las escrituras fuera de él preguntan. Las acciones de red preguntan, excepto la búsqueda web del propio proveedor, que solo deny network ** desactiva. La herramienta de lectura rechaza un archivo .env y lee todo lo demás. Esa regla gobierna solo la herramienta de lectura. Un grep del directorio devuelve el contenido del archivo. Un comando de shell lo lee bajo las reglas de shell. Una escritura sobre él está permitida. Narya juzga una línea de shell con el veredicto más estricto de todo lo que realmente ejecuta. Una línea que Narya no puede analizar pregunta, y Narya no recuerda nada de ella.
Una ejecución no interactiva convierte cada pregunta en un rechazo registrado. Nunca se queda colgada. narya -p siempre se ejecuta en ese modo.

​
Auditoría

Narya escribe una fila por cada pregunta y por cada rechazo que pertenece a una sesión, incluidos los rechazos que no llegaron a ninguna persona. Un rechazo fuera de una sesión, o una fila que el almacén no logra escribir, no deja fila. El rechazo sigue en pie. Cada fila lleva:
  • la acción y el recurso
  • qué reglas coincidieron, y qué otorgaría un permiso recordado
  • el estado y quién decidió
  • el motivo
  • el alcance de la respuesta
Los permisos derivados de reglas no llevan fila. Lee las filas con narya permissions denied. Agrega --session <id>, --since <time> o --until <time> para acotar el rango. Una página contiene 100 filas, y Narya lo indica cuando trunca. La retención es opcional por clase y conserva todo de forma predeterminada. El ajuste [retention] permission_asks barre las filas ya decididas y conserva las pendientes.

​
Sesiones atendidas y desatendidas

Cada sesión registra una postura, attended o detached. Una sesión desatendida rechaza y registra la siguiente pregunta en lugar de bloquearse para siempre. Ejecuta narya session promote <session-id> para marcar una sesión como atendida. Repite la pregunta de salida del cliente, y una segunda ejecución no cambia nada. Una sesión registrada como desatendida en un directorio en el que nadie confía vuelve a atendida en su siguiente comprobación de control. La lectura de confianza falla en cerrado.