datekeys-doc/spec_v0.10/revision_borrador.md

# Revisión final del borrador del spec v0.10 (30-09-2026)

*Revisión del borrador de la entrega 1 del formato 3, en `datekeys-go`, rama `v0.10`, commit `fa7f95e`. La hizo un revisor adversarial, como la revisión final de la v0.9, contra el diseño ([formato3_diseno.md](formato3_diseno.md)) y el spec v0.9. Las quince correcciones están aplicadas en el commit siguiente de la rama.*

**Veredicto:** el traslado del diseño es fiel. Están las diez decisiones del apartado 9 del diseño, nada de las entregas 2 y 3 entra como normativo, y no se pierde nada de la v0.9. Los problemas son una consecuencia no prevista de R6c, que el diseño también tenía, y la redacción de algunos puntos de determinismo.

| # | Gravedad | Sección | Problema | Corrección |
|---|---|---|---|---|
| 1 | Bloqueante | §29.5, R6c; §76, cambio 5 | R6c rechazaba cualquier carácter ASCII de R4 en una proyección best-fit. bestfit1250 lleva «¿» a '?', bestfit874 lleva «§», «¶», «♥» y las flechas a controles C0, bestfit1253 lleva «←» y «→» a '<' y '>', y bestfit1252 lleva U+3000 a U+0020. «¿Qué es esto.jpg» o «Para ti ♥.jpg» se habrían rechazado, y relajarlo después exigiría un formato nuevo. | R6c solo rechaza '/', '\', ':' y U+0000, que cambian el destino con la API ANSI de Windows, y sigue aplicando R3, R5, R6 y R6b a la proyección. Los demás hacen fallar la creación del fichero, pero no cambian su destino. |
| 2 | Mayor | §63, paso 17; §69.1; §76, cambio 8 | «Autenticar los P bytes» dejaba fuera los datos tras el chunk final, que `filippo.io/age` señala en la lectura siguiente; 17.1 incluía la comprobación del relleno, que también es 17.8; y 17.3 y 17.6 contaban como fallos. | Los códigos distintos de `ERR_INTEGRITY` se informan tras leer `PAYLOAD_AGE` hasta EOF; 17.1 excluye el relleno; 17.3 y 17.6 nunca fallan. |
| 3 | Mayor | §29.7 | Faltaba el orden de las filas: un `seal` con una clave desconocida y un `seal_type` desconocido daba S1 o S2 según el lector. | Decide la primera fila que se cumple; `alg` y `seal_type` solo se leen de un contenido que cumple su schema. |
| 4 | Mayor | §58, §70 | Las dos secciones rechazaban toda codificación no canónica y toda versión desconocida, también en `security`, contra la regla de que `security` nunca decide la apertura. | Excepción explícita para `SECURITY_CBOR` y el contenido de sus claves 2 y 3: solo cambian los veredictos. |
| 5 | Menor | §76, cambio 8; §64; §69.1 | El caso era falso: con el chunk siguiente corrupto, las dos librerías entregan antes el del head. Solo divergen con el fichero cortado justo tras un chunk completo. | Caso, mutación y ejemplo nuevos con una ruta «..» y el corte exacto tras el chunk que la contiene. |
| 6 | Menor | §29.7 | Los textos de los veredictos eran solo del SDK oficial, con un MUST imposible de comprobar. | El SDK oficial MUST usar esos textos; otra implementación, esos textos o una traducción que no afirme más. |
| 7 | Menor | §29.7 | No quedaba claro si la presentación valía para una salida redirigida, y una ruta larga podía imitar un veredicto. | La regla vale para toda salida de texto, y cubre también las rutas. |
| 8 | Menor | §70 | Faltaba la regla del diseño para una interfaz que solo entrega un flujo de bytes. | Termina tras el paso 2 con un error del llamador, nunca con `ERR_UNSUPPORTED_VERSION`. |
| 9 | Menor | §62.1, regla 13 | Cuatro fixtures de §67 solo se pueden escribir incumpliendo la regla del área y de `security` vacío. | Excepción para un generador de vectores de prueba. |
| 10 | Menor | §76 | La lista de datos de prueba que cambian estaba incompleta. | Lista completa: dos mutaciones, `cbor.json`, el campo `spec`, `testdata/README.md` y las pruebas de las dos implementaciones. Comprobado que ninguno de los 4 380 casos del diferencial deja `VERSION` 3. |
| 11 | Menor | §64, §67 | Faltaban mutaciones de R1, R5, R7, R9, el autor y la maquetación, y lo que cubren los vectores. | Siete mutaciones más y un párrafo con la cobertura de los vectores. |
| 12 | Menor | §76, cambios 2 y 3 | Las cifras del cambio 2 suponían la mtime sin decirlo, y el cambio 3 citaba un límite de 8192 bytes que el texto no tiene. | Caso con mtime; el límite, atribuido al borrador anterior del diseño, con los tamaños de SLH-DSA. |
| 13 | Menor | §62.1, regla 16 | El MUST de tomar la mtime chocaba con la opción de quitarla. | El MUST vale solo si el escritor la incluye. |
| 14 | Menor | §29.5.1 | El conjunto de tablas no estaba cerrado: faltaba la clase de combinación canónica y la lista exacta de los quince ficheros best-fit. | Lista cerrada. Sus SHA-256 siguen por fijar al implementar. |
| 15 | Menor | §57, §69.1, §70, §73, §74, CDDL | Coherencia editorial. | Seis retoques. |

**Comprobado por el revisor:** las diez decisiones; los tamaños, recalculados con un codificador CBOR propio; las afirmaciones sobre Unicode, Node y Go; varias tablas best-fit de un solo byte; el CDDL frente al texto; y las referencias cruzadas.

**Sin comprobar:** la resolución 8.3 en NTFS, HFS+, los mapeos de Cygwin, WSL y el SMB de macOS, los anchos de un terminal CJK, los datos de UCD 17.0.0, las tablas best-fit de doble byte (932, 936, 949, 950 y 1361) y la sintaxis del CDDL con una herramienta.