sergio/takana

Esta mañana puse en el §4 la cuenta de nodos por perfil (base 86, cli 153, kde 431…) como si fuera
la clausura de la imagen, y era `build ∪ runtime`: incluía las herramientas de `[solo-build]`, entre
17 y 35 por perfil. La tabla pasa a mostrar las dos columnas y la diferencia, porque el número de
la imagen es el que el §4 necesita y el otro contesta otra pregunta.

Se añade además lo que el documento no decía y es la razón de ser del arreglo: un disparador de
rearmado que se enciende porque cambió un compilador —algo que no entra en la imagen— es el
calendario que este mismo §4 quiere evitar.

Y el pendiente queda con su medición en vez de como suposición: **ninguna imagen declara nada**
—no se escribe ni un `/etc/os-release`, y los aciertos de `grep` en el repo son todos lecturas para
detectar el anfitrión— y además no hay imágenes publicadas: en `/srv/repo` lo que hay son paquetes
`.tkn`.

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

diff --git a/docs/33-versionado-y-relojes.md b/docs/33-versionado-y-relojes.md
index 9574e058..c1e1cbf7 100644
--- a/docs/33-versionado-y-relojes.md
+++ b/docs/33-versionado-y-relojes.md
@@ -143,37 +143,52 @@ banco, 13 del salto y 13 del USB, y las tres corren sin intervención.
 
 ✅ **La primera mitad está construida** (2026-10-10): `scripts/cierre-perfiles.py`, cableado al
 latido y publicando `docs/state/cierres.json`. Ese `h` **no existía** — el grafo sabía el hash de
-cada artefacto y nadie resumía el conjunto — y es lo que convertía el §4 en un pseudocódigo
+cada artefacto y nadie resumía el conjunto — y es lo que convertía este §4 en pseudocódigo
 inejecutable. No construye nada: lee los grafos que el latido acaba de regenerar, en menos de un
 segundo. ⇒ **el `git log` de `cierres.json` ES la señal «este perfil se movió, su imagen quedó
 rancia»**, que hasta hoy no se podía saber sin rearmar para averiguarlo.
 
-| | |
-|---|---|
-| base | 86 nodos | cli | 153 | escritorio-cosmic | 294 |
-| escritorio-gnome | 359 | escritorio-kde | 431 | escritorio-mirada | 41 |
-| escritorio-sway | 281 | metal-tigerlake | 5 | servidor | 186 |
-| servidor-minimo | 117 | | | | |
-
-⚠ **La trampa, medida, que habría dado cierres falsos en silencio: la clausura se calcula en EL
-GRAFO DE SU COLA.** El perfil `base` tiene **86 nodos en `build-state.json` y 78 en
-`build-state-kde.json`**; los 8 que «faltan» —dbus, gmp, libgcrypt, libgpg-error, libnl, mpfr,
-openssl, util-linux— sí están en el grafo de KDE, pero con `perfiles=['escritorio-kde']`, porque
-ahí el nombre `openssl` es la variante de `incoming-kde/` y no la del corpus. Corolario: **un
-digest sólo es comparable consigo mismo a lo largo del tiempo**, nunca entre perfiles ni entre
-grafos. El control lo demuestra: moviendo el hash de `bash` en el grafo del corpus se mueven
-exactamente `base`, `cli`, `servidor` y `servidor-minimo`, y los cuatro escritorios quedan quietos.
+⚠ **De qué conjunto, que es la parte que se puede errar sin enterarse: del cierre de IMAGEN.** La
+primera versión sumó las herramientas de `[solo-build]` —`llvm21`, `go`, `python3`, `cmake`,
+`perl`—, que no van en la imagen porque **la imagen no se construye a sí misma**. Entre 17 y 35
+nodos de más por perfil, en pares (cola,nombre):
+
+```
+perfil               build∪runtime  imagen   solo-build de más
+base                           86      69                  17
+cli                           153     133                  20
+escritorio-cosmic             296     261                  35
+escritorio-gnome              369     337                  32
+escritorio-kde                445     411                  34
+escritorio-mirada              41      23                  18
+escritorio-sway               282     249                  33
+servidor                      186     166                  20
+servidor-minimo               117      99                  18
+```
+
+Con el conjunto equivocado, tocar un compilador movía el digest y decía «rearmá» cuando los bytes
+de la imagen no cambian — **un disparador que se enciende por algo que no entra en la imagen es el
+calendario que este §4 quiere evitar.** La membresía sale de `yupana.membresia_imagen()`, la misma
+vista que `hydrate-profile.py` proyecta al FHS: una sola fuente para «qué lleva esta imagen».
+
+Tres clases de miembro, y las tres se nombran en el informe en vez de desaparecer en el número:
+los **propios** entran por su hash; los **`ajeno`** (xwayland, rust-toolchain-bin,
+steam-runtime-sniper) y los **`wanted`** —declarados por el perfil y sin receta que los provea—
+entran por NOMBRE con su marca, porque no se les puede pedir hash y no aportan bytes, pero el día
+que alguien les escriba la receta la marca pasa a hash y el digest se mueve. `escritorio-kde`
+declara `wanted/xwayland`, y el informe lo dice. Y un cierre **incompleto** no se hashea: un digest
+sobre una clausura parcial diría que la imagen cambió cuando lo que cambió es cuánto sabemos.
+
+Los hashes se indexan por **(cola, nombre)**, porque `openssl` es una receta distinta en `corpus` y
+en `incoming-kde`; comprobado que los cinco grafos no se contradicen (1.288 pares, 0 conflictos), y
+si algún día lo hacen el informe lo grita en vez de elegir uno.
 
 ⚠ **Y el paso que SIGUE faltando: la imagen publicada tiene que declarar de qué clausura salió.**
-Sin eso la comparación «h ≠ el hash de la imagen publicada» no se puede cerrar y el cron volvería a
-ser un calendario. Hoy además **no hay imágenes publicadas** —el sitio no ofrece descargas—, así
-que no hay con qué comparar: lo que está listo es el lado nuestro, y el día que se publique una
-imagen basta con que lleve su `cierres.json` al lado.
-
-Dos cosas que este número NO resume, y las dos a propósito: un cierre **incompleto** no se hashea
-(un digest sobre una clausura parcial diría que la imagen cambió cuando lo que cambió es cuánto
-sabemos), y un nodo **`ajeno`** —xwayland, rust-toolchain-bin, steam-runtime-sniper— entra por
-NOMBRE pero su contenido queda fuera, porque no lo construimos nosotros.
+Medido el 2026-10-10: **ninguna imagen declara nada** — no se escribe ni un `/etc/os-release`; los
+aciertos de `grep os-release` en el repo son todos LECTURAS para detectar el anfitrión. Y además no
+hay imágenes publicadas (el sitio no ofrece descargas; lo que se publica en `/srv/repo` son
+paquetes `.tkn`). Así que lo que está listo es el lado nuestro, y el día que se publique una imagen
+basta con que lleve su entrada de `cierres.json` al lado.
 
 ## 5. Lo que este documento NO decide