🎥 cosmic: ScreenCast — dos bloqueos, y el que importa es que NADIE ARRANCA PIPEWIRE

BLOQUEO 1: dbus-send no puede manejarlo, al revés que FileChooser. El
selector se abre con UNA llamada; ScreenCast necesita un handshake de tres
pasos con estado (CreateSession → SelectSources → Start) y la sesión queda
atada a la CONEXIÓN que la creó — cada dbus-send es una conexión distinta
que muere al terminar, así que el paso 2 nunca encuentra la sesión del paso
1. Es límite de la herramienta, no del portal.

Lo que sí se midió: CreateSession FUNCIONA. El frontend devuelve
/org/freedesktop/portal/desktop/request/1_106/sc1 con nuestro handle_token.

BLOQUEO 2, y éste no lo arregla ningún cliente: NO HAY DEMONIO DE PIPEWIRE.

  ls /usr/bin/ | grep -i pipewire  →  pipewire, pipewire-aes67,
                                      pipewire-avb, pipewire-pulse
  ps ax | grep -c pipewire         →  1   (el propio grep)

Los binarios están —el backend del portal enlaza libpipewire-0.3.so— pero el
demonio no corre: cosmic-start no lo lanza y no hay systemd de usuario. O
sea que aunque se escribiera el cliente ashpd, Start no tendría con quién
negociar el stream. Arreglo: lanzarlo desde cosmic-start. Para AUDIO además
falta wireplumber, que ni está construido.

Y se corrigió un comentario DESACTUALIZADO de cosmic-start que decía que
cosmic-settings-daemon «todavía no se puede construir acá (arrastra
pipewire)»: es falso hace tiempo, ese daemon está sellado y corre. Un
comentario viejo manda a buscar un bloqueo que ya no existe, y eso cuesta
igual que un bug.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

docs/runbooks/cosmic-desktop.md

@@ -940,10 +940,42 @@ así que ya no está para recibirla; `dbus-monitor` con un match rule normal tam
 pide un cliente que implemente el ciclo Request/Response — que es justo lo que hace `ashpd` dentro de
 las aplicaciones. **El diálogo está probado; la entrega del fichero a la aplicación, no.**
 
+### 🎥 ScreenCast: dos bloqueos distintos, y el segundo es el que importa
+
+**Bloqueo 1 — `dbus-send` no puede manejarlo, al revés que FileChooser.** El selector se abre con
+UNA llamada; ScreenCast necesita un apretón de manos de tres pasos con estado (`CreateSession` →
+`SelectSources` → `Start`), y la sesión queda atada a la **conexión** que la creó. Cada `dbus-send`
+es una conexión distinta que muere al terminar, así que el paso 2 nunca encuentra la sesión del paso
+1. No es un límite del portal sino de la herramienta: hace falta un cliente `ashpd` de verdad.
+
+Lo que sí se midió con `dbus-send`: `CreateSession` **funciona** — el frontend acepta y devuelve
+`/org/freedesktop/portal/desktop/request/1_106/sc1`, con el `handle_token` que le pasamos.
+
+**Bloqueo 2 — NADIE ARRANCA EL DEMONIO DE PIPEWIRE**, y éste no lo arregla ningún cliente.
+`docs/evidencia/cosmic-screencast-sin-pipewire-2026-08-05.png`:
+
+```
+$ ls /usr/bin/ | grep -i pipewire      →  pipewire, pipewire-aes67, pipewire-avb, pipewire-pulse
+$ ps ax | grep -c pipewire             →  1     (el propio grep: NO hay demonio)
+```
+
+Los binarios están en la imagen —el backend del portal enlaza `libpipewire-0.3.so`— pero el
+**demonio** no corre: `cosmic-start` no lo lanza y no hay systemd de usuario que lo active. O sea que
+aunque se escribiera el cliente `ashpd`, `Start` no tendría con quién negociar el stream.
+
+Arreglo: lanzarlo desde `cosmic-start`. (Para AUDIO además falta `wireplumber`, que ni siquiera está
+construido — ver la decisión de audio del proyecto.)
+
+**Y de paso se corrigió un comentario desactualizado de `cosmic-start`** que decía que
+`cosmic-settings-daemon` «todavía no se puede construir acá (arrastra pipewire)». Es falso hace
+tiempo: ese daemon está sellado y corre. Un comentario viejo manda a buscar un bloqueo que ya no
+existe, y eso cuesta igual que un bug.
+
 ## Lo que falta, en orden
 
-1. **`ScreenCast`**, que es la que ejercita pipewire de verdad, y la entrega de URI del `FileChooser`
-   con un cliente `ashpd` real en vez de `dbus-send`.
+1. **Arrancar el demonio de pipewire desde `cosmic-start`**, que es lo que destraba ScreenCast de
+   verdad; después, un cliente `ashpd` para ejercer el handshake y, de paso, capturar la URI del
+   `FileChooser` que `dbus-send` no puede ver.
 2. **Decidir `gvfs`** (ver la corrección de arriba: las piezas ya están selladas, lo que falta es la
    decisión sobre la segunda glib). Destrabaría los montajes remotos de cosmic-files y su applet.
 3. **Enchufar la tienda a `.swm`**: servir `org.freedesktop.PackageKit` y encender la feature

scripts/cosmic/cosmic-start-qemu.sh

@@ -171,10 +171,21 @@ if [ ! -f "$HOME/.config/qalculate/qalc.cfg" ]; then
 fi
 
 # ── MODO: bare (default) o session ──────────────────────────────────────────────────────────────
-# `cosmic-session` es el camino de producción, pero HOY no se puede usar: llama a
-# `cosmic-settings-daemon` con `.expect("failed to start settings daemon")` (src/main.rs:255) y
-# PANICKEA si no está — no es opcional ni está detrás de una feature. Y ese daemon todavía no se
-# puede construir acá (arrastra pipewire; ver el runbook).
+# `cosmic-session` llama a `cosmic-settings-daemon` con
+# `.expect("failed to start settings daemon")` (src/main.rs:255) y PANICKEA si no está — no es
+# opcional ni está detrás de una feature.
+#
+# ⚠ **DESACTUALIZADO Y CORREGIDO (2026-08-05)**: acá decía que ese daemon «todavía no se puede
+# construir acá (arrastra pipewire)». Es falso desde hace tiempo — `cosmic-settings-daemon` está
+# sellado y corre, y `pipewire` está en la imagen. Se deja el rastro porque el comentario viejo
+# mandaba a buscar un bloqueo que ya no existe.
+#
+# Lo que SÍ falta, y es otra cosa: **nadie ARRANCA el demonio de pipewire**. `/usr/bin/pipewire` y
+# `pipewire-pulse` están instalados, pero `ps ax | grep pipewire` en la sesión no devuelve nada, y
+# este script no lo lanza. Consecuencia medida: el portal acepta
+# `org.freedesktop.portal.ScreenCast.CreateSession` y devuelve su objeto Request, pero **no puede
+# haber stream** porque no hay demonio con quien negociarlo. Sin systemd de usuario, lanzarlo es
+# tarea de este script. (Para audio además falta `wireplumber`, que ni siquiera está construido.)
 #
 # El modo `bare` es la otra mitad que upstream ya soporta (`make install-bare-session`): el
 # compositor se lanza SOLO y los clientes se levantan a mano contra su WAYLAND_DISPLAY. Sirve para lo