diff --git a/CLAUDE.md b/CLAUDE.md
index 3612b3c..c5c7c6f 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -67,16 +67,30 @@ Kuma cae → notificación «n8n Auto-Restart» → webhook público de n8n →
 `restartedAt`. Antes no reiniciaba nada (sin RBAC: 403), y sus «éxitos» eran el
 aviso de FALLO enviándose bien.
 
-- La SA es `n8n-restarter`, con **un RoleBinding por namespace** (ver
-  `n8n/rbac-restarter.yaml`). Si añades un servicio al `SERVICE_MAP` del
-  workflow, hace falta también su RoleBinding o dará 403.
+- La SA es `n8n-restarter`. Desde el **2026-07-31** son **Roles por namespace
+  con `resourceNames`** sobre los 12 workloads exactos del `SERVICE_MAP` (ver
+  `n8n/rbac-restarter.yaml`), no un ClusterRole abierto. Si añades un servicio
+  al mapa, **hay que añadirlo también ahí** o dará 403 — deliberado: el mapa y
+  el permiso se mueven juntos.
+  Motivo: esa SA va montada en el **pod entero** de n8n y los nodos Code leen el
+  token de `/var/run/secrets/…`, así que cualquier workflow con un nodo Code
+  hereda lo que se conceda aquí. El límite no es el mapa, es el RBAC.
 - La clave del mapa es el **nombre exacto del monitor en Kuma**. Renombrarlo
   allí lo desconecta en silencio.
 - El webhook exige la cabecera `X-Kuma-Token` (secret `n8n-kuma-webhook`, fuera
-  de git). Sin secreto configurado la comprobación se salta a propósito, para
-  que un despiste no te deje sin avisos.
+  de git) y desde el **2026-07-31 falla en CERRADO**: el `env` ya no lleva
+  `optional`, así que sin secreto el pod no arranca, y la puerta lanza error si
+  la variable falta. Antes se saltaba la comprobación «para no quedarte sin
+  avisos», y ese argumento era falso: el aviso de caída lo manda Kuma por su
+  notificación 1, directa, no por este webhook.
 - Para apps bajo ArgoCD, el `restartedAt` se **revierte** tras el reinicio. El
-  pod sí se reinicia; la anotación no queda. No es un fallo.
+  pod sí se reinicia; la anotación no queda. No es un fallo. Por eso el éxito se
+  comprueba con `observedGeneration >= la generation que devolvió el PATCH`, y
+  con `>=` y no con `==`: la reversión vuelve a subir la generation.
+- **Cómo saber por qué rama fue una ejecución** cuando `SAVE_ON_SUCCESS=none` ya
+  la ha vaciado: por la duración. `deletedAt - startedAt` (con el offset fijo de
+  1 h) da ~0,02 s si la puerta rechazó, ~0,3 s si el PATCH falló y se fue por la
+  rama de fallo, y ~60 s si hizo el ciclo completo con su espera.
 
 ## Un workflow que termina en verde no dice que haya hecho su trabajo