Format 3: Unicode 18.0.0, and the two answers pending before Go

The author chose Unicode 18.0.0 and approved the draft. The handoff
lists what implementation still needs from the author: a proposal to
close the invisible-character channel that Unicode 18 warns about, and
permission to download the Unicode and WindowsBestFit data files.

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

HANDOFF.md

@@ -91,7 +91,7 @@ El vector de GT (`vectors/tlock_ibe.json`) ya está cubierto en `App`. El paso 9
 
 ### 2.5 Sesiones del 29-09: v0.9 del spec y formato 2 en Go (retomar aquí)
 
-**Estado al parar (30-09 por la tarde). Retomar por el formato 3, al final de esta sección:** el borrador del spec v0.10 de la entrega 1 está redactado y revisado en `datekeys-go`, rama `v0.10` (`9d1cd2e`, sin subir). Queda que el autor elija la versión de Unicode de las tablas y apruebe el texto.
+**Estado al parar (30-09 por la tarde). Retomar por el formato 3, al final de esta sección:** el borrador del spec v0.10 de la entrega 1 está redactado y revisado en `datekeys-go`, rama `v0.10` (`9d1cd2e`, sin subir). El autor eligió Unicode 18.0.0 y dio el visto bueno al texto con «la 18.0.0, adelante». Antes de implementar faltan dos respuestas suyas: el permiso para descargar los datos de Unicode 18.0.0 y de WindowsBestFit, y la propuesta sobre los caracteres invisibles, que Unicode 18 señala como vía de ataque a aplicaciones de IA.
 
 **Estado al cerrar la fase 3 (29-09 por la noche):**
 - Pasos 1 a 5 hechos. El spec v0.9 está cerrado con el tag `spec-v0.9` (`7e2d83c`, en `main` de `datekeys-go`), y las dos implementaciones leen el formato 2: Go desde `f24a280`, que también lo escribe, y TypeScript desde `0118890`.
@@ -244,8 +244,9 @@ El vector de GT (`vectors/tlock_ibe.json`) ya está cubierto en `App`. El paso 9
   - La revisión final, como la de la v0.9, encontró un problema bloqueante, tres mayores y once menores, todos corregidos ([spec_v0.10/revision_borrador.md](spec_v0.10/revision_borrador.md)). El bloqueante: R6c rechazaba «¿», porque bestfit1250 lo lleva a '?'. Ahora solo rechaza '/', '\', ':' y U+0000 en una proyección. El diseño recoge los cambios que le afectan en su anexo D.
   - Pregunta del autor: la firma de autor con su clave privada está prevista, en la entrega 2. Varias firmas no hace falta decidirlas ahora: un `alg` futuro puede definir una lista de firmas sin cambiar el formato (pregunta 3 de la entrega 2 del diseño).
 - **Siguiente:**
-  1. El autor elige la versión de Unicode de las tablas. El diseño y el borrador dicen 17.0.0, pero Unicode 18.0.0 salió el 16-09-2026, con 13 007 caracteres nuevos. Las tablas quedan congeladas con el formato 3, así que la recomendación es la 18.0.0; el cambio toca §29.5.1, §73, §75, §76 y §77.
+  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. El autor aprueba el texto del spec v0.10.
+  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.

spec_v0.10/formato3_diseno.md

@@ -184,7 +184,7 @@ La entrega 1 congela el formato. Define la trama, el contenedor `security` con s
 3. HEAD: versión propia, sal, comentario, autor declarado y, por fichero, ruta, size, start, end, SHA-256 y mtime.
 4. SECURITY: siempre presente, en un área cuyo tamaño declara la trama y no depende del contenido.
 5. SECURITY nunca decide la apertura (objetivo 6 de §4, recuperación independiente): solo da veredictos de texto fijo.
-6. Rutas estrictas, con tablas propias de Unicode 17.0.0 y las proyecciones best-fit de Windows.
+6. Rutas estrictas, con tablas propias de Unicode 18.0.0 y las proyecciones best-fit de Windows.
 7. En el paso 17 prevalece cualquier fallo de `age` (`ERR_INTEGRITY`); si no lo hay, el orden del texto en claro. Código nuevo `ERR_HEAD_INVALID`.
 8. Entrega del contenido: un fichero, un ZIP propio o un árbol en un directorio nuevo. Un lector v0.9 rechaza el formato 3 en el paso 2.
 
@@ -278,8 +278,8 @@ R1 y R8 son capa 3 sobre todo el array; las demás, capa 4. Así, [«b/..», «a
   - C0 y U+007F–009F;
   - `" * : < > ? \ |`;
   - U+2028 y U+2029;
-  - todo punto con la propiedad `Default_Ignorable_Code_Point` de Unicode 17.0.0, salvo la lista blanca: ZWNJ, ZWJ, VS15 y VS16, que hacen falta en emoji y en varias escrituras. La propiedad cubre los controles bidi (U+061C, U+200E, U+200F, U+202A–202E, U+2066–2069), U+00AD, U+034F, U+200B, U+2060–206F, U+3164, U+FEFF, los demás selectores de variante y las etiquetas U+E0000–E007F, que permiten nombres visualmente idénticos;
+  - todo punto con la propiedad `Default_Ignorable_Code_Point` de Unicode 18.0.0, salvo la lista blanca: ZWNJ, ZWJ, VS15 y VS16, que hacen falta en emoji y en varias escrituras. La propiedad cubre los controles bidi (U+061C, U+200E, U+200F, U+202A–202E, U+2066–2069), U+00AD, U+034F, U+200B, U+2060–206F, U+3164, U+FEFF, los demás selectores de variante y las etiquetas U+E0000–E007F, que permiten nombres visualmente idénticos;
-  - los no-caracteres y todo Cn (sin asignar) de Unicode 17.0.0, que una versión futura podría plegar o volver ignorable;
+  - los no-caracteres y todo Cn (sin asignar) de Unicode 18.0.0, que una versión futura podría plegar o volver ignorable;
   - U+F000–U+F0FF, del área de uso privado: Cygwin, WSL y el SMB de macOS representan con ellos los caracteres prohibidos en Windows, así que «informe», U+F03A y «anexo» se verían allí como «informe:anexo».
 - **R5.** Ningún segmento empieza por U+0020 ni termina en U+0020 o '.'.
 - **R6.** El segmento hasta el primer '.', sin U+0020 finales y sin distinguir mayúsculas ASCII, no puede ser CON, PRN, AUX, NUL, CONIN$, CONOUT$, COM0–9, LPT0–9, COM¹²³ ni LPT¹²³.
@@ -292,18 +292,18 @@ R1 y R8 son capa 3 sobre todo el array; las demás, capa 4. Así, [«b/..», «a
 - **R6c.** Best-fit. Para cada `bestfit*.txt` de WindowsBestFit, fijadas por digest, se sustituye cada punto no ASCII que la tabla lleva a ASCII por ese byte. Se rechaza si alguna proyección contiene '/', '\', ':' o U+0000, o incumple R3, R5, R6 o R6b. Cubre ∖, ∶, ¥ (cp932), ₩ (cp949), ´ (cp1253), las formas de ancho completo, «ＣＯＮ.txt» y U+3000 en los extremos, que bestfit1252 lleva a U+0020. Los demás caracteres de R4 que dé una proyección no se rechazan: con la API ANSI de Windows hacen fallar la creación del fichero, pero no cambian su destino. Así se aceptan «¿», que bestfit1250 lleva a '?', y «§», «♥» y las flechas, que bestfit874 lleva a controles C0 (anexo D).
 - **R7.** Árbol plegado.
   - Nodos: las rutas y sus prefijos.
-  - Clave de cada segmento: NFD(pliegue(NFD(s′))), con s′ el segmento sin los puntos de la lista blanca de R4 y el pliegue C+F de CaseFolding 17.0.0 más ı → i (NTFS). Se quitan antes de normalizar porque los cuatro son starters (ccc 0): entre dos marcas combinantes, cambiarían su orden canónico. Los directorios con casefold de ext4 y f2fs también ignoraban los puntos ignorables al comparar, hasta 2025; no está comprobado aquí.
+  - Clave de cada segmento: NFD(pliegue(NFD(s′))), con s′ el segmento sin los puntos de la lista blanca de R4 y el pliegue C+F de CaseFolding 18.0.0 más ı → i (NTFS). Se quitan antes de normalizar porque los cuatro son starters (ccc 0): entre dos marcas combinantes, cambiarían su orden canónico. Los directorios con casefold de ext4 y f2fs también ignoraban los puntos ignorables al comparar, hasta 2025; no está comprobado aquí.
   - Se rechazan dos hermanos con la misma clave (A.txt/a.txt, NFC/NFD, «Fotos/a» y «fotos/b», Straße/STRASSE, Kelvin/k, «ab» con y sin ZWNJ) y una ruta que es a la vez fichero y carpeta («A» y «a/b»).
 - **R8.** Orden estrictamente ascendente de los bytes UTF-8 (§54). TypeScript MUST comparar los bytes, no los strings: `<` ordena por unidades UTF-16, y U+FF5E y U+1F600 salen al revés que en Go (hallazgo 6); `localeCompare` ordena por colación. Ninguno de los dos sirve.
 - **R9.** Como mucho 65535 carpetas implícitas.
 - **R10.** Ningún primer segmento cuya clave de R7 empiece por «.datekeys-». La CLI escribe el árbol en `DIR/.datekeys-*` antes de moverlo, y una entrada con ese nombre chocaría con él (hallazgo 10).
 
-**Tablas.** Un generador en `datekeys-go` las produce desde UCD 17.0.0 (UnicodeData, DerivedCoreProperties, CaseFolding y las descomposiciones) y desde WindowsBestFit, y emite código para los dos repos; sus suites comprueban el digest. MUST NOT usarse `normalize`, `toLowerCase`, las clases `\p{…}` de las expresiones regulares, el paquete `unicode` ni x/text: dependen de la versión de Unicode de cada motor.
+**Tablas.** Un generador en `datekeys-go` las produce desde UCD 18.0.0 (UnicodeData, DerivedCoreProperties, CaseFolding y las descomposiciones) y desde WindowsBestFit, y emite código para los dos repos; sus suites comprueban el digest. MUST NOT usarse `normalize`, `toLowerCase`, las clases `\p{…}` de las expresiones regulares, el paquete `unicode` ni x/text: dependen de la versión de Unicode de cada motor.
 
 **Escritor.**
 
 - Guarda los nombres tal como llegan.
-- Rechaza un UTF-16 mal formado y, con un mensaje que nombra el carácter, los puntos de R4 y los posteriores a Unicode 17.
+- Rechaza un UTF-16 mal formado y, con un mensaje que nombra el carácter, los puntos de R4 y los posteriores a Unicode 18.0.0.
 - No conserva carpetas vacías y deja editar las rutas.
 - Excluye por defecto `.DS_Store`, `Thumbs.db`, `desktop.ini`, `._*` y `__MACOSX/`, que se muestran tachados con un conmutador.
 
@@ -518,7 +518,7 @@ El autor cerró el 30-09 las diez preguntas abiertas, todas con la recomendació
 1. Hay un código nuevo, `ERR_HEAD_INVALID`: separa un escritor defectuoso de un CBOR roto.
 2. Los escritores de las entregas 1 y 2 usan `AREA_LEN` = 512: cuesta 490 bytes por cápsula y oculta la firma. Se descartó fijar ya un área de 4096.
 3. El área la fija la versión del spec, y el mapa `security` sigue en su versión 1 cuando llegue el sello. Así un lector de la entrega 2 sigue comprobando la firma en una cápsula de la entrega 3.
-4. Las tablas Unicode son propias, generadas de UCD 17.0.0.
+4. Las tablas Unicode son propias, generadas de UCD 18.0.0. El diseño decía 17.0.0, pero la 18.0.0 salió el 16-09-2026, y el autor la eligió ese mismo 30-09: las tablas quedan congeladas con el formato, y no se trabaja con versiones de Unicode ya superadas.
 5. El head va siempre en su versión 1. Una versión nueva exige un formato nuevo (§22), así que nunca falla tras la fecha por su versión.
 6. Los escritores de la v0.10 solo escriben el formato 3.
 7. Los límites quedan como se propusieron, y con el formato 3 quedan congelados: subirlos exigiría un formato nuevo.
@@ -851,7 +851,7 @@ Un revisor comprobó que los arreglos de Fable y las decisiones del autor están
 - el caso de Ed25519 en Go 1.26.8 y en noble 2.4.0;
 - las referencias al código y las cruzadas.
 
-Quedan sin verificar Unicode 17.0, las tablas WindowsBestFit, HFS+ en una máquina y los mapeos de Cygwin, WSL y el SMB de macOS.
+Quedan sin verificar los datos de Unicode, que desde entonces son los de la 18.0.0, las tablas WindowsBestFit, HFS+ en una máquina y los mapeos de Cygwin, WSL y el SMB de macOS.
 
 ## Anexo D. Revisión final del borrador del spec v0.10 (30-09)