diff --git a/HANDOFF.md b/HANDOFF.md
index 9c804ba..024621b 100644
--- a/HANDOFF.md
+++ b/HANDOFF.md
@@ -247,9 +247,9 @@ El vector de GT (`vectors/tlock_ibe.json`) ya está cubierto en `App`. El paso 9
   1. Hecho: el autor eligió Unicode 18.0.0 («no vamos a trabajar con unicodes ya pasados») y dio el visto bueno al texto. El borrador lo recoge en su rama, y el diseño, en su decisión 4.
   2. Pendiente del autor: la propuesta sobre invisibles. Hoy el comentario y el autor declarado admiten las etiquetas U+E0000–E007F y los selectores de variante, con los que se esconde texto que un modelo de IA sí lee, y las rutas admiten secuencias de ZWJ, ZWNJ, VS15 y VS16. Recomendación: una sola regla para todo texto del creador, rutas incluidas: nada de `Default_Ignorable_Code_Point` salvo la lista blanca, y la lista blanca solo donde es conforme: VS15 y VS16 tras un carácter que los admite según `emoji-variation-sequences.txt`, y ZWJ y ZWNJ nunca al principio o al final, ni dos seguidos.
   3. Pendiente del autor: permiso para descargar de unicode.org los datos de las tablas, unos 10 MB: `UnicodeData.txt`, `DerivedCoreProperties.txt`, `CaseFolding.txt` y `emoji-variation-sequences.txt` de Unicode 18.0.0, y los quince `bestfit*.txt` de WindowsBestFit.
-  3. La referencia Go implementa el formato 3 con sus fixtures, vectores y mutaciones, fija los SHA-256 de las tablas y pasa `scripts/check.sh`. Después, con la autorización del autor, el tag `spec-v0.10`, como en la v0.9.
-  4. `datekeys-ts` sincroniza `testdata` y lee y escribe el formato 3.
-  5. La entrega 2 abre la versión siguiente del spec, y la 3 espera al documento «Servicio de sellado DateKeys v1». Para otra revisión externa, el artefacto hay que volver a publicarlo desde el diseño nuevo.
+  4. La referencia Go implementa el formato 3 con sus fixtures, vectores y mutaciones, fija los SHA-256 de las tablas y pasa `scripts/check.sh`. Después, con la autorización del autor, el tag `spec-v0.10`, como en la v0.9.
+  5. `datekeys-ts` sincroniza `testdata` y lee y escribe el formato 3.
+  6. La entrega 2 abre la versión siguiente del spec, y la 3 espera al documento «Servicio de sellado DateKeys v1». Para otra revisión externa, el artefacto hay que volver a publicarlo desde el diseño nuevo.
 
 **Conclusiones de la conversación, sin decisión pendiente:**
 - El protocolo no contempla un sello de tiempo de creación (§5, §55.1). Si se quiere, lo recomendado es un sello RFC 3161 u OpenTimestamps sobre el SHA-256 del `.dkc` completo, guardado aparte.