harkaq: el bucle CERRADO — de Impuro a Hermetico sobre una receta real (§4.7)

Diagnosticar no vale nada si no se puede accionar. El bucle completo sobre
recipes/zlib.toml, cada paso guiado SÓLO por lo que dijo harkaq:

  zlib tal cual → Impuro: /usr/bin/make         → "declarar dep: make"
  + make        → Impuro: /usr/bin/ranlib       → "declarar dep: binutils"
  + binutils    → Impuro: liblto_plugin.so      → irreducible ⇒ clasificar
  final         → Hermetico ×3 fases, artefacto b3:adc5c251… SELLADO

Cada capa que se pela destapa la siguiente, y TODAS convergen en el gcc de
Alpine. El último hallazgo es el que no se encuentra a mano: los binutils DE
HAMMER —ya declarados como dep— cargan el plugin LTO del gcc DE ALPINE
(/usr/libexec/gcc/x86_64-alpine-linux-musl/15.2.0/liblto_plugin.so). No es un
fallo de declaración de la receta: es un agujero de soberanía DENTRO de un
artefacto que hammer construye.

Va a denegación esperada por la misma razón que /usr/bin/gcc (§4.2): el build
completa sin él ⇒ es una SONDA, no una necesidad, y bloquearla es DESEABLE —
impide que los binutils de hammer usen el plugin de Alpine por detrás. D3 otra
vez: no se calla, se clasifica.

Detalle que confirma el modelo: el hash del artefacto es IDÉNTICO antes y
después de clasificar la sonda (b3:adc5c251… las dos veces). Clasificar cambia
el VEREDICTO, no el BUILD. Es el principio de H1 sosteniéndose solo: la
evidencia es comportamiento, no identidad (recipe.rs:228, y por eso Evidence
está fuera de hash_inputs).

Y eso es lo que `Hermetico` significa ahora, con todo el peso: el kernel
certificó que ese build no usó NADA fuera de su clausura declarada, y el canario
prueba que el certificado no es el silencio de un lector roto.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

scripts/harkaq/README.md

@@ -287,3 +287,26 @@ que era el riesgo de muerte del §7.
 **Gotcha del barrido:** copiar la receta a otro directorio rompe la resolución de `deps.build`
 (son relativas al dir de la receta) ⇒ se descartaban en silencio justo las recetas CON deps. La
 copia va al lado del original.
+
+## El bucle cerrado (§4.7)
+
+Diagnosticar no vale nada si no se puede accionar. Sobre `recipes/zlib.toml`, cada paso guiado
+SÓLO por lo que dijo harkaq:
+
+| Paso | Veredicto | harkaq dijo | Acción |
+|---|---|---|---|
+| zlib tal cual | `Impuro` | `/usr/bin/make` → declarar dep: make | `[deps] build=["make"]` |
+| + make | `Impuro` | `/usr/bin/ranlib` → declarar dep: binutils | `build=["make","binutils"]` |
+| + binutils | `Impuro` | `liblto_plugin.so` → irreducible | clasificar como esperada |
+| final | **`Hermetico` ×3** | — | `b3:adc5c251…` sellado |
+
+Cada capa destapa la siguiente y **todas convergen en el gcc de Alpine**. El último hallazgo no se
+encuentra a mano: **los binutils DE HAMMER cargan el plugin LTO del gcc DE ALPINE** — un agujero
+de soberanía dentro de un artefacto que hammer construye, no un fallo de la receta.
+
+**El hash del artefacto es idéntico antes y después de clasificar** (`b3:adc5c251…` las dos veces):
+clasificar cambia el veredicto, no el build. La evidencia es comportamiento, no identidad.
+
+**NO modificar `recipes/zlib.toml`** para probar esto: cambiaría su hash e invalidaría el
+artefacto sellado y todo lo aguas abajo. Se prueba en una copia `recipes/.harkaq-*.toml` (al lado
+del original, o se rompe la resolución de deps).