`hydrate-profile.py` ya tenía el bloque «quién ensucia la RAÍZ del rootfs», y es bueno: mira por
ARTEFACTO y no sobre el árbol fundido, porque en el fundido el nombre del culpable ya se perdió.
Pero sólo corre al hidratar un perfil ⇒ **sólo ve lo que alguna imagen declara**. Hoy hay **649
recetas que no alcanza ninguna imagen**, y una fase `install` que se equivoca de destino en una de
ésas es invisible hasta el día que alguien la declare.
Lo destapó `qdrant`: selló con **69 M** de cabeceras de protobuf bajo `/src`, y no está en ningún
perfil ⇒ ningún guardián lo habría visto. Lo encontré mirando el árbol del artefacto a mano antes de
promoverlo, que es justo lo que no se puede dejar a que alguien se acuerde.
`--auditar-raices` hace la misma pregunta sobre el STORE ENTERO sin hidratar nada, reutilizando el
mismo `FHS_RAIZ` (una sola definición de «qué puede ir en la raíz», no dos que se desincronizan).
Y dos tablas, porque un barrido que canta tres cosas de las cuales dos son correctas se deja de leer:
· `RAIZ_POR_CONTRATO` — `seed-zig` (el toolchain ES el artefacto) y los rootfs (`store`/`ente` son
suyos por diseño). Se imprimen como ⊘ con el motivo y no cuentan.
· `RAIZ_DEUDA_DECIDIDA` — `perl` y sus 945 páginas nroff en `/`. Es suciedad REAL pero su arreglo
está decidido EN CONTRA por ahora (una línea, 305 rebuilds, va con el próximo bump). Se imprime
como contexto y **no hace fallar**: si fallara siempre, un ofensor NUEVO se perdería entre el ruido
del viejo — que es exactamente cómo se muere un guardián.
Probado con los dos controles, no sólo con el que da verde: sobre un store de juguete con una
suciedad inventada sale **1** y la nombra; quitándola sale **0**. Sobre el store real: 0 ofensores
nuevos sobre 3 artefactos conocidos.
Sergio
beb1c2a597