# Borrador v0.15: decisiones para el autor

*7 de octubre de 2026. El borrador está en la rama `v0.15` de `datekeys-go` (`b7402bd`), en `spec/DateKeys_Protocol_Specification_v0.15.md`. Es la recuperación a largo plazo del [diseño](../diseno_recuperacion.md), con la opción A y las ocho recomendaciones que aprobaste el 6-10. Lo hizo un agente Opus; la sesión revisó el paso 9.c en el código. `scripts/check.sh` pasa entero, con un script nuevo que abre dos fixtures siguiendo solo el anexo.*

Si apruebas lo que sigue tal como está, basta con decir «apruebo el borrador». Al aprobarlo se cierra como la v0.14 y se lleva a TypeScript, a Dart y al paquete de la revisión externa.

## Lo que hace el borrador

1. **El objeto de release y el fichero `.dkr`** (§20, §47, §47.1 nueva, CDDL). Es un CBOR de 111 bytes: `{0: "datekeys-release", 1: 1, 2: chain_hash, 3: ronda, 4: firma}`. No lleva firma propia ni la marca de «verificado»: se comprueba contra el perfil fijado. Los lectores siguen aceptando el JSON de drand como entrada, pero un escritor nunca lo guarda.
2. **La cadena en el paso 10** (§51, §63). Primero las capas del objeto, después `chain_hash` (`ERR_PROFILE_MISMATCH`), la ronda y la firma. No hay códigos de error nuevos.
3. **El paso 9.c, opción B** (§49, §63). El reloj local solo cuenta antes de pedir a la red. Un release que el lector ya tiene, pegado, de un fichero o de un archivo local, no se compara con el reloj, y el lector MAY avisar de que el reloj va atrasado.
4. **La recuperación a largo plazo** (§50, §53, §62.1 reglas 26 a 28):
   - el `.dkr` junto al `.dkc` es el camino principal, y también junto a una `.dkk` con localizador;
   - el archivo de releases es un formato informativo, sin prometer dónde se aloja;
   - el SDK SHOULD avisar al sellar, guardar el anexo y guardar el `.dkr` pasada la fecha.
5. **La Release API** (§45): su respuesta es el objeto de release; la forma HTTP es informativa.
6. **El §74:** salen los dos puntos de trabajo futuro que esto cubre, y entran la extensión `datekeys.release` de la `.dkk` y un archivo publicado.
7. **El anexo de recuperación** (§79 nueva, informativa, después del §78 para no renumerar el §77). Explica cómo abrir una cápsula `time_only` y una `time_and_key` sin el software de DateKeys:
   - los parámetros de Quicknet;
   - la trama;
   - la verificación del release;
   - el stanza tlock;
   - cómo abrir un fichero `age` desde su file key;
   - las capas X25519 con `age -d`;
   - el contenido de cada formato.

   `scripts/recovery_check.sh` lo demuestra con código que no importa nada de DateKeys, ni tlock ni drand.

## Lo que el agente decidió distinto del diseño, para que lo apruebes o no

8. **Un límite de tamaño del objeto: de 1 a 1024 bytes**, con `ERR_NON_CANONICAL_CBOR`. Así el código de error no depende de cuánto lea un lector. La firma, de 1 a 96 bytes en el CDDL; otra longitud dentro de ese rango da `ERR_RELEASE_INVALID`.
   - Recomendación: aprobar.
9. **Un JSON de drand mal formado da `ERR_RELEASE_INVALID` en el paso 10.** Solo es una entrada de quien llama y nunca se escribe.
   - Recomendación: aprobar.
10. **Los fallos del archivo de releases dan `ERR_RELEASE_UNAVAILABLE` en el paso 9.** Una ronda que el archivo no tiene o no cubre, de otra cadena, o con otra longitud. Una ronda a ceros cuenta como ausente, no como firma que no verifica.
    - Recomendación: aprobar. El formato del archivo es informativo y no tiene códigos propios.
11. **Lo que no hace la CLI de Go:**
    - la opción de pedir a la red antes de la fecha aunque el reloj diga que no ha llegado, que el spec deja como MAY;
    - guardar el anexo junto a las cápsulas y avisar del release al sellar, que son SHOULD del SDK.

    Lo demás sí: `decrypt -release FICHERO`, `decrypt -save-release` y la orden nueva `datekeys release`, que pide, verifica y guarda el `.dkr`.
    - Recomendación: aprobar. Los SHOULD del SDK van con las recomendaciones de la v0.14 en los clientes, que siguen pendientes.

## Lo que cambia en los vectores

- **`vectors/release.json`, nuevo:** 36 objetos, 12 JSON de drand y 7 consultas a un archivo, cada uno con su resultado y el texto de Go.
- **`releases/`, nuevo:** los `.dkr` de las rondas 1000, 1001, 1004 y 2000, y un archivo de las rondas 1000 a 1004 con la 1002 y la 1003 a ceros.
- **`mutations.json`:**
  - cada caso dice ahora si su release está en la mano (`supplied`) o viene de la red (`network`);
  - «la ronda aún no ha llegado» pasa a abrir con un release en la mano, por la opción B;
  - hay cuatro casos nuevos: ese mismo caso desde la red, un release de otra ronda desde la red, y dos objetos de otra cadena.

  Son 222 casos, 178 del §64. Ningún otro cambia de resultado.

## Al aprobar

- Como la v0.14: la fecha de la cabecera, `SpecVersion` 0.15, el SHA-256, el tag `spec-v0.15` y `main`.
- TypeScript y Dart siguen el borrador: el objeto, la fuente en la mano, el paso 9.c, los vectores nuevos y el campo `source` del corpus. La guarda de TypeScript exige una prueba para cada fichero nuevo de `testdata`.
- El paquete de la revisión externa se pone al día con los commits nuevos y con la recuperación ya resuelta.
- Sale una `0.4.0` de TypeScript.