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>

docs/16-harkaq-jaula.md

@@ -775,6 +775,37 @@ resolución de `deps.build` (son relativas al directorio de la receta) ⇒ brotl
 pude cargar la dep 'cmake'" y se descartaba en silencio. Se descartaban **justo las recetas con
 deps, que son las interesantes**. La copia va al lado del original.
 
+### 4.7 El bucle cerrado: de `Impuro` a `Hermetico` sobre una receta real
+
+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:
+
+| Paso | Veredicto | Lo que dijo harkaq | 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 (ver abajo) |
+| 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 más interesante y no lo habría encontrado 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 problema de
+declaración de la receta: es un agujero de soberanía *dentro de un artefacto que hammer construye*.
+
+Va a **denegación esperada**, y 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 esto 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.
+
 ---
 
 **Fase 2 — `harkaq-policy` completo + medir la brecha.** Clausura real, `/src`, `/out`, `/tmp`,

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).