Documentar activación del timer y el gotcha de HOME= en systemd --user

Timer activo desde 2026-08-26. Documenta el hallazgo en vivo: el
manager de systemd --user de devops arranca con HOME=/DATA (el de
/etc/passwd), no con el override de /etc/profile.d/zz-devops-home.sh
que solo aplica a shells interactivas -- sin Environment=HOME=... en
la unidad, claude -p habría fallado la autenticación en cada corrida
del timer, silenciosamente. Se detectó y corrigió antes de activar,
corriendo el servicio manualmente vía systemctl --user start con el
entorno real como último paso de validación.

workloads/docs-portal/docs/arquitectura/agente-monitoreo.md

@@ -8,9 +8,10 @@ como decisión de gobernanza — la lista blanca de abajo es lo que
 autoriza al agente a actuar sin intervención humana, y debe poder
 auditarse.
 
-Estado: **script y prueba end-to-end validados en vivo (2026-08-26)**.
-El timer de systemd (automatización continua) **todavía no está
-activo** — pendiente de decisión explícita para habilitarlo.
+Estado: **timer de systemd ACTIVO desde 2026-08-26** (`lab-agent.timer`,
+usuario `devops`, cada 15 min entre 06:00–23:00 hora local). Script,
+Telegram y las unidades systemd, todo validado en vivo antes de
+activar.
 
 ## Lista blanca de acciones correctivas automáticas
 
@@ -258,15 +259,36 @@ promedio estadísticamente robusto, es una primera estimación para
 decidir si el timer se activa. Revisar el costo real después de la
 primera semana en producción y ajustar frecuencia/modelo si hace falta.
 
-## Pendiente antes de activar el timer en continuo
+## Activación del timer (2026-08-26)
+
+Habilitado tras confirmación explícita del propietario del lab, viendo
+antes el costo mensual estimado. Unidad de usuario (`systemctl --user`,
+corre como `devops`, no `root`), con límites de CPU/memoria (`CPUQuota`,
+`MemoryMax`) — instalada en `/DATA/.config/systemd/user/`, no en el
+`~/.config/...` de una shell interactiva.
+
+**Gotcha encontrado y corregido en vivo:** el manager de `systemd
+--user` de `devops` arranca con `HOME=/DATA` (el valor de
+`/etc/passwd`), no `/DATA/AppData/home-devops` — ese override solo se
+aplica al abrir una shell interactiva vía
+`/etc/profile.d/zz-devops-home.sh`, que el manager de systemd nunca
+carga. Sin corregirlo, `claude -p` habría buscado
+`~/.claude/.credentials.json` en `/DATA/.claude/` (no existe) y la
+autenticación habría fallado en cada corrida del timer, silenciosamente,
+hasta la primera vez que alguien mirara el log. `lab-agent.service`
+fija `Environment=HOME=/DATA/AppData/home-devops` explícitamente para
+evitarlo. Se detectó y corrigió *antes* de habilitar el timer, corriendo
+el servicio manualmente vía `systemctl --user start` con el entorno
+real (no desde una shell interactiva) como último paso de validación.
+
+También requirió `sudo loginctl enable-linger devops` (una vez) — sin
+eso, `systemctl --user` ni siquiera conecta (no hay `/run/user/<uid>`
+sin una sesión de login o linger activo).
+
+**Pendiente, no bloqueante:**
 
-- **Confirmación explícita del propietario del lab** para habilitar el
-  timer de systemd — no se activa automáticamente solo por haber
-  pasado la prueba end-to-end ni por tener el costo estimado.
-- Unidad systemd de usuario (`systemctl --user`, corre como `devops`,
-  no `root`), con límites de CPU/memoria (`CPUQuota`, `MemoryMax`).
-  Requiere `loginctl enable-linger devops` (una vez, con sudo) para que
-  seguir corriendo sin sesión interactiva activa.
 - Opcional: `GITEA_TOKEN_FILE` para activar la señal de "runner
   atascado" vía API de Gitea Actions (hoy se omite, degradación segura).
-- Decidir la tensión con la ventana de `medusa-deploy` (ver arriba).
+- Decidir la tensión con la ventana de `medusa-deploy` (ver arriba) —
+  sigue sin resolver, el timer se activó igual porque no bloquea el
+  resto de la lista blanca.