SDD 27 §9: kate no es «de KDE» — la herencia hace dos trabajos y sólo uno es herencia

El usuario preguntó si va a poder ejecutar kate desde mirada o si kate «está para KDE y no se
hereda». La pregunta separa dos cosas que hoy comparten un solo mecanismo: qué CONTIENE un
metapaquete (lo que resolvió el §7.1) y qué PUEDE CORRER en un sistema.

MEDIDO sobre la clausura de kate: son 110 recetas, y lo único que suena a Plasma —kwindowsystem,
plasma-activities, plasma-wayland-protocols— son LIBRERÍAS. No aparece plasmashell, ni kwin, ni
plasma-workspace. O sea que kate necesita Qt6 + KF6 + un compositor, y mirada TIENE compositor: que
hoy no corra ahí no es técnico, es que no está instalado. Coste medido: mirada son 41 nodos, kate
110, ya coinciden 24 ⇒ faltan 86, que es traerse Qt6 y KF6. Ese precio no lo cobra KDE, lo cobra Qt.

Y la distinción YA EXISTE en el repo sin estar nombrada: mpv, atuq, swayimg y libnotify están
declaradas en los CUATRO escritorios —repetidas, no heredadas—, zathura en tres, foot en dos. El
repo ya trata las apps distinto de kwin, sólo que copiando la línea en cada perfil.

Propuesta escrita: que el metapaquete del escritorio sea el ESCRITORIO (shell, compositor, tema,
ajustes) y que las apps salgan a metapaquetes propios instalables desde cualquier sistema, de modo
que `takana install kate` funcione desde mirada sin instalar Plasma. Se lleva bien con el §8: con
vistas montables, «tengo KDE y GNOME y elijo en el greeter» y «uso kate dentro de GNOME» dejan de
ser dos problemas y pasan a ser uno solo — qué clausura se compone para esta sesión.

Cuesta mover ~20 declaraciones de targets.toml y no toca ninguna receta ni ningún artefacto: es
reclasificar, no reconstruir.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LCt3ettR4Z7b6wPCBmbvEV

docs/27-perfiles-instalables-y-el-instalador.md

@@ -187,3 +187,64 @@ palabra entra en algún hash o en el índice del repo.
 sí**. Unificar imagen e instalador sobre un `/usr` proyectado es construir sobre el supuesto de que
 sólo hay un escritorio a la vez. Antes de unificarlos conviene decidir si el destino es un FHS
 plano o una vista composefs, porque es la diferencia entre «instalás uno» y «instalás los tres».
+
+## 9. Herencia hace DOS trabajos distintos, y sólo uno es herencia
+
+La herencia del §7.1 contesta *«¿qué **contiene** este metapaquete?»*. El usuario preguntó otra cosa:
+
+> *¿voy a poder ejecutar un kate desde mirada, o kate está para KDE y no se hereda?*
+
+Eso es *«¿qué **puede correr** en este sistema?»*, y hoy se confunde con lo anterior porque hay un
+solo mecanismo.
+
+### `kate` no es «de KDE» técnicamente — lo es sólo por empaquetado
+
+Medido el 2026-09-09 sobre la clausura de `recipes/incoming-kde/kate.toml`:
+
+- **110 recetas** en total.
+- Lo único que suena a Plasma son `kwindowsystem`, `plasma-activities` y
+  `plasma-wayland-protocols` — y **las tres son librerías**, no el shell. La última es literalmente
+  XML de protocolo.
+- **No aparece `plasmashell`, ni `kwin`, ni `plasma-workspace`.**
+
+⇒ kate necesita Qt6 + KF6 + un compositor Wayland. Mirada **tiene** compositor. Que hoy no se pueda
+ejecutar desde mirada no es una limitación técnica: **es que no está instalado**.
+
+Coste medido de tenerlo ahí: la clausura de `escritorio-mirada` son 41 nodos, la de kate 110, y
+**24 ya están** ⇒ habría que sumar **86**, que es esencialmente traerse Qt6 y KF6. Y ese precio es
+el mismo desde mirada que desde sway: no lo cobra KDE, lo cobra Qt.
+
+### Las tres clases, y sólo la primera es herencia
+
+| clase | qué es | ¿se hereda? |
+|---|---|---|
+| **piso** | `base` + `cli` | **sí** — todo sistema lo tiene (hecho en §7.1) |
+| **escritorio** | `plasmashell`, `kwin`, `breeze`, `powerdevil`, `kscreen` | **no, y no tiene sentido**: son la implementación de *ser* KDE. Correr `kwin` desde mirada no significa nada, mirada ya tiene compositor |
+| **aplicaciones** | `kate`, `okular`, `dolphin`, `gwenview`, `ark`, `spectacle`… | **no se heredan: se INSTALAN**. Hoy están dentro del metapaquete del escritorio, y ahí está el error de clasificación |
+
+### La prueba de que la distinción ya existe sin estar nombrada
+
+`mpv`, `atuq`, `swayimg` y `libnotify` **están declaradas en los CUATRO escritorios** — repetidas,
+no heredadas. `zathura` en tres, `foot` en dos. O sea que el repo **ya trata las apps distinto de
+`kwin`**, sólo que copiando la línea en cada perfil en vez de decirlo.
+
+Y el mecanismo también existe a medias: esas cuatro viven en el CORPUS y no en una cola, con el
+comentario explícito de que es «justamente para poder listarse en las cuatro». Falta el último paso.
+
+### Propuesta
+
+Que `escritorio-kde` sea **el escritorio** —shell, compositor, tema, ajustes, energía— y que las
+apps salgan a metapaquetes propios: `kate` suelto, o agrupadas en algo tipo `kde-apps`, instalables
+desde cualquier sistema. Con eso la pregunta del usuario se contesta sola:
+
+    takana install kate      # desde mirada, desde sway, desde donde sea
+
+trae sus 86 recetas faltantes y funciona, **sin instalar Plasma**.
+
+⚠ Y esto se lleva bien con el §8: si un escritorio es una VISTA montable y las apps son
+metapaquetes aparte, entonces «tengo KDE y GNOME instalados y elijo en el greeter» y «uso kate
+dentro de mi sesión de GNOME» dejan de ser dos problemas distintos. Son el mismo: qué clausura se
+compone para esta sesión.
+
+**Coste**: mueve unas 20 declaraciones de `targets.toml` y no toca ni una receta ni un artefacto —
+es reclasificar, no reconstruir. No se hizo todavía porque es decisión de diseño, no de limpieza.