From 9273880745325e8e3e069a568a811e42c3ef1c74 Mon Sep 17 00:00:00 2001 From: sergio Date: Sat, 8 Aug 2026 12:25:31 -0400 Subject: [PATCH] =?UTF-8?q?docs:=20por=20qu=C3=A9=20KDE=20est=C3=A1=20en?= =?UTF-8?q?=2076/162=20=E2=80=94=20los=20artefactos=20NO=20EXISTEN,=20y=20?= =?UTF-8?q?la=20causa=20es=20estructural?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Diagnóstico completo. No es daño de la campaña del split ni un fallo de store-gc. LO MEDIDO, en orden: 1. 86 nodos del perfil sin artefacto en su hash vigente. 2. NO lo causó el split: revertidas una por una todas las recetas tocadas hoy (3 bibliotecas base, 30 hojas, dbus, 38 de la 2ª tanda) el número NO se movió de 198 en ningún caso. 3. La FRONTERA son 7 recetas —las únicas cuyas deps sí están al día—: dbus, libnl, libpcap, libxkbcommon, lm-sensors, perl-xml-parser, vulkan-loader. Las otras 79 cuelgan de ellas. 4. Las 7 son SOMBRAS de incoming-kde, no las canónicas. Las del corpus están al día, y por eso el problema es INVISIBLE desde el grafo del corpus — que es justo el que yo miraba. 5. No fue store-gc: sus hashes vigentes no figuran en ningún manifiesto de borrado, y tres nunca se podaron. (Lo sospeché porque la regla de «superado» es por NOMBRE y una sombra comparte nombre con la canónica; la sospecha era razonable y los manifiestos la descartan.) 6. Ni el hub ni el worker los tienen. No están en otro sitio: NO ESTÁN. LA CAUSA DE FONDO, que importa más que KDE: la cola se construyó en workers EFÍMEROS, el sync del store es unidireccional (worker→hub) y esos workers ya no existen. Cuando algo del sustrato compartido cambió después, las sombras se re-hashearon y nadie las reconstruyó, porque el hub nunca fue la máquina donde vivía ese escritorio. ⇒ Con flota efímera y sync unidireccional, un escritorio puede dejar de ser reconstruible-desde-el-store SIN QUE NINGÚN INDICADOR LO DIGA. El grafo seguía reportando 162/162 desde un JSON generado semanas antes. Coste de arreglarlo: 86 reconstrucciones en la granja, empezando por las 7 de la frontera. No hay muro técnico conocido — son recetas que ya construyeron. Es cómputo, no investigación. Co-Authored-By: Claude Opus 5 (1M context) --- docs/20-catalogo-publicable-y-completa.md | 34 +++++++++++++++++++++++ 1 file changed, 34 insertions(+) diff --git a/docs/20-catalogo-publicable-y-completa.md b/docs/20-catalogo-publicable-y-completa.md index 2a382f8b..51fcb06b 100644 --- a/docs/20-catalogo-publicable-y-completa.md +++ b/docs/20-catalogo-publicable-y-completa.md @@ -313,3 +313,37 @@ aparecer en el grafo. ⇒ Cuando este documento diga que algo «cierra», leelo como *se puede intentar*, no como *funciona*. La distancia se paga una vez por perfil y se paga entera. Los tres escritorios que aún no se validaron con pantalla la deben. + +--- + +## 8. Por qué `escritorio-kde` está en 76/162 — diagnóstico (2026-08-08) + +**No es daño de la campaña del split**, y tampoco es un fallo de `store-gc`. Es más simple y más +incómodo: **esos artefactos no existen en ninguna parte**. + +### Lo que se midió, en orden +1. **86 nodos del perfil sin artefacto en su hash vigente.** +2. **No lo causó el split**: se revirtieron una por una todas las recetas tocadas hoy —las 3 + bibliotecas base, las 30 hojas, `dbus`, las 38 de la 2ª tanda— y el número **no se movió**. +3. **La FRONTERA de la deriva son 7 recetas** (las únicas cuyas deps sí están al día): + `dbus`, `libnl`, `libpcap`, `libxkbcommon`, `lm-sensors`, `perl-xml-parser`, `vulkan-loader`. + Las otras 79 cuelgan de ellas. +4. **Las 7 son SOMBRAS de `incoming-kde`**, no las canónicas. Las del corpus están perfectamente al + día — por eso el problema es invisible desde el grafo del corpus. +5. **No fue `store-gc`**: sus hashes vigentes no figuran en ningún manifiesto de borrado, y tres de + ellas (`libpcap`, `lm-sensors`, `vulkan-loader`) nunca se podaron. +6. **Ni el hub ni el worker los tienen.** No están «en otro sitio»: no están. + +### La causa de fondo, y por qué importa más que KDE +La cola KDE se construyó en workers EFÍMEROS. El sync del store es **unidireccional** (worker→hub) y +esos workers ya no existen. Cuando algo del sustrato compartido cambió después de aquella campaña, +las sombras de KDE se re-hashearon y **nadie las reconstruyó**, porque el hub nunca fue la máquina +donde vivía ese escritorio. + +⇒ **Con flota efímera y sync unidireccional, un escritorio puede dejar de ser reconstruible-desde-el- +store sin que ningún indicador lo diga.** El grafo seguía reportando 162/162 en un JSON generado +semanas antes, y sólo se vio al regenerarlo. + +### Qué cuesta arreglarlo +**86 reconstrucciones en la granja**, empezando por las 7 de la frontera. No hay muro técnico +conocido: son recetas que ya construyeron alguna vez. Es tiempo de cómputo, no investigación.