Leer una regla como la lee quien la mantiene

Este es el comienzo del archivo de FZQ-021. El panel lo trae completo, línea a línea:

title: Cuenta agregada al grupo de administradores locales
id: 00000000-0000-4000-8000-000000000021
status: test
date: 2026-03-02
modified: 2026-06-30

Cada campo cumple un papel. El título lo lee una persona y puede cambiar cuando se aclara. El nombre del archivo puede cambiar si se reorganizan las carpetas. El id es el identificador de la regla: lo usan las fichas, los tickets y las pruebas para referirse a ella, y por eso no debe cambiar mientras la regla siga siendo la misma. date es cuándo se creó y modified, cuándo se modificó por última vez la parte que importa (título, detección, nivel o fuente de registros).

En el repositorio de Zipaquirá los id son marcadores evidentes (00000000-0000-4000-8000-…) porque este es un ejemplo; en un repositorio real cada id es un identificador universal único generado una vez.

Después del encabezado viene la lógica. En Sigma la parte detection tiene selecciones con nombre y una condition que las combina. Quien mantiene la regla empieza siempre por ahí: qué evento y qué valor busca.

Abre el panel y consulta el bloque de detección (líneas 16 a 22).

La condición de la regla no es solo seleccion: es seleccion and not filtro_inventario. Un filtro es una selección que, si se cumple, hace que el evento no cuente. Es la forma ordenada de documentar una excepción: queda a la vista, con nombre, en vez de esconderse en una lógica larga. También es el lugar donde una regla se vuelve ciega sin que nadie lo note, porque cada excepción es algo que la regla deja de ver.

La lectura de una condición se hace con una frase: «salta cuando ocurre esto y no ocurre aquello». Quien revisa un cambio la repite en voz alta antes de mirar nada más, porque una condición que no se puede decir en una frase suele estar mal pensada.

Fíjate también en la última línea de la regla: level: high. Es el nivel de la alerta para el turno, y status: test es la fase de la regla. Los valores posibles de status son stable, test, experimental, deprecated y unsupported; una regla que se da de baja se marca como deprecated en vez de desaparecer sin rastro.

Un repositorio con historia acumula descuidos que no dan error: dos archivos que declaran el mismo id, una regla copiada y modificada sin cambiar su identificador, un título que ya no dice lo que hace la lógica. Los dos primeros son peligrosos porque las fichas, los tickets y las pruebas apuntan a un id, y con dos archivos iguales nadie sabe a cuál.

El panel trae una tabla con el id y la fecha de creación que declara cada archivo de reglas.