diff --git a/docs/evidencia/gnome-shell-qemu-2026-07-29.png b/docs/evidencia/gnome-shell-qemu-2026-07-29.png
index 30e05aa4..5aab2d2e 100644
Binary files a/docs/evidencia/gnome-shell-qemu-2026-07-29.png and b/docs/evidencia/gnome-shell-qemu-2026-07-29.png differ
diff --git a/docs/runbooks/gnome-qemu-desktop.md b/docs/runbooks/gnome-qemu-desktop.md
index 734811d8..6dc1cc34 100644
--- a/docs/runbooks/gnome-qemu-desktop.md
+++ b/docs/runbooks/gnome-qemu-desktop.md
@@ -100,14 +100,42 @@ datos del demonio, es una interfaz publicada que consume otro programa.
    esperar a que la imagen esté hecha Y no haya otro QEMU con el disco tomado (`Failed to get "write"
    lock` es el aviso de que hay uno vivo).
 
+### Iconos y cursor: `adwaita-icon-theme` (cerrado)
+
+`No cursor theme available` no era cosmético: **con el cursor por software** —obligatorio en
+virtio-gpu con render software— mutter dibuja la imagen que le da el tema, y sin tema el puntero se
+movía invisible. Con `adwaita-icon-theme` (+ `hicolor-icon-theme`, que su `index.theme` hereda) el
+cursor aparece y la notificación del shell tiene su icono. Colores distintos: 582 → 629.
+
+Dos gotchas de esas dos recetas: **hicolor 0.18 pasó de autotools a meson** (su tarball ya no trae
+`configure`, y un `./configure` heredado sale con 127), y adwaita declara `gtk-update-icon-cache`
+como `required: true` para un `add_install_script` que **su propio autor marcó
+`skip_if_destdir: true`** — exige un binario que en un build empaquetado no puede ejecutar. Se borran
+los dos bloques; `required: false` no alcanza porque meson no propaga el disabler ahí dentro.
+
+### El setuid del launch-helper: una causa, dos síntomas (cerrado)
+
+`dbus-daemon-launch-helper` es el que `dbus-daemon` ejecuta para activar un servicio del bus de
+SISTEMA bajo demanda, y **comprueba sus propios permisos antes de hacer nada**: si no es setuid root
+se niega, y el cliente recibe `The permission of the setuid helper is not correct` — que es lo que
+reportaba colord. Sin eso **ninguna** activación por bus de sistema funciona. La imagen ahora lo deja
+`root:messagebus 4750`, y el síntoma de colord cambió de «permiso incorrecto» a «timed out»: la
+activación ya se intenta de verdad, y lo que queda es del demonio, no del bus.
+
 ### Lo que queda, y ninguno impide el escritorio
 
-- `Failed to activate service 'org.freedesktop.UPower': timed out` — falta lanzar `upowerd` en
-  `gnome-start`, como se hace con `accounts-daemon`.
-- `No cursor theme available` — falta un tema de cursor (adwaita-icon-theme).
-- colord no arranca: su helper setuid no tiene los permisos correctos en la imagen.
+- **UPower**: `gnome-start` lanza `upowerd` y **verifica que siga vivo** (lo hace: «upowerd sigue
+  vivo»), pero el nombre `org.freedesktop.UPower` no aparece en el bus y el shell espera sus 25 s.
+  Su política D-Bus está bien (`allow own` para root, verificado en el artefacto), así que el proximo
+  paso es mirar el log del propio upowerd —probablemente se queda enumerando por gudev sobre
+  libudev-zero—. Es el indicador de batería en una VM sin batería.
+- **colord**: activación por bus ya permitida, el demonio no llega a arrancar. Es gestión de color.
 - `Missing required core component Settings` — es gnome-control-center, que no está en el corpus.
 
+**Lección de las dos anteriores, que ya costó una iteración: un pid no es un servicio.** La primera
+versión del lanzamiento de upowerd decía «lanzado» y el shell seguía esperando; reportar el arranque
+de un daemon sin comprobar que adquirió su nombre es reportar una intención, no un hecho.
+
 ## CÓMO SE CERRÓ LA CAPA JS (2026-07-29)
 
 Era el muro anterior, y quedó cerrado. Vale la pena dejar cómo, porque el método es reusable.