1# SDD 16 — harkaq: la jaula de hammer
2
3**Estado:** Draft 2 · **Fecha:** 2026-07-15 · **Nombre provisional:** *harkaq* ("el que detiene"; renombrable, ningún identificador depende del nombre)
4
5> **Qué cambió del Draft 1.** El Draft 1 se escribió contra el sandbox de nix. hammer no usa nix
6> para construir: usa bubblewrap (ADR 0004, `crates/hammer-build/src/sandbox.rs`). Eso invalidó
7> por irrelevancia ~40% del documento — el argumento anti-nix, las FOD y su red abierta, y la fase
8> del *fetcher mediado* que era el mayor riesgo de cronograma. Fase 0 (reconocimiento) se ejecutó
9> y sus tres mediciones están en §3. El resultado neto es un proyecto **más chico, más barato y
10> con un beneficio que cobra antes**. Lo que sobrevive intacto es el corazón: D1 (política
11> derivada), D2 (evidencia negativa) y D3 (cero quieting).
12
13**Tesis:** hammer es una distro cuyo autor es un modelo. Su sandbox (bwrap) fue diseñado para dar
14*hermeticidad de facto* — aislar el build del host — no para *probar* hermeticidad ni para acotar
15lo que el build usa **de adentro de la jaula**. harkaq cierra esa brecha sin pedirle política a
16nadie: **la clausura de entradas declaradas de la receta ya es la política**. El subproducto es
17más valioso que el producto — la ausencia de denegaciones bajo una política igual a la clausura
18es *evidencia mecánica* de que lo declarado **basta**, encadenable en willay y consumible por iniy.
19
20---
21
22## 0. Por qué esto no lo resuelve bwrap
23
24El sandbox actual (`sandbox.rs:224`) hace bien lo que se propuso hacer:
25
26- `--unshare-all` — netns, pidns, mountns, ipcns, utsns, userns. **Sin red, ya hoy.**
27- `--overlay-src <rootfs Alpine> [--overlay-src <dep>…] --tmp-overlay /` — base y deps de solo
28  lectura, escrituras a una capa tmpfs descartable.
29- `--bind <src> /src`, `--bind <out> /out` — las únicas dos superficies RW reales.
30- Entorno mínimo y fijado (`SOURCE_DATE_EPOCH`, `CC`, `-mcpu=baseline`, `CARGO_BUILD_JOBS=1`).
31
32Eso da hermeticidad **respecto del host**. La brecha no está ahí. Está adentro:
33
34> **El sandbox monta un rootfs Alpine entero como capa base del overlay.**
35
36O sea `política ⊋ clausura`, por un margen enorme. Una receta puede usar cualquier header,
37cualquier `.so`, cualquier binario que Alpine traiga — **sin declararlo en `deps`** — y el build
38pasa en verde. El artefacto queda sellado y reproducible, y aun así arrastra una dependencia
39fantasma que nadie escribió.
40
41Ese no es un bug hipotético: es exactamente el bug que la campaña de **de-Alpinización** viene
42cazando *a mano, receta por receta*, leyendo logs y adivinando. El patrón documentado (strip
43`makedepends`, fase configure explícita, `.pc Requires` → `[deps].build`) es el parche manual de
44un problema que el kernel puede diagnosticar solo.
45
46**La inversión que hace hammer:** el sandbox de bwrap asume que quien escribe la receta sabe lo
47que declaró. En hammer, quien escribe la receta es un modelo, la receta se importa
48automáticamente desde nixpkgs/Alpine, y "lo que declaró" es precisamente la parte que falla.
49Nadie más tiene ese problema porque nadie más tiene una distro cuyo autor sea un modelo.
50
51**No-tesis:** esto no reemplaza a bwrap. harkaq **compone** con él (§5, D4): la jaula de mount y
52namespaces sigue siendo de bwrap; harkaq agrega la política de grano fino y —lo que importa— el
53canal de evidencia.
54
55### 0.1 El lugar exacto en el modelo de confianza
56
57De `hammer-core/src/recipe.rs:229`, sobre la evidencia H1 (proof-carrying recipes, SDD 15):
58
59> *"Frontera honesta: garantiza que **lo declarado pasa**, no que **lo declarado basta**."*
60
61harkaq es el complemento simétrico de esa frase, y por eso encaja sin forzar nada:
62
63| | Pregunta | Mecanismo | Evidencia |
64|---|---|---|---|
65| **H1** | ¿lo declarado **pasa**? | checks corridos en el sandbox | positiva (los checks pasan) |
66| **harkaq** | ¿lo declarado **basta**? | política = clausura, en el kernel | negativa (nadie denegó nada) |
67
68Juntas cierran el cuadro: H1 dice que el artefacto *hace lo que dice*; harkaq dice que *no
69necesitó nada que no dijo*. Ninguna de las dos pide confiar más en el modelo. Las dos piden
70verificar más — que es el principio declarado de SDD 15 §0.
71
72---
73
74## 1. Metas
75
761. Ejecutar el builder bajo una política **derivada, no escrita**: `política = clausura(deps declaradas)`.
772. Producir, por cada build, un veredicto de hermeticidad con evidencia:
78   `hermético ⟺ política = clausura ∧ denegaciones = ∅`.
793. Emitir esa evidencia hacia willay/iniy, direccionada por blake3, como un `kind` nuevo junto a
80   la evidencia H1.
814. **Convertir la de-Alpinización en un diagnóstico mecánico**: cada denegación nombra el path,
82   el dev y el ino de lo que el build usó sin declarar.
835. Degradación explícita y declarada: en kernel sin Landlock, harkaq marca el build **sin
84   evidencia** — nunca finge.
85
86## 2. No-metas
87
88- No corre en wawa. Ver D6.
89- No reemplaza el sandbox de bwrap; se compone encima. Defensa en capas.
90- No es un contenedor de propósito general ni compite con bubblewrap/landrun.
91- v1 no cubre macOS (hammer es musl/Linux).
92- No promete contener un exploit de kernel. Ver §8.
93- **No reabre ADR 0004.** hammer no adopta nix como backend de build. Esa opción sigue diferida
94  y harkaq no la necesita.
95
96---
97
98## 3. Fase 0 — Reconocimiento: EJECUTADA (2026-07-15)
99
100El Draft 1 estimaba "días". Fueron cinco minutos, porque las tres preguntas tenían respuesta
101mecánica. Las tres respuestas están medidas, no supuestas.
102
103### 3.1 ABI de Landlock
104
105Medido con el syscall (`landlock_create_ruleset(NULL, 0, LANDLOCK_CREATE_RULESET_VERSION)`), que
106es la vía correcta: los kernels de otras fuentes traen features backporteadas y **el número de
107versión del kernel miente** (RHEL 9.6 backporteó hasta ABI 5 sobre un 5.14).
108
109| Dónde | Kernel | ABI | Veredicto |
110|---|---|---|---|
111| Laptop de desarrollo | 7.2.0-rc3-1-cachyos-rc | **10** | techo; todo disponible |
112| Kernel de hammer | 6.16.12-metal (`recipes/linux.toml`) | **ausente** | `# CONFIG_SECURITY_LANDLOCK is not set` |
113
114Lo que hace falta de cada ABI, y desde dónde:
115
116| ABI | Kernel | Qué trae | Para harkaq |
117|---|---|---|---|
118| 2 | 5.19 | `FS_REFER` | **necesario** — sin refer no compila nada real |
119| 3 | 6.2 | `FS_TRUNCATE` | necesario |
120| 4 | 6.7 | `NET_BIND_TCP`, `NET_CONNECT_TCP` | **inerte** — no hay red que filtrar (§6) |
121| 5 | 6.10 | `FS_IOCTL_DEV` | cierra ioctls a dispositivos |
122| 6 | 6.12 | `SCOPE_ABSTRACT_UNIX_SOCKET`, `SCOPE_SIGNAL` | corta fuga lateral |
123| 7 | 6.15 | **audit de denegaciones** | **este es el proyecto entero** |
124| 8 | 7.0 | `RESTRICT_SELF_TSYNC` | robustez (todos los hilos) |
125| 10 | — | `ADD_RULE_QUIET`, `quiet_access_*` | **deliberadamente NO usar** (D3) |
126
127El hallazgo que ordena el diseño sigue siendo ABI 7: Linux 6.15 registra las peticiones denegadas
128vía audit con el motivo — `domain`, `blockers` (p.ej. `fs.make_reg,fs.refer`) y la identificación
129del objeto (`path`, `dev`, `ino` para filesystem; `opid`, `ocomm` para señales).
130
131Traducción: **el mecanismo de traza que el Draft 1 iba a construir ya lo hace el kernel.** No hay
132que instrumentar syscalls ni interponer un tracer. La evidencia sale del audit log del propio LSM,
133que es un productor mucho más confiable que cualquier cosa en espacio de usuario.
134
135### 3.2 El kernel de hammer: falta un flag, no una versión
136
137`store/060b34a6…-linux-metal/boot/config-6.16.12-metal` dice:
138
139```
140# CONFIG_SECURITY_LANDLOCK is not set
141CONFIG_LSM="landlock,lockdown,yama,loadpin,safesetid,selinux,smack,tomoyo,apparmor,ipe,bpf"
142CONFIG_SECCOMP_FILTER=y
143```
144
145Respuesta a la Q2 del Draft 1 ("¿vale la pena forzar ≥6.15 en la distro?"): **no hace falta
146forzar nada.** 6.16.12 ya trae hasta ABI 8, y `CONFIG_LSM` ya lista `landlock` de primero. Falta
147sólo compilarlo: un `scripts/config -e SECURITY_LANDLOCK` junto a los otros ajustes de la fase
148`configure` de `recipes/linux.toml` (`SECURITY_PATH` entra por `select`). Cuesta un rebuild
149(~35min) y cambia el hash del kernel. Es el único trabajo de infraestructura del proyecto.
150
151seccomp ya está `=y` en ambos kernels. No hay trabajo ahí.
152
153### 3.3 Las FODs: no existen. El fetcher mediado: ya está construido
154
155El Draft 1 dedicaba §6 entero + D8 al problema de las derivaciones de salida fija y su red
156abierta, y ponía el *fetcher mediado* en Fase 3 llamándolo *"el mayor riesgo de alcance del
157proyecto"*, de *"meses"*.
158
159Ese trabajo está hecho desde siempre, por construcción:
160
161- `crates/hammer-build/src/download.rs` corre `curl` **en el host**, fuera del sandbox.
162- El builder recibe **bytes** vía `--bind <src> /src`. Nunca un socket.
163- `--unshare-all` incluye `--unshare-net`: netns vacío para **todo** build, sin excepciones,
164  porque no existe la categoría "derivación que necesita red".
165
166Eso *es* la jaula con ventanilla que D8 proponía construir. hammer nunca tuvo el agujero de las
167FOD porque nunca tuvo FODs: separar el fetch del build fue una decisión temprana y silenciosa que
168resultó ser la correcta por razones de seguridad que nadie había escrito todavía. Queda escrita acá.
169
170**Fase 3 se elimina del plan.** El riesgo de cronograma desaparece.
171
172### 3.4 Q1 resuelta: la evidencia llega, con dos precondiciones y un canario obligatorio
173
174Experimento `scripts/harkaq/q1-audit.c` (2026-07-15), corrido en el laptop (ABI 10). Tres
175escenarios: denegación sin `execve`, con `execve` y flags por defecto, y con `execve` +
176`LANDLOCK_RESTRICT_SELF_LOG_NEW_EXEC_ON`.
177
178**La evidencia llega, y es exactamente la que el diseño necesita.** Un lector no privilegiado
179del grupo multicast `AUDIT_NLGRP_READLOG` recibe:
180
181```
182domain=146973ef2 blockers=fs.read_file path="/etc/passwd" dev="nvme1n1p6" ino=4458369
183domain=146973ef2 status=allocated mode=enforcing pid=3359 uid=0 exe="…/q1-audit" comm="q1-audit"
184```
185
186`blockers` + `path` + `dev` + `ino` + el `exe` que lo intentó. Ese registro **es** el diagnóstico
187de de-Alpinización de §0, y sale del kernel sin instrumentar nada.
188
189**Precondición 1 — `audit_enabled=1`.** Medido: el laptop arranca con `audit_enabled=0` (sin
190`audit=1` en el cmdline, sin `auditd`). Con audit apagado **no se emite ningún registro, de
191ningún escenario**. Se enciende con `AUDIT_SET` por netlink (`CAP_AUDIT_CONTROL`) o con `audit=1`
192en el cmdline — que para el kernel de hammer es horneable, igual que el resto del cmdline metal.
193
194**Precondición 2 — `LOG_NEW_EXEC_ON` es obligatorio, y su ausencia es indetectable.** Medido:
195
196| Escenario | Registros `ACCESS` |
197|---|---|
198| `same-exec` (sin `execve`) | **2** — logueado por defecto |
199| `new-exec` (flags por defecto) | **0** |
200| `new-exec-logon` (`LOG_NEW_EXEC_ON`) | **4** |
201
202Misma jaula, misma denegación, `cat` rebotó con `EACCES` en los tres. harkaq **restringe y después
203hace `execve`** del builder (bwrap → `/bin/sh -c` → make → `zig cc`): es el caso `new-exec`. Sin el
204flag, harkaq certificaría como herméticos **todos** los builds, `denials=[]`, para siempre, sin un
205solo error visible. El flag no es configuración: es la diferencia entre el sistema y un sello de goma.
206
207**No hay canario gratis en el kernel.** Se investigó si el registro `status=deallocated denials=N`
208podía servir de verificación cruzada. Medido, con una ventana de escucha de 6s: **un dominio con
209flags por defecto cuya única denegación es post-`exec` no emite absolutamente nada** — ni
210`allocated`, ni `access`, ni el `deallocated` con su contador. El contador existe **sólo para
211dominios que ya loguean**. Y el `allocated` se emite **perezosamente**, pegado al primer denial
212logueado (mismo evento de audit), así que un build genuinamente limpio tampoco lo produce: su
213presencia no puede usarse como prueba de que los flags tomaron.
214
215⇒ **D9 (nueva decisión cerrada, abajo): el canario lo fabrica harkaq.**
216
217Lo que el contador sí resuelve, cuando el logging está bien puesto: exigir
218`nº de registros ACCESS recibidos == denials` del `deallocated` detecta **registros perdidos** por
219desborde del backlog de audit — un riesgo real con la granja construyendo en paralelo. Son dos
220chequeos para dos fallas distintas (mala configuración vs. pérdida), y hacen falta los dos.
221
222> **Nota de método, que vale más que el resultado.** La primera corrida del experimento dio 0
223> registros en los tres escenarios y parecía confirmar la hipótesis. Era un bug del instrumento:
224> el `AUDIT_GET` pedía `NLM_F_ACK`, el ACK llegaba antes que la respuesta (el kernel la manda
225> asíncrona), el lector lo tomaba por fallo, `enabled` quedaba en `-1`, la rama que encendía el
226> audit nunca corría y el kernel no emitía nada. Sólo se detectó porque el **control**
227> (`same-exec`, que debía loguear) también dio 0, y eso era imposible.
228>
229> Es el modo de falla de harkaq, en vivo, sobre su propio banco de pruebas: un sistema cuyo
230> producto es la *ausencia* de algo no se rompe ruidosamente — dice que todo está bien. El
231> experimento ahora aborta con código 4 si no puede **confirmar** `audit_enabled=1`, en vez de
232> reportar cero. La misma disciplina es la que D9 le impone a harkaq.
233
234### 3.5 Q1b resuelta: la evidencia cruza el userns, y el canario es la clave primaria
235
236Experimento `scripts/harkaq/q1b-attrib.c` (2026-07-15). Dos builds **concurrentes**, cada uno
237dentro de bwrap con `--unshare-all` (los mismos ns que `Sandbox::bwrap_args`), sin privilegio
238(uid 1000), con un canario de nonce distinto. El lector corre en el **host**, como root.
239
240```
241[ACCESS] domain=146973f1c blockers=fs.read_file path="/tmp/harkaq-canary-BBBB" dev="nvme1n1p6" ino=4457713
242[DOMAIN] domain=146973f1c status=allocated mode=enforcing pid=8498 uid=1000 exe="…/q1b" comm="q1b"
243[ACCESS] domain=146973f1f blockers=fs.read_file path="/tmp/harkaq-canary-AAAA" dev="nvme1n1p6" ino=4457713
244[DOMAIN] domain=146973f1f status=allocated mode=enforcing pid=8499 uid=1000 exe="…/q1b" comm="q1b"
245[DOMAIN] domain=146973f1f status=deallocated denials=1
246[DOMAIN] domain=146973f1c status=deallocated denials=1
247```
248
249**(a) Los registros cruzan.** 6 registros landlock de adentro de bwrap llegaron al lector del
250host. El audit no está namespaceado y se comporta como tal. ⇒ **`harkaq-audit` vive en el host,
251junto a hammerd; la arquitectura de §4 se sostiene.** Y cruzan con builds **sin privilegio**, que
252es como corren de verdad (si sólo cruzaran con builds root, no servirían).
253
254**(b) El canario con nonce atribuye.** `AAAA=1`, `BBBB=1`, cero registros ajenos, con dos builds
255en paralelo. ⇒ **Q1b cerrada: la granja puede construir en paralelo sin contaminarse la
256evidencia.**
257
258Tres hallazgos colaterales que valen más que el veredicto:
259
2601. **El contador quedó validado.** Los dos `deallocated denials=1` llegaron en ventana, uno por
261   dominio, y cuadran con 1 `ACCESS` cada uno. El chequeo anti-pérdida de §3.4
262   (`nº ACCESS == denials`) está medido, no supuesto.
2632. **La identidad sobrevive a los namespaces:** `pid=8498 uid=1000` son del **host** (adentro del
264   pidns la víctima se ve como pid 1). El audit reporta identidad del lado donde está el lector.
2653. **`dev`+`ino` identifican el OBJETO, no el BUILD.** Los dos canarios reportan el mismo
266   `ino=4457713` (ambos bindean `/etc/hostname`). Atribuir por dev/ino habría fundido dos builds
267   que leen el mismo fichero no declarado — que es *el caso más común* que harkaq va a ver. **La
268   clave es `domain=`**; el canario es lo que la revela.
269
270⇒ El flujo de atribución queda cerrado: **canario ⇒ aprendo el `domain=` ⇒ atribuyo por `domain=`
271todo lo demás del build.** D9 hace tres trabajos con un mecanismo: honestidad (§3.4), clave
272primaria (acá) y — vía el contador — detección de pérdida.
273
274> **Nota de método (la tercera, y ya no es anécdota).** Esta corrida también falló primero, dos
275> veces más, y las dos el banco reportó un resultado inventado con total confianza:
276> 1. El comando de la víctima era `cat $canario >/dev/null`. `/dev` no estaba en la clausura ⇒ sh
277>    fallaba **en la redirección** y `cat` no llegaba a correr. El `rc=1` venía del redirect: el
278>    test medía una denegación que no era la que creía medir.
279> 2. Corriendo como root, bwrap no pudo ni ejecutar el binario (`execvp: Permission denied`) y el
280>    veredicto imprimió *"NADA cruzó ⇒ harkaq-audit no puede vivir en el host: replantear"* — una
281>    conclusión arquitectónica falsa, a partir de cero estímulo. (Causa: `--unshare-all` mapea
282>    sólo uid 0→0; los ficheros de uid 1000 quedan sin mapear y `CAP_DAC_OVERRIDE` **en un userns
283>    sólo vale sobre uids mapeados** ⇒ root-en-userns no atraviesa un home `drwx------`.)
284>
285> El banco ahora tiene un **gate de estímulo**: si alguna víctima no sale con status 0, aborta
286> (exit 4) en vez de contar registros.
287>
288> Van **tres** veces en una sesión —`NLM_F_ACK`, el redirect, el exec— que un cero resultó ser el
289> instrumento y no el kernel, y las tres el programa afirmó con confianza algo falso. Es la
290> evidencia empírica más fuerte a favor de D9, y viene del lado incómodo: *el banco lo escribió
291> alguien que sabía exactamente cuál era el riesgo, mirándolo de frente, y cayó igual, tres veces.*
292> harkaq sin canario no es un riesgo de configuración: es el comportamiento por defecto.
293
294---
295
296## 4. Arquitectura
297
298```
299 receta (escrita/importada por el agente)
300        │
301        ├─ deps declaradas (paths del store, por hash)
302        │
303        ▼
304 ┌──────────────────────────────────────────────────────────┐
305 │ harkaq-policy   (puro, testeable sin kernel)             │
306 │   clausura(deps) → PolicySpec {                          │
307 │      fs_ro:   [UN FICHERO POR ENTRADA — ver §4.1]        │
308 │      fs_list: [dirs de la clausura: listar, no leer]     │
309 │      fs_rw:   [/src, /out, /tmp, /cache]                 │
310 │      base:    [el runtime implícito — §8 Q2]             │
311 │      scoped:  UNIX_ABSTRACT | SIGNAL                     │
312 │   }                                                      │
313 │   PolicyId = blake3(postcard(PolicySpec))                │
314 └───────────────────────────┬──────────────────────────────┘
315                             ▼
316 ┌──────────────────────────────────────────────────────────┐
317 │ harkaq-exec     (musl, Rust) — DENTRO de bwrap           │
318 │   bwrap ya dio: ns, overlay, /src, /out, sin red         │
319 │   1. landlock: PolicySpec → ruleset (best-effort/ABI)    │
320 │   2. seccomp-bpf: allowlist (D4), vía --seccomp <fd>     │
321 │   3. no_new_privs, drop caps, exec builder               │
322 └───────────────────────────┬──────────────────────────────┘
323                             ▼
324 ┌──────────────────────────────────────────────────────────┐
325 │ harkaq-audit    (lector de AUDIT_LANDLOCK_*)             │
326 │   EN EL HOST, junto a hammerd — FUERA de bwrap (§3.5):   │
327 │   el audit no está namespaceado y los registros cruzan.   │
328 │   Requiere CAP_AUDIT_READ (§8 Q1c).                       │
329 │   canario ⇒ domain= ⇒ atribuye el resto (D9)             │
330 │   denegaciones → Denial { blockers, path, dev, ino, ... }│
331 └───────────────────────────┬──────────────────────────────┘
332                             ▼
333   Verdict { PolicyId, recipe_hash, artifact_hash,
334             estado: Hermetico | Impuro{denials[]} | SinEvidencia }
335                             │
336              blake3 ──► CAS ──► willay ──► iniy
337```
338
339Ley de dependencia: `harkaq-policy` no conoce el kernel (función pura de `Recipe` → `PolicySpec`,
340testeable con `cargo test` en cualquier máquina, incluso sin Landlock). `harkaq-exec` no conoce
341la receta. El acoplamiento vive sólo en `hammer-build`.
342
343Nota de encaje: `Sandbox::bwrap_args` ya construye la lista de deps (`self.deps`) — es
344literalmente el input de `clausura()`. El `PolicySpec` se deriva de datos que la struct `Sandbox`
345ya tiene en la mano.
346
347### 4.1 La política es POR FICHERO, no por path del store (corrección medida)
348
349El Draft 2 decía `fs_ro: [store paths de la clausura]`. **Es falso, y era otra herencia del marco
350nix**, donde cada dep se ve dentro del sandbox como un `/nix/store/<hash>-x` distinto. En hammer
351no: `Sandbox::bwrap_args` apila cada dep con `--overlay-src` y las **funde en el mismo `/usr`**
352que el rootfs Alpine, a propósito, para que el compilador y pkgconf las encuentren en las rutas
353estándar sin plumbing de flags.
354
355Medido dentro del sandbox real:
356
357```
358/usr/include/zlib.h    (dep DECLARADA)          dev=63 ino=13641973
359/usr/include/stdio.h   (Alpine, NO declarado)   dev=63 ino=4196788
360/usr/include           (el directorio)          dev=61 ino=15   ← overlayfs, uno solo
361```
362
363Los paths del store **no existen dentro del sandbox**, y una regla sobre `/usr/include` concede
364las dos cosas por igual — la evidencia dejaría de significar nada. Ni siquiera `dev` distingue:
365overlayfs deja pasar el inode de la capa inferior y ambas capas están en la misma partición.
366
367**La clausura se enumera fichero a fichero.** Es computable sin esfuerzo: en el *host* sabemos
368exactamente qué aporta cada dep (`store/<hash>-zlib/usr/include/zlib.h` → `/usr/include/zlib.h`;
369la traducción es quitar el prefijo del store). `harkaq-policy.sh` lo hace hoy.
370
371Dos consecuencias de diseño:
372
3731. **`list` ≠ `ro`.** pkgconf y los tests de `configure` **necesitan** escanear `/usr/lib/pkgconfig`,
374   pero listar no es leer. Landlock separa `READ_DIR` de `READ_FILE`, así que se concede el
375   listado del directorio y se deniega la lectura de los `.pc` que la receta no declaró. Sin esta
376   separación, todo `ls` sería un falso positivo.
3772. **Máscara por tipo.** Los derechos de-sólo-directorio (`READ_DIR`, `MAKE_*`, `REFER`, …) sobre
378   un fichero regular hacen que el kernel rechace la regla entera con `EINVAL`. Como la clausura
379   es mayormente ficheros sueltos, sin recortar por tipo no arranca ni la primera regla.
380
381### 4.2 Q2 resuelta: el runtime base son 5 paths, y hay una tercera categoría
382
383El método es lo importante: **no se adivina, se mide**. `scripts/harkaq/q2-runtime-base.sh` corre
384un build real en el sandbox real con `política = clausura declarada` y deja que las denegaciones
385nombren el resto. `MODE=base` (sin **ninguna** dep declarada) aísla la respuesta sin juicio de
386valor: sin clausura que pueda explicarlas, *toda* denegación es runtime base por definición.
387
388`MODE=base`, `hello.c` mínimo con `zig cc` — 18 denegaciones, 4 paths distintos (contador del
389kernel 19 = 18 + canario ✓):
390
391```
3928× /dev/urandom      6× /usr/lib/os-release      3× /dev/null      1× /usr/bin/env
393```
394
395**Y el build salió `rc=0`.** No son cosas que el build *necesite*: son cosas que *intenta*. Pero
396aparecen en todos los builds, así que sin tratarlas cada veredicto sale `Impuro` con los mismos
397paths y la deuda real queda enterrada. Iterando (cada línea añadida sólo tras una denegación
398real, nunca por corazonada) la partición se cierra en **tres** categorías:
399
400| Categoría | Qué | Qué hacer |
401|---|---|---|
402| **Contrato del sandbox** | `/src`, `/out`, `/tmp`, `/dev/null` (**rw**: es destino de escritura), `/dev/urandom`, `/proc`, `/opt/zig` | conceder — **los crea bwrap, no son Alpine** |
403| **Runtime base Alpine** | `/bin/sh`, `/bin/busybox`, `/lib/ld-musl-x86_64.so.1`, `/usr/bin/env`, `/usr/lib/os-release` | conceder — irreducible, y son **5** |
404| **Denegación esperada** | `/usr/bin/gcc` | **denegar y clasificar** (D3) |
405
406La primera línea divisoria es la que hacía falta: `/dev` y `/proc` **los monta bwrap**, no salen
407del rootfs Alpine ⇒ son superficie de contrato como `/src`, no deuda. Sólo 5 paths de Alpine son
408irreducibles. Eso hace viable todo el planteo: **el resto de Alpine es, genuinamente, deuda**.
409
410**La tercera categoría no estaba en el diseño y es la más interesante.** `zig cc` sondea
411`/usr/bin/gcc` (`fs.execute,fs.read_file`, 3 veces) y el build igual sale `rc=0` sin él. Esa
412denegación **no es ruido a permitir: es la jaula haciendo su trabajo**. Concederla dejaría a zig
413invocar el gcc de Alpine por detrás — justo lo que la campaña *matar gcc* persigue a mano. harkaq
414da evidencia mecánica de que zig lo intenta *y* de que negárselo no rompe el build. Es D3 literal
415("una denegación esperada no se calla, se *clasifica*"), y confirma que la decisión de no tener
416`quiet` era correcta: silenciarla habría borrado el hallazgo.
417
418**El contraste, con el mismo runtime base:**
419
420```
421MODE=base   rc=0   Impuro, denegaciones = [ /usr/bin/gcc ]              ← esperada
422MODE=zlib   rc=1   Impuro, denegaciones = [ /usr/lib/libz.so.1.3.2 ]    ← DEUDA PURA
423```
424
425Una sola denegación, sin ruido: el build se linkaba contra **la zlib de Alpine** en vez de la dep
426declarada (que aporta `libz.a`). Sin harkaq eso pasa en verde y el artefacto queda dependiendo de
427Alpine. **Es exactamente el bug de §0, aislado en un build real y en una corrida de 20 segundos.**
428
429Consecuencia para el `Verdict`: los tres estados de D9 necesitan que las denegaciones vengan
430**clasificadas** (`base` | `esperada` | `deuda`), no en una lista plana. `Hermetico` debe
431significar "cero deuda", no "cero denegaciones" — si no, ningún build real lo alcanzaría jamás.
432Implementado en `harkaq-verdict.py`, **deliberadamente fuera del lector**: éste corre con
433`CAP_AUDIT_READ` y clasificar es *política, no privilegio* (mismo argumento que Q1c). Las
434expectativas viajan en la propia política como `# expect <path>` — una sola fuente de verdad, y
435`harkaq-exec` las ignora como comentario. Medido:
436
437```
438MODE=base   rc=0   Hermetico   esperadas: /usr/bin/gcc            deuda: ninguna ✓
439MODE=zlib   rc=1   Impuro      DEUDA: /usr/lib/libz.so.1.3.2
440```
441
442### 4.3 ¿Aguantan los 5 paths? No — pero converge, y eso es lo que importa
443
444Los 5 paths de §4.2 son la respuesta para *un* shape de build (C mínimo con `zig cc`). La
445pregunta honesta era si sobreviven a un `configure` de autotools, que sondea el sistema entero.
446Medido contra una fuente **real** (`libgpg-error`, `MODE=configure`), iterando con el método de
447§4.2 (cada línea sólo tras una denegación real):
448
449| Ronda | Deuda restante (paths únicos) |
450|---|---|
451| 1 | `/bin/bash`, `/bin/coreutils` |
452| 2 | `libacl`, `libattr`, `libcrypto`, `libreadline`, `libutmps` |
453| 3 | `libncursesw`, `libskarnet` |
454| 4 | `/usr/bin/c89`, `/usr/bin/c99`, `/usr/bin/ldd`, `/usr/bin/make` |
455
456**Respuesta: no, el runtime base es por forma de build.** Un `configure` necesita ~16 entradas,
457no 5. Pero las tres cosas que importan salieron bien:
458
4591. **Converge, y rápido** — 3 rondas, de 34 denegaciones a 5. No es una cola infinita.
4602. **Se queda chico** — ~16 entradas, no cientos. La métrica de <5% de la Fase 2 sigue siendo
461   plausible.
4623. **El runtime base no es una lista de binarios: es su CIERRE de `.so`.** Conceder `/bin/bash`
463   arrastra `libreadline`+`libncursesw`; conceder `/bin/coreutils` arrastra `libacl`+`libattr`.
464   Eso es *computable* (`ldd`), no adivinable ⇒ `harkaq-policy` debe derivar también el cierre
465   dinámico del runtime base, igual que deriva la clausura de las deps. Misma idea, otro origen.
466
467**Y el residuo es todo significativo, ninguno ruido:**
468
469- `c89`, `c99`, `ldd` — la misma familia que `gcc` (§4.2): sondas de compilador de Alpine. Van a
470  **denegación esperada**; concederlas sería dejar que `configure` compile con Alpine.
471- `/usr/bin/make` — **la decisión de diseño de verdad**, y no la toma harkaq. Hoy los builds de
472  hammer usan el `make` de Alpine sin declararlo. O es runtime base (se acepta y se escribe), o
473  es deuda (y se declara como dep). Nótese que esto es *exactamente* lo que los swaps del
474  `selfhost-verify` reemplazan uno a uno: **la lista de deuda de harkaq y la lista de swaps del
475  bootstrap son la misma lista, descubierta por dos caminos.** Que coincidan es la mejor
476  validación externa que tiene el método.
477
478---
479
480## 5. Decisiones cerradas
481
482### D1 — La política se deriva, no se escribe
483
484Es el corazón, y sobrevive al Draft 1 sin un rasguño. Todo sandbox del mundo muere en la
485ergonomía: alguien mantiene a mano un perfil de permisos, nadie lo revisa, todos terminan en
486permisivo. hammer no tiene ese problema porque **la receta ya declara sus deps por hash**.
487`clausura(deps)` es el conjunto exacto de rutas de solo lectura. Cero configuración humana,
488precisión igual a la del direccionamiento por contenido.
489
490Corolario: no existe "modo permisivo". Una receta que necesita más de lo que declara está mal
491escrita, y ese es exactamente el diagnóstico que queremos que el agente reciba — hoy lo
492producimos leyendo logs a mano y llamándolo de-Alpinización.
493
494### D2 — La evidencia es negativa, y por eso es barata
495
496**No se traza lo permitido.** La tentación es loguear todo acceso para "probar" qué tocó el build;
497eso exige fanotify o eBPF, cuesta rendimiento y produce un río de datos que nadie audita.
498
499La formulación correcta es la contrapositiva:
500
501> `hermético(build) ⟺ política = clausura(deps) ∧ denegaciones = ∅`
502
503Si la política concede *exactamente* la clausura declarada y el kernel no denegó nada, entonces el
504build no usó nada fuera de lo declarado. **La política es la afirmación; la ausencia de
505denegaciones es la prueba.** Coste de la traza: un lector de audit y una lista casi siempre vacía.
506
507Esto convierte la reproducibilidad de hammer, que hoy es una promesa arquitectónica verificable
508sólo rebuildeando, en un certificado por build.
509
510### D3 — Cero quieting. Las denegaciones son el producto
511
512ABI 10 permite suprimir selectivamente logs de accesos denegados por objeto (`LANDLOCK_ADD_RULE_QUIET`,
513campos `quiet_access_*`). Es una feature excelente para sandboxear apps de escritorio ruidosas —
514y **veneno para harkaq**. Silenciar una denegación es destruir la única evidencia que produce el
515sistema. En harkaq `quiet_*` está prohibido por diseño; una denegación esperada no se calla, se
516*clasifica* en el `Verdict`.
517
518(De la propia doc del kernel: el objeto queda marcado como quiet si al menos una llamada lo pidió,
519y llamadas posteriores sin el flag no lo limpian — es pegajoso. Razón extra para no tocarlo.)
520
521Este laptop reporta ABI 10, así que la feature está a un flag de distancia. La disciplina es no
522usarla.
523
524### D4 — Landlock no basta; seccomp es obligatorio, no opcional
525
526Landlock cubre fs, puertos TCP e IPC scoping. No cubre `ptrace`, `bpf`, `userfaultfd`, `keyctl`,
527`io_uring`, montajes, ni la mitad de la superficie interesante. seccomp-bpf con allowlist por
528syscall es la otra mitad de la jaula.
529
530Buena noticia de composición: **bwrap acepta `--seccomp <fd>`**. No hay que reemplazar el
531launcher; se le pasa el filtro al que ya tenemos. `CONFIG_SECCOMP_FILTER=y` en ambos kernels.
532
533`io_uring` va explícitamente denegado en v1 (superficie de kernel enorme, y bypassea buena parte
534del análisis por-syscall). Si un builder lo necesita, que lo justifique.
535
536### D5 — Herencia y TSYNC
537
538Las restricciones de Landlock se heredan automáticamente por `fork()` y `exec()`, así que todo el
539árbol de procesos del build queda contenido sin trabajo extra — que es exactamente lo que hace
540falta cuando `Sandbox::run` lanza `/bin/sh -c` que lanza make que lanza `zig cc`. Con ABI 8
541disponible (6.16.12 lo tiene), usar `RESTRICT_SELF_TSYNC` para cubrir todos los hilos.
542
543### D6 — harkaq es órgano de hammer, no de la suite. Rompe la paridad wawa, y está bien
544
545Landlock, seccomp y cgroups son Linux puro; en `x86_64-unknown-none` no existen. Esto viola el
546principio de paridad Linux/wawa que gobierna el resto del ecosistema, y hay que decirlo en voz
547alta antes de que alguien lo cobre.
548
549El costo es aceptable porque **el bucle de build del agente es una actividad Linux por
550definición**. wawa nunca compila nada: consume artefactos atestados del CAS. La frontera de
551confianza de wawa es la atestación; la de hammer es la jaula. Son mecanismos distintos para
552posiciones distintas del pipeline, y eso es coherente, no inconsistente.
553
554### D7 — Fallo cerrado, y honesto sobre el ABI
555
556- `abi_minima = V3` para intentar el build (sin `REFER` y `TRUNCATE` no compila software real).
557- `abi_evidencia = V7` para emitir un `Verdict` con evidencia.
558- Entre V3 y V7: el build corre, el `Verdict` sale `SinEvidencia`, iniy lo trata con
559  `uncertainty` alta en vez de creerle.
560- Sin Landlock (el kernel de hammer **hoy**): `SinEvidencia`, y el build corre igual bajo el bwrap
561  de siempre. harkaq es inerte, no un muro.
562
563Nunca se emite evidencia que el kernel no respaldó. Se consulta el ABI con el syscall, jamás
564`uname`.
565
566### D8 — La red ya está cerrada; harkaq no la toca
567
568(Reemplaza al D8 del Draft 1, que trataba de las FOD.)
569
570`--unshare-all` ⇒ netns vacío ⇒ los derechos de red de ABI 4 son **inertes**. No se implementan.
571Si algún día un build necesitara red, la respuesta no es abrir el netns: es extender el fetcher
572del host (§3.3), que es el embudo con hash donde ancla el CAS y donde willay puede auditar.
573
574`SCOPE_ABSTRACT_UNIX_SOCKET` (ABI 6) sí se usa: cierra la fuga simétrica hacia sockets abstractos.
575Ojo con la semántica documentada — un socket datagram ya conectado antes del scoping puede seguir
576enviando; y el scoping no admite reglas: si un dominio está scoped, no hay forma de permitir un
577recurso puntual fuera. Es todo-o-nada, lo cual para nosotros está bien.
578
579### D9 — El canario deliberado: `denials=[]` no se cree, se gana
580
581(Nace de la medición de §3.4. Es la decisión que Q1 obligó a tomar.)
582
583**El problema.** Un build hermético y un lector ciego producen exactamente los mismos bytes:
584`denials=[]`. Y §3.4 midió que el kernel **no ofrece ninguna forma de distinguirlos** — un dominio
585sin logging es invisible, y el registro `allocated` es perezoso, así que su ausencia tampoco
586prueba nada. Sin resolver esto, D2 (la evidencia negativa) no vale nada: la afirmación más fuerte
587del sistema sería indistinguible de su falla más común.
588
589**La decisión.** Cada build provoca una denegación conocida, **después del `execve`**, y harkaq
590**exige verla**. El canario es un path que existe en el sandbox y que la política deja
591deliberadamente fuera de la clausura (p.ej. un `--ro-bind` a una ruta fija que el ruleset no
592concede). El probe se antepone al comando del builder — misma vía que `Sandbox::run` ya usa
593(`/bin/sh -c`), así que corre en el dominio y del lado correcto del `exec`.
594
595**El veredicto pasa a ser de tres estados, no de dos:**
596
597| Canario | Otras denegaciones | Veredicto |
598|---|---|---|
599| visto | ∅ | `Hermetico` — y *ahora sí* significa algo |
600| visto | ≥1 | `Impuro { denials }` — el diagnóstico útil |
601| **no visto** | cualquiera | **`SinEvidencia`** — el lector no es confiable; no se afirma nada |
602
603El canario cubre la mala configuración (flag ausente, audit apagado, lector caído). El contador
604`deallocated denials=N` de §3.4 cubre la otra falla, la pérdida de registros por backlog: se exige
605`nº de ACCESS == N`. Dos chequeos, dos fallas, ninguno redundante.
606
607**Y el canario es además la clave primaria de la evidencia** (medido en §3.5). Con un nonce único
608por build, su registro revela el `domain=` de ese build, y `domain=` ata todos los registros
609restantes del mismo. Sin él no hay atribución fiable con la granja construyendo en paralelo: el
610`pid=` viaja en el `allocated`, que es **perezoso**, y `dev`+`ino` identifican el **objeto**, no el
611build — dos builds leyendo el mismo fichero no declarado dan el mismo `ino`, que es justo el caso
612más común que harkaq va a ver. Un mecanismo, tres trabajos: honestidad, atribución y detección de
613pérdida.
614
615**Por qué es un no-negociable.** Es la misma disciplina de D7 (fallo cerrado) y de D3 (cero
616quieting), aplicada al único punto donde el sistema podría mentirse a sí mismo en silencio. Y no
617es hipotético: el banco de pruebas de Q1 ya cayó en esa trampa una vez (§3.4, nota de método).
618
619---
620
621## 6. Fases
622
623**Fase 0 — Reconocimiento.** ✅ **CERRADA (2026-07-15)**. Ver §3. Salidas: ABI 10 en el laptop,
624Landlock ausente-pero-a-un-flag en el kernel de hammer, cero FODs y fetcher ya construido.
625
626**Fase 1 — El hito demostrable (una tarde).**
627Precondiciones, todas ya medidas en §3 y ninguna especulativa:
6281. `scripts/config -e SECURITY_LANDLOCK` en `recipes/linux.toml` (+ rebuild, ~35min, cambia el hash).
6292. `audit=1` horneado en el cmdline del kernel metal — o `AUDIT_SET` desde hammerd (§3.4, Q1c).
6303. `LANDLOCK_RESTRICT_SELF_LOG_NEW_EXEC_ON` en el `restrict_self` (§3.4). **Sin esto no hay nada.**
6314. El canario de D9 antepuesto al comando del builder.
632
633Después: tomar **una** receta real de hammer. Derivar su política de la clausura. Correrla bajo
634Landlock+seccomp dentro del bwrap actual. Emitir el `Verdict` con `denials = []` **y el canario
635visto**.
636
637**Estado (2026-07-15): la cadena corre de punta a punta.** `harkaq-audit` (lector, host,
638`CAP_AUDIT_READ`) + `harkaq-exec` (política, estático, dentro de bwrap) + `harkaq-run.sh`
639(orquesta y pone el canario). Los dos actos, con comandos sintéticos:
640
641```json
642limpio  {"estado":"Hermetico","canario_visto":true,"contador_kernel":1,"denials":[]}
643impuro  {"estado":"Impuro","canario_visto":true,"contador_kernel":2,
644         "denials":[{"blockers":"fs.read_file","path":"…/README.md","dev":"nvme1n1p3","ino":"2919408"}]}
645```
646
647Canario visto y contador coherente en ambos ⇒ los tres estados de D9 funcionan sobre el kernel
648real. Precondiciones 2–4 ✅. Falta: la precondición 1 (sólo para que harkaq corra *dentro* de
649hammer — el hito se demuestra en el laptop, que ya está en ABI 10), `harkaq-policy` derivando de
650la clausura real, y el contraste receta-de-Alpinizada vs. receta-que-no.
651
652**Sutileza medida: lo que DAC ya bloquea es invisible.** Un acceso que los permisos Unix rechazan
653no genera registro de Landlock (el hook del LSM no llega a correr). No rompe D2 — si DAC lo
654bloqueó, el build tampoco lo usó, así que `Hermetico` sigue siendo cierto — pero acota el
655*diagnóstico*: harkaq no reporta el intento. Para la de-Alpinización es inocuo (el rootfs Alpine
656es world-readable); para escribir tests es una trampa (un escenario "impuro" sobre un path que DAC
657ya prohíbe da `Hermetico` y el control no controla nada).
658Luego correr **una receta que sepamos no de-Alpinizada** y mostrar que la jaula nombra exactamente
659qué usó sin declarar, con path/dev/ino.
660**Ese par de corridas es el argumento entero del proyecto**, y se enseña en dos minutos.
661
662> Cambio respecto del Draft 1: el segundo acto era una derivación de juguete que leía
663> `/etc/passwd`. Una receta real no de-Alpinizada es *mejor demo* (es el problema que de verdad
664> tenemos) y de paso le entrega valor inmediato a una campaña en curso.
665
666**Fase 2 — `harkaq-policy` completo + medir la brecha.** Clausura real, `/src`, `/out`, `/tmp`,
667`/cache`, `/proc` y `/dev` mínimos, y el **runtime base** (sin `/bin/sh` ni la libc del rootfs no
668arranca nada — ver Q3). Correr contra N recetas del catálogo y medir la tasa de falsos positivos.
669*Métrica de éxito: <5% de recetas necesitan excepción.*
670El delta entre `política = clausura` y `política = clausura + base Alpine` **es** la medida
671cuantitativa de la deuda de de-Alpinización del catálogo. Ese número no existe hoy.
672
673**Fase 3 — El bucle epistémico.** `Verdict → willay → iniy`, como `kind` nuevo junto a la
674evidencia H1 (§0.1). Aquí el agente empieza a recibir su propio reflejo: una receta cuyo build
675denegó cosas es una receta de la que el sistema desconfía, y esa desconfianza es un número, no una
676vibra.
677
678*(La Fase 3 del Draft 1 —el fetcher mediado— se eliminó: ya existe. Ver §3.3.)*
679
680---
681
682## 7. Riesgos y honestidades
683
684- **El kernel es la TCB.** harkaq no contiene un exploit de kernel. Landlock+seccomp reduce
685  superficie; no la elimina. Si el modelo de amenaza incluye "la IA encuentra un 0-day de kernel",
686  la respuesta correcta es microVM, no LSM. Decir esto en el README, no en letra chica.
687- **La entrega de la evidencia es el único riesgo técnico serio que queda.** Ver Q1. Todo el
688  proyecto cuelga de poder leer los registros `AUDIT_LANDLOCK_*` de forma confiable desde el
689  proceso que orquesta el build. Si eso no se resuelve limpio, harkaq queda sin producto.
690- **Falsos positivos matan proyectos de sandboxing.** Si el 30% de los builds necesita excepción
691  manual, harkaq se desactiva y queda como decoración. La Fase 2 existe para descubrir esto
692  temprano y barato. Atenuante: acá un "falso positivo" suele ser un **verdadero positivo de
693  de-Alpinización**, y el catálogo tiene ~750 recetas para probarlo.
694- **Domesticar el vocabulario.** harkaq no prueba que un build fue hermético. Prueba que *bajo el
695  supuesto de que el kernel y la derivación de política son correctos*, el build no accedió fuera
696  de su clausura declarada. Es una afirmación fuerte y defendible. La versión sin asteriscos es la
697  que te van a cobrar. (Mismo criterio que SDD 15 §0: "verificado bajo supuestos nombrados".)
698- **Competencia.** Como proyecto OSS genérico, "sandbox para agentes" es un espacio poblado (ya
699  existe landrun) y la ventana no es infinita. Como el ejecutor de hammer, no compite con nadie: el
700  diferenciador no es la jaula, es que **la política sale del hash y la evidencia entra al grafo de
701  confianza**. Nadie más tiene CAS + log monótono + grafo para cerrar ese bucle.
702- **El rebuild del kernel cambia su hash.** Encender `SECURITY_LANDLOCK` invalida
703  `060b34a6…-linux-metal` y lo que dependa de él. Es esperado y barato, pero hay que agendarlo, no
704  descubrirlo.
705
706---
707
708## 8. Preguntas abiertas
709
710- **Q1 — ✅ CERRADA (2026-07-15).** La evidencia llega, con `blockers`/`path`/`dev`/`ino`/`exe`, por
711  el multicast `AUDIT_NLGRP_READLOG`. Precondiciones medidas: `audit_enabled=1` (no viene de
712  fábrica) y `LOG_NEW_EXEC_ON` (sin él, cero registros tras el `exec`). No hay canario gratis ⇒
713  D9. Detalle y mediciones en §3.4. **El gate del proyecto está pasado: harkaq es viable.**
714- **Q1b — ✅ CERRADA (2026-07-15).** Los registros cruzan el userns/pidns/mountns de bwrap hasta un
715  lector en el host, con builds **sin privilegio**. La atribución con la granja en paralelo se
716  resuelve con el canario de nonce único (D9): revela el `domain=`, que ata el resto. Medido con 2
717  builds concurrentes, cero cruces. Detalle en §3.5.
718- **Q1c (Fase 1):** ¿quién corre `harkaq-audit` y con qué privilegio? Necesita `CAP_AUDIT_READ`
719  (leer el multicast) y, salvo que se hornee `audit=1` en el cmdline, `CAP_AUDIT_CONTROL` (para el
720  `AUDIT_SET`). En el laptop hizo falta root. Medido en §3.5: el lector privilegiado y los builds
721  sin privilegio conviven bien. Falta decidir si es hammerd o un helper con capabilities acotadas
722  — preferible lo segundo: `CAP_AUDIT_*` es superficie de más para el daemon entero.
723- **Q1d (Fase 1, menor):** el `exe=` del registro trae la ruta **del host**. Con el sandbox real
724  (`--bind <src> /src`) hay que confirmar qué ruta reporta para un builder que vive en `/src`, y si
725  sirve para algo o basta con `domain=`.
726- **Q2 — ✅ RESPONDIDA (2026-07-15), y el resultado es mejor de lo esperado.** Ver §4.2. El
727  runtime base de Alpine son **5 paths**, medidos; la deuda queda aislada sin ruido; y apareció
728  una tercera categoría que no estaba en el diseño: la *denegación esperada*.
729- **Q3 (Fase 2):** ¿`/proc` y `/dev` mínimos rompen builds reales? (`/proc/self` suele hacer falta;
730  `/proc/sys` casi nunca.) bwrap ya monta `--proc /proc --dev /dev`.
731- **Q4:** ¿el `Verdict` entra en `Recipe::hash_inputs`? Por simetría con `Evidence` (H1), **no**:
732  hermeticidad es comportamiento, no identidad. Confirmar con el mismo criterio de `recipe.rs:228`.
733
734*(Las Q1/Q4/Q5 del Draft 1 —el vector page-cache de `copy.fail`, la fracción de FODs, y si harkaq
735envuelve o reemplaza a nix— se eliminan: eran todas sobre nix.)*