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 ⇒