sergio/takana

El SDD 16 dejó abierto: '¿el vector page-cache de copy.fail sobrevive a un
ruleset que deniegue escritura a nivel de inode? Investigar antes de afirmar
nada'. Investigado en un fs AISLADO (loop en un worker efímero, nunca el fs del
usuario):

  escribir al artefacto sellado              → EPERM
  dd como ROOT                               → Operation not permitted (ni root)
  machacar los bytes POR DEBAJO (device)+leer→ Input/output error

El tercero ES el vector de copy.fail: modificar el fichero por debajo del fs. El
kernel detecta la corrupción AL LEER (el Merkle no cuadra) y rechaza la lectura.
⇒ fs-verity mata el vector. Landlock read-only no alcanzaba; fs-verity sí.

Costo medido, y corrige al SDD 17 §5: 'hash = identidad' es FALSO — fs-verity usa
Merkle SHA-256, hammer direcciona con BLAKE3 ⇒ son DOS hashes, no uno. Y ext4
exige -O verity Y blocksize = PAGE_SIZE (con 1024 el mount falla:
'Unsupported blocksize for fs-verity'). No es gratis, pero es barato para lo que da.

NO se tocó el fs del laptop (habilitar verity pediría tune2fs sobre la partición
del usuario): el experimento corrió en un loop device de un worker descartable.

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

diff --git a/docs/16-harkaq-jaula.md b/docs/16-harkaq-jaula.md
index c697ebf7..4656317a 100644
--- a/docs/16-harkaq-jaula.md
+++ b/docs/16-harkaq-jaula.md
@@ -1027,6 +1027,25 @@ vibra.
 
 ## 8. Preguntas abiertas
 
+- **Q1-copy.fail — ✅ RESPONDIDA (2026-07-16) con fs-verity.** El SDD dejó abierto: *«¿el vector
+  page-cache de `copy.fail` sobrevive a un ruleset que deniegue escritura a nivel de inode?
+  Investigar antes de afirmar nada»*. **Investigado, en un fs aislado (loop, nunca el fs real):**
+
+  | ataque | resultado |
+  |---|---|
+  | escribir al artefacto sellado | `EPERM` |
+  | `dd` como **root** | `Operation not permitted` — ni root |
+  | **machacar los bytes POR DEBAJO** (en el device) y leer | **`Input/output error`** |
+
+  El tercero es el vector de `copy.fail`: se modifica el fichero por debajo del filesystem. **El
+  kernel detecta la corrupción al leer** (el Merkle no cuadra) y rechaza la lectura. ⇒ **fs-verity
+  mata el vector**; Landlock read-only no alcanzaba, fs-verity sí.
+
+  **Costo medido, contra lo que dice el SDD 17 §5:** *«hash = identidad»* es **falso** — fs-verity
+  usa un Merkle **SHA-256** y hammer direcciona con **BLAKE3**: son **dos** hashes, no uno. Y en
+  ext4 exige `-O verity` **y blocksize = PAGE_SIZE** (con 1024 el mount falla:
+  `Unsupported blocksize for fs-verity`). No es gratis, pero es barato para lo que da.
+
 - **Q1 — ✅ CERRADA (2026-07-15).** La evidencia llega, con `blockers`/`path`/`dev`/`ino`/`exe`, por
   el multicast `AUDIT_NLGRP_READLOG`. Precondiciones medidas: `audit_enabled=1` (no viene de
   fábrica) y `LOG_NEW_EXEC_ON` (sin él, cero registros tras el `exec`). No hay canario gratis ⇒