Gestionar un repositorio de reglas

Las reglas de contenido se escriben pronto y se olvidan tarde. Sin versiones, nadie sabe qué cambió cuando una regla empieza a marcar de más. Sin revisión por otra persona, los errores de la autora los lleva el turno. Sin puertas automáticas, la calidad depende del cuidado de cada día.

Las puertas convierten los criterios del equipo en una comprobación que se hace en cada cambio, antes de aprobar. No sustituyen el juicio de quien revisa: le quitan el trabajo de comprobar lo mecánico para que mire lo que importa.

Abre /repo/politica-de-calidad.txt y /repo/ultima-ejecucion.txt. Cada fila de la ejecución dice, para cada puerta, si la regla pasa o falla. Una regla que falla varias puertas a la vez suele tener un problema de fondo, no un detalle.

La política dice que una regla con alguna puerta en FALLA no se despliega. Cuenta cuántas de las siete reglas están en ese caso: una regla con una sola puerta en FALLA cuenta igual que una con tres.

Abre /repo/estado-de-reglas.csv. La puerta de propietario falla en dos reglas por motivos distintos: una nunca tuvo propietario asignado y la otra tiene como propietaria a alguien que ya no está en el equipo. La segunda es más peligrosa porque parece tener dueño: nadie la recoge y nadie nota que falta.

Entre las reglas que fallan hay dos sin propietario real. Nadie del equipo sabe de memoria qué vigilan, y una de ellas, además, tiene su meta incompleto. El equipo debe decidir cómo tratarlas sin dejar un hueco de detección ni mantener reglas que nadie entiende.