datekeys-go branch v0.10, unpushed, holds the nine steps of the plan,
from 631d09c to 6fa2b54, and a fix of the CLI, 735885c. scripts/check.sh
60s is clean. The handoff records what was done, the checks, what the
author has to decide (the push and the tag spec-v0.10, an editorial
change in section 67 of the approved text, the size of the mutation
corpus) and what datekeys-ts starts with. The plan marks each step with
its commit.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
# Handoff DateKeys, 26 de septiembre de 2026 (actualizado el 30 por la tarde: borrador del spec v0.10 de la entrega 1, revisado)
# Handoff DateKeys, 26 de septiembre de 2026 (actualizado el 30 por la noche: el formato 3 implementado en la referencia Go)
Estado al parar la sesión del 26 por el límite semanal de uso. Se actualizó el 28 de septiembre tras cerrar la v0.8.2 del spec (§2.1), el 29 de madrugada tras cerrar la fase 2 (§2.2), el 29 a mediodía tras reorganizar el espacio de trabajo (§0) y el 29 por la noche tras implementar el formato 2 de la v0.9 en Go y en TypeScript, poner el tag `spec-v0.9` y escribir el writer TypeScript con su interoperabilidad con Go (§2.5). El 30 de madrugada se diseñó el formato de cápsula 3 y Fable lo revisó; a mediodía se aplicaron al diseño esa revisión y las decisiones del autor, y quedó separado en tres entregas; por la tarde, el autor cerró las preguntas de la entrega 1, y se redactó y revisó el borrador del spec v0.10 (§2.5, al final). Sirve para retomar sin contexto previo, sea una persona o una sesión de Claude.
Estado al parar la sesión del 26 por el límite semanal de uso. Se actualizó el 28 de septiembre tras cerrar la v0.8.2 del spec (§2.1), el 29 de madrugada tras cerrar la fase 2 (§2.2), el 29 a mediodía tras reorganizar el espacio de trabajo (§0) y el 29 por la noche tras implementar el formato 2 de la v0.9 en Go y en TypeScript, poner el tag `spec-v0.9` y escribir el writer TypeScript con su interoperabilidad con Go (§2.5). El 30 de madrugada se diseñó el formato de cápsula 3 y Fable lo revisó; a mediodía se aplicaron al diseño esa revisión y las decisiones del autor, y quedó separado en tres entregas; por la tarde, el autor cerró las preguntas de la entrega 1, y se redactó y revisó el borrador del spec v0.10 (§2.5, al final). Por la noche, el autor aprobó ese borrador, con Unicode 18.0.0 y la regla de invisibles, y la referencia Go implementó el formato 3 (§2.5, al final). Sirve para retomar sin contexto previo, sea una persona o una sesión de Claude.
---
@ -37,7 +37,7 @@ Los repos con remoto están en el Gitea privado `g.activething.com` (solo LAN, c
| `datekeys-go` (`go/DateKeys`) | `main` | `7e2d83c` | Spec v0.9 cerrada, con el tag anotado **`spec-v0.9`** en `7e2d83c`; SHA-256 del spec `36189e1e62f0f835b7665219aa63df7200cd89ac4e4e924f2705f970fa7c40a9`. Implementa el formato 2 (`f24a280`): lo escribe y lee los formatos 1 y 2. `scripts/check.sh 60s` limpio. La v0.8.2 sigue en su tag, `spec-v0.8.2` (`9ac9cd9`). |
| | `v0.8.2` | `9ac9cd9` | El commit del tag; ya no hace falta. |
| | `v0.9` | `7e2d83c` | Igual que `main`; ya no hace falta. |
| | `v0.10` | `9d1cd2e` | Borrador del spec v0.10, entrega 1 del formato 3: el spec, el CDDL y `spec/README.md`. Sin aprobar y sin subir; el código sigue en la v0.9. |
| | `v0.10` | `6fa2b54` | Spec v0.10, entrega 1 del formato 3, aprobada por el autor el 30-09 e implementada: escribe el formato 3 y lee los formatos 1 a 3, con `SpecVersion` 0.10. SHA-256 del spec `7f26419a444aa3e89a3aa8afbbba9d952af69e048aee1e93cd70732c2d1d99d1`. `scripts/check.sh 60s` limpio. Sin subir: la rama y el tag `spec-v0.10` esperan la autorización del autor (§2.5). |
| `datekeys-ts`, antes `App` (`go/DateKeys-App`) | `main` | `da26862` | Desde `5ee8813`, sin `docs/` y con el paquete `datekeys-ts` (§0). Versión `0.2.0-dev` desde `8c08c97`, con `v0.1.0` cerrada en `d577283`; implementa el spec 0.9 desde `0118890` (`VERSION` y `SPEC_VERSION`, también en el pie de la página). Escribe el formato 2 y tiene la página `/create` (fase 3, §2.5). Librería TypeScript con la inspección (pasos 1 a 8) y la apertura (pasos 9 a 18) de los formatos 1 y 2, en memoria o desde un `Blob` hacia un stream de salida, como un fichero OPFS. Página `/inspect` con la acción "abrir", que muestra el formato y avisa del 1. `testdata` sincronizado a `7e2d83c` (`spec-v0.9`). Fase 2 completa (pasos 2 a 8), incluidos el cifrado tlock y la interoperabilidad de TypeScript a Go. Los 125 casos del corpus pasan por `open` con el código, el paso y el texto de Go. En `0118890`, 5 425 tests, ninguno saltado; la fase 3 añadió los suyos, con `npm run verify` en verde en cada paso (§2.5). |
| `docs` (solo local) | `main` | | Este repo: handoff, planes, revisiones y reglas. |
@ -245,12 +245,30 @@ El vector de GT (`vectors/tlock_ibe.json`) ya está cubierto en `App`. El paso 9
- 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. 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.
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.
2. Hecho: el autor aprobó la regla de invisibles («sí a las dos»), que el spec recoge en R4b y en §29.6 (`631d09c`).
3. Hecho: con su permiso se descargaron los 19 ficheros de datos, 8,25 MB, en `datekeys-go/.cache/`, fuera de git.
4. Hecho: la referencia Go implementa el formato 3, con el [plan](PLAN_formato3_go.md) y el detalle de abajo. **Pendiente del autor:** autorizar la subida de la rama `v0.10` y el tag `spec-v0.10`, como en la v0.9.
5. **Siguiente:**`datekeys-ts` sincroniza `testdata` y lee y escribe el formato 3, con un plan propio.
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.
**Hecho el 30-09 por la noche: el formato 3 en Go.** Rama `v0.10` de `datekeys-go`, sin subir, un commit o varios por paso del plan:
- `631d09c`, el spec con la regla de invisibles; `6fba1dd`, paso 1, `internal/pathrule` con las tablas de Unicode 18.0.0 y best-fit generadas y su `TablesDigest`; `72e86b8`, paso 2, el códec de `BODY`, `security` y el head.
- `7249ef4`, paso 3, el lector: `capsule.Sink`, `ErrSinkRequired` justo tras el paso 2, el paso 17 en subpasos con su precedencia, y lecturas de `BODY` que crecen con los bytes recibidos (§57).
- `8955c0f`, paso 4, el escritor `capsule.EncryptFiles`, que lee cada fichero dos veces; `Encrypt` solo escribe el formato 2 con `EncryptOptions.TestVectors`.
- `a0de80f`, paso 5, el CLI: `encrypt -in` con ficheros y carpetas, `-comment`, `-author` y `-no-mtime`; `decrypt -out CARPETA` con `os.Root`; la presentación de §29.7, con el ancho del terminal pedido por `syscall`, sin dependencias nuevas.
- Paso 6, datos de prueba: `3c39336` (`SpecVersion` 0.10 y `ERR_HEAD_INVALID`), `e070f89` (las nueve fixtures), `db862d5` (`paths.json`, `path_fold.json`, `head_schema.json`, `security.json` y el control de versión 3 en `cbor.json`) y `18eb3c3` (las mutaciones: 209 casos, 169 del §64, tres de los cuales se abren con su veredicto).
- `20f9959`, paso 7, la documentación; `735885c`, una corrección del CLI: una carpeta de salida sin su carpeta padre falla antes de pedir el release; `6fa2b54`, paso 8, tres objetivos de fuzzing nuevos (`FuzzDecodeHead`, `FuzzEvaluateSecurity`, `FuzzCheckPath`) y el SHA-256 del spec en `spec/README.md`.
- Verificación: `go test ./...` y `scripts/check.sh 60s` limpios, cobertura de `capsule` 93,1 %; la prueba en vivo contra Quicknet abrió cápsulas de formato 3 de las dos políticas; los tres objetivos nuevos, cerca de un millón de ejecuciones cada uno, sin fallos.
- Para el autor, sin urgencia:
- un cambio editorial en el texto aprobado: §67 decía «Serán … (por implementar)» de las fixtures del formato 3, y ahora dice «Son …». El SHA-256 de `spec/README.md` es el del texto con ese cambio;
- el corpus de mutaciones pasa de 168 KB a 706 KB. 476 KB son el caso de 65 536 carpetas implícitas que pide el §64, cuyo head mide 235 KB;
- los textos del CLI que el spec no fija son de la referencia: la cabecera «Ficheros escritos en CARPETA (N):», los avisos de nombres peligrosos y los mensajes del escritor. Los que fija, los veredictos y las dos etiquetas, van literales.
- Para `datekeys-ts`:
- el generador de tablas aún no escribe el módulo TypeScript, que el plan preveía con una bandera: es el primer paso de su plan, con el mismo `TablesDigest`;
- `testdata` cambia entero de `"spec"`, y añade nueve fixtures, cuatro ficheros de vectores, `mutations.json` con 209 casos (`version changed` pone ahora `VERSION` 4, y hay casos con `verdicts`) y el diferencial con 5 110;
- los textos de las reglas de rutas y de texto deben coincidir byte a byte: `paths.json` y `head_schema.json` los traen en `result` y `detail`.
- Herramientas: en esta máquina los heredocs de Bash rompen apóstrofos y barras invertidas, y la herramienta Write convierte `\uXXXX` en caracteres literales. Funciona escribir los cambios como scripts de Python en el scratchpad.
**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.
- Un fichero único `.dk` con `.dkc` y `.dkk` juntos no conviene: con `time_and_key` equivaldría a `time_only`. Ya se envía un solo fichero con `time_only` o con destinatarios `age1…`.
@ -278,7 +296,7 @@ Están en el [README](README.md#reglas) de este repo, que el `CLAUDE.md` de la r
- En este repo están los planes, la revisión del protocolo y los papeles de la v0.9. El [README](README.md#documentos) los lista.
- En `datekeys-go`:
- `spec/DateKeys_Protocol_Specification_v0.9.md`, cerrado con el tag `spec-v0.9`,`spec/DateKeys_Protocol_Specification_v0.8.2.md`, `spec/datekeys.cddl` y `spec/README.md`;
- `spec/DateKeys_Protocol_Specification_v0.10.md`, aprobado e implementado en la rama `v0.10`, pendiente de su tag; `spec/DateKeys_Protocol_Specification_v0.9.md`, cerrado con el tag `spec-v0.9`;`spec/DateKeys_Protocol_Specification_v0.8.2.md`, `spec/datekeys.cddl` y `spec/README.md`;
- `testdata/README.md`, que documenta los ficheros compartidos para segundas implementaciones;
- `docs/traceability.md` y `CHANGELOG.md`.
- Las herramientas de verificación de las sesiones del 26 al 28-09 estaban en carpetas temporales y pueden haber desaparecido: el diferencial Go/TypeScript de `tsreview/` y las copias congeladas `dkgo-ref-<commit>`. Su descripción está en los mensajes de los commits de `datekeys-ts` y en su README.
# Plan: formato 3 en la referencia Go (spec v0.10, entrega 1)
*Estado, 30-09 por la noche: pasos 0 a 8 hechos en la rama `v0.10`, sin subir; el tag `spec-v0.10` espera la autorización del autor. Detalle en el [handoff](HANDOFF.md), §2.5.*
*30 de septiembre de 2026. Implementa en `datekeys-go`, rama `v0.10`, el texto que el autor aprobó ese día: la entrega 1 del formato 3, con Unicode 18.0.0 y la regla de invisibles. Fuentes: el spec v0.10 de esa rama y [spec_v0.10/formato3_diseno.md](spec_v0.10/formato3_diseno.md). Después, `datekeys-ts` seguirá con su propio plan.*
## Reglas de trabajo
@ -14,14 +16,14 @@
| Paso | Contenido | Resultado |
|---|---|---|
| 0 | Datos: los 4 ficheros de Unicode 18.0.0 y los 15 de WindowsBestFit, en `.cache/`, fuera de git | Hecho el 30-09: 8,25 MB, con sus SHA-256 |
| 1 | `internal/pathrule`: generador de tablas y reglas de rutas y de texto | R2 a R7, R4b, R9, R10 y §29.6, con sus pruebas |
| 2 | `capsule`: formato 3 en el códec | `Format3`, control de versión 3, trama de `BODY`, `security`, head, `ErrHeadInvalid` |
| 3 | Lector: paso 17 del formato 3 y el sumidero | Subpasos 17.1 a 17.8, su precedencia y la lectura hasta EOF |
| 4 | Escritor del formato 3 | `EncryptFiles`, con dos pasadas; `Encrypt` queda para los generadores de pruebas |
| 5 | CLI | `encrypt -in` con carpetas, `-comment`, `-author`, `-no-mtime`; `decrypt -out DIR`; presentación de §29.7 |
| 6 | Datos de prueba | Fixtures `format3_*`, vectores de rutas, del head y de `security`, mutaciones y diferencial |
| 7 | Documentación y versión | README, CHANGELOG, `docs/traceability.md`, `testdata/README.md`, `SpecVersion` |
| 8 | Verificación y cierre | `check.sh` con fuzzing nuevo, SHA-256 del spec y tag `spec-v0.10` con la autorización del autor |
| 1 | `internal/pathrule`: generador de tablas y reglas de rutas y de texto | Hecho, `6fba1dd`. Falta la salida TypeScript del generador, que pasa al plan de `datekeys-ts` |
| 2 | `capsule`: formato 3 en el códec | Hecho, `72e86b8` |
| 3 | Lector: paso 17 del formato 3 y el sumidero | Hecho, `7249ef4` |
| 4 | Escritor del formato 3 | Hecho, `8955c0f` |
| 5 | CLI | Hecho, `a0de80f` |
| 6 | Datos de prueba | Hecho, de `3c39336` a `18eb3c3` |
| 7 | Documentación y versión | Hecho, `20f9959`; `SpecVersion` pasó a 0.10 en el paso 6 |
| 8 | Verificación y cierre | Hecho, `6fa2b54`, salvo el tag `spec-v0.10`, que espera al autor |
