diff --git a/HANDOFF.md b/HANDOFF.md
index c72bd97..38512a5 100644
--- a/HANDOFF.md
+++ b/HANDOFF.md
@@ -22,6 +22,8 @@ Sirve para retomar sin contexto previo, sea una persona o una sesión de Claude.
 
    **La app Flutter queda archivada** para más adelante, por decisión del autor del 6-10 («la aplicación de Flutter de momento se archiva para un futuro»). La librería Dart está lista para cuando se retome.
 
+**Borrador v0.14 (6-10, noche).** El autor dijo «sí, empieza por el 1»: el paso 2 de la revisión, escribir lo que falta. Rama `v0.14` de `datekeys-go`, `49b3764`, sin aprobar: §5, §7.6, §7.7, §7.10, §36.1, §38.1, §50, §53, §59, §71 y erratas del §76 (de la sesión); y la raíz de confianza byte a byte en §12, §35, §51 y los pasos 10 y 11 del §63, con `testdata/vectors/tlock_steps.json` (de un agente Opus). Las decisiones, en [spec_v0.14/decisiones.md](spec_v0.14/decisiones.md); la 8, los tres schemes de §12.1, es la única que cambia código, y la recomendación es B, solo Quicknet. TypeScript y Dart no cambian hasta la aprobación.
+
 **Revisión de completitud contra la v0.13 (6-10, noche).** [REVISION_completitud_v0.13.md](REVISION_completitud_v0.13.md), de un agente Opus: de los ocho puntos de la revisión de la v0.8.2, el escritor está hecho; el versionado, lo que no se garantiza y la firma con la `.dkk` protegida, en parte; y el riesgo del proveedor, la revisión externa, la raíz de confianza y la recuperación a largo plazo, pendientes. Los tres pasos que propone antes de la v1.0: medir el área y cerrar el perfil CMS, una versión solo de texto que escriba lo que falta, y una revisión criptográfica externa. Para la próxima versión del spec, dos erratas: el título del §76 dice «v0.8.1», y el bloque de la v0.13 va antes que el de la v0.12. `FuzzCheckResolvedIP` es el objetivo 26 del fuzzing (Go `416c155`).
 
 **Fuzzing (6-10, noche).** `FUZZ_PARALLEL=4 scripts/fuzz.sh 60s` sobre `69dbb0c`, los 25 objetivos, `FuzzParseInfo` y `FuzzCheckURI` incluidos: limpio, sin entradas nuevas que fallen.
diff --git a/README.md b/README.md
index 444393f..4f76f62 100644
--- a/README.md
+++ b/README.md
@@ -46,6 +46,7 @@ Para retomar el trabajo, lee [HANDOFF.md](HANDOFF.md): el estado de cada repo, l
 | [PLAN_fase3_escritura.md](PLAN_fase3_escritura.md) | Fase 3, writer TypeScript del formato 2 (v0.9). v3, hecha: la librería, su interoperabilidad con Go y la página `/create` (hasta `3a9d2b1` de `datekeys-ts`) |
 | [REVISION_completitud_protocolo.md](REVISION_completitud_protocolo.md) | Qué le falta al protocolo antes de la v1.0 |
 | [REVISION_completitud_v0.13.md](REVISION_completitud_v0.13.md) | La misma revisión contra la v0.13 (6-10): qué está hecho, los huecos nuevos y los tres pasos siguientes antes de la v1.0 |
+| [spec_v0.14/](spec_v0.14/decisiones.md) | El borrador v0.14: las [decisiones para el autor](spec_v0.14/decisiones.md), con su recomendación |
 | [spec_v0.9/](spec_v0.9/README.md) | Papeles de trabajo del borrador v0.9: diseño, revisiones y correcciones pendientes |
 | [spec_v0.10/](spec_v0.10/formato3_diseno.md) | Formato de cápsula 3 en diseño, en tres entregas: varios ficheros, firma de autor y sello de tiempo. El diseño, con sus revisiones incorporadas, la revisión de Fable y la revisión final del borrador del spec |
 | [spec_v0.11/](spec_v0.11/llave_palabras.md) | Papeles de trabajo de la v0.11, ya etiquetada. Contiene: <br>la [llave de palabras](spec_v0.11/llave_palabras.md); <br>la [consulta a Fable y Astra sobre el tamaño del área de firmas y sellos](spec_v0.11/area_firmas_para_revision.md) y [su propuesta](spec_v0.11/revision_fable_astra.md); <br>la [revisión del borrador](spec_v0.11/revision_borrador.md); <br>la [revisión de lo hecho en la sesión del 1 y 2 de octubre](spec_v0.11/revision_sesion_1_2_octubre.md), con los fallos pendientes de arreglar |
diff --git a/spec_v0.14/decisiones.md b/spec_v0.14/decisiones.md
new file mode 100644
index 0000000..9a48151
--- /dev/null
+++ b/spec_v0.14/decisiones.md
@@ -0,0 +1,61 @@
+# Borrador v0.14: decisiones para el autor
+
+*6 de octubre de 2026. El borrador está en la rama `v0.14` de `datekeys-go` (`49b3764`), en `spec/DateKeys_Protocol_Specification_v0.14.md`. Sale del paso 2 de la [revisión de completitud contra la v0.13](../REVISION_completitud_v0.13.md): escribir lo que falta antes de la v1.0. No cambia ningún formato ni ningún veredicto, y su §76 recoge los siete cambios con su caso.*
+
+Cada decisión trae la recomendación. Si las apruebas todas tal como están, basta con decir «apruebo el borrador», como con la v0.12 y la v0.13. La 8 es la única que cambia código.
+
+## Lo que ya está escrito en el borrador
+
+1. **Lo que no se garantiza (§5).** Añade que antes de la fecha nadie puede comprobar que una cápsula se abrirá, por lo que no sirve sola para demostrar una puja o una predicción; y tres no objetivos: caducidad, condiciones distintas de una ronda y cancelación.
+   - Recomendación: aprobar.
+
+2. **El proveedor (§7.6, §36.1).** §7.6 deja de ser una frase. Separa la confidencialidad hasta la fecha, que falla si el umbral de drand se pone de acuerdo, de la apertura después, que falla si drand deja de firmar o nadie guarda el release. Dice que no hay otra vía de apertura. Una cápsula `time_and_key` protege la primera y no la segunda, y el SDK oficial SHOULD recomendarla para horizontes largos o contenidos valiosos.
+   - Recomendación: aprobar. Para la página `/create`, es un aviso más que habría que añadir cuando se apruebe.
+
+3. **Los estados de un perfil (§71).** `activo`, `solo lectura` (no se escriben cápsulas nuevas, se siguen abriendo) y `comprometido` (se abren, con un aviso de que pudieron leerse antes). Una entrada publicada no se retira nunca del registro.
+   - Recomendación: aprobar.
+
+4. **Las firmas y los sellos frente a un adversario cuántico (§7.7, §53).** Dice que tampoco son post-cuánticos los recipients X25519, las firmas de autor ni las de las autoridades de sellado, y que un veredicto F3, F4, F6 o S4 leído décadas después prueba menos.
+   - Recomendación: aprobar.
+
+5. **El cliente web (§7.10, §59).** Un §7.10 nuevo cuenta con una página sustituida por quien controla el dominio o la construcción. §59 pide, como SHOULD, builds reproducibles con sus hashes publicados, Subresource Integrity en cada script, una política de contenido sin código de otro origen y un cliente que funcione sin conexión.
+   - Recomendación: aprobar. La página ya tiene la política de contenido. Lo demás es trabajo para `datekeys-ts` cuando se publique la página.
+
+6. **La entropía de la llave de palabras (§38.1).** El SDK oficial SHOULD ofrecer por defecto palabras al azar, al menos 6 de una lista pública de 2048 o más (unos 66 bits), y decir que unas palabras elegidas por una persona no son adecuadas para un contenido valioso. La derivación no cambia.
+   - Alternativa: solo el aviso, sin generar palabras.
+   - Recomendación: aprobar lo escrito. Generar palabras exige una lista, que sería un fichero de datos propio, no una dependencia: cuál, en qué idioma y de qué licencia lo decides tú cuando toque hacerlo.
+
+7. **La raíz de confianza, byte a byte (§12, §35, §51, §63 pasos 10 y 11).** El spec ya no remite a «drand/kyber». Ahora escribe:
+   - el mensaje que firma una ronda: SHA-256 de la ronda en 8 bytes;
+   - su hash a G1, con la suite y el DST de RFC 9380;
+   - la ecuación del paso 10;
+   - H2, H3 y H4 del IBE de tlock, con sus etiquetas en bytes. H3 incluye el desplazamiento de un bit, que es fácil de implementar mal.
+
+   Lo ha sacado un agente del código de las tres implementaciones y de drand, kyber y tlock, y lo comprueba un vector nuevo, `tlock_steps.json`, con cuatro rondas publicadas y cinco stanzas.
+   - Recomendación: aprobar.
+
+## Lo que el borrador deja abierto
+
+8. **Los tres schemes de §12.1.** §12.1 admite tres schemes de drand, pero el texto solo fija byte a byte el de Quicknet. Además, Go verifica los tres y TypeScript y Dart solo Quicknet, así que las implementaciones ya divergen.
+   - A: dejarlo así.
+   - B: admitir solo `bls-unchained-g1-rfc9380`, el de Quicknet. Cambia la validación de perfiles en Go, TypeScript y Dart, y ninguna cápsula válida.
+   - C: admitir los tres al leer un perfil, y dejar que un lector rechace en el paso 10 los que el texto no fija.
+   - Recomendación: **B**. Cierra la divergencia, y un proveedor nuevo sería un perfil nuevo (§10).
+
+9. **«Una representación firmada equivalente» del perfil (§12).** El borrador la quita: ninguna implementación la tenía y nada la definía.
+   - Alternativa: moverla a «Trabajo futuro» de §74.
+   - Recomendación: dejarla quitada.
+
+10. **Los valores intermedios del hash a G1 en los vectores.** `tlock_steps.json` da el mensaje y el punto, pero no los valores intermedios de RFC 9380. Darlos exigiría que Go importe directamente kilic/bls12-381, que ya va en el módulo como dependencia indirecta.
+    - Recomendación: no darlos. Dart ya comprueba su hash a G1 con los vectores de RFC 9380.
+
+## Al aprobar
+
+Como con la v0.12 y la v0.13:
+- la fecha de la cabecera;
+- `SpecVersion` 0.14;
+- el SHA-256 en `spec/README.md`;
+- el tag `spec-v0.14` y `main`;
+- TypeScript y Dart, con `testdata` en el tag y una prueba que recorra `tlock_steps.json`. En TypeScript, la guarda falla si un fichero de `testdata` no lo corre ninguna prueba.
+
+Si eliges B en la decisión 8, también el cambio de código en los tres repos. Además, `ibe.ts` e `ibe.dart` dicen en un comentario que H3 «pone a cero el bit más alto», cuando el código lo desplaza, que es lo correcto: se corrige el comentario.