A new section 0 records the reorganization of 29-09 and what is left for
the author: renaming App to datekeys-ts once no session holds it open,
opening sessions at the workspace root, deleting the duplicate
enquiry.php, and giving docs and web a remote if wanted.
Section 2.5 now says what was checked: the final review of the v0.9 draft
has 22 entries, not 21, and none is applied in 1189f2f, so all are
pending. It points to spec_v0.9/review.md and names the entry that needs
the author's decision (the section 56 MUST NOT).
The repository table follows the new folder names, and the rules and the
document list now point to the README.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
# Handoff DateKeys, 26 de septiembre de 2026 (actualizado el 29 por la noche)
# Handoff DateKeys, 26 de septiembre de 2026 (actualizado el 29 a mediodía)
Estado al parar la sesión del 26 por el límite semanal de uso, actualizado el 28 de septiembre tras cerrar la v0.8.2 del spec (§2.1) y el 29 tras cerrar la fase 2 (§2.2). 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) y el 29 a mediodía tras reorganizar el espacio de trabajo (§0). Sirve para retomar sin contexto previo, sea una persona o una sesión de Claude.
---
## 0. Reorganización del espacio de trabajo (29-09, mediodía)
`G:\bussines\datekeys` se reorganizó el 29-09. El mapa de carpetas y las reglas del proyecto están ahora en el [README](README.md) de este repo. Los cambios:
- **Documentos:** los del proyecto, este incluido, pasaron de `App/docs` a este repo, `docs`, que es privado y no tiene remoto. Su primer commit es `6e8d6c6`. Los papeles de trabajo de la v0.9, que solo estaban en una carpeta temporal, están en [spec_v0.9/](spec_v0.9/README.md).
- **`App`:** quitó `docs/`, y el paquete, el README y el aviso de licencias del sitio pasan a llamarse `datekeys-ts` (`5ee8813`, subido). `npm run verify` sigue en verde, con 2 611 tests.
- **Archivo y logos:**
- `AppOld` pasó a `archive/prototype`, sin cambios;
- los borradores v0.1 a v0.8.1, que estaban en Descargas, pasaron a `archive/spec-drafts`, con los hashes comprobados;
- los logos pasaron a `brand/`.
- **Claude:**
- la memoria de Claude es ahora la de la raíz. La de `App` queda congelada, con una nota que remite a la nueva;
- en la raíz hay un `CLAUDE.md`, que carga el README, y un `.claude/launch.json` para las vistas previas.
- **Nombres:** en las secciones siguientes, `App` es el repo que ahora se llama `datekeys-ts`. Su remoto sigue siendo `go/DateKeys-App`.
Pendiente del autor, antes de seguir:
1. Cerrar la sesión abierta en `App` y renombrar la carpeta a `datekeys-ts`. Windows no deja renombrar una carpeta en uso.
2. Abrir las sesiones siguientes en `G:\bussines\datekeys`. La primera comprueba `npm run verify` y `npm run testdata:check` en `datekeys-ts`.
3. Borrar `G:\bussines\datekeys\enquiry.php`, que es una copia idéntica de `web/static/api/enquiry.php`. Claude no tiene permiso para borrarlo.
4. `docs` y `web` solo existen en esta máquina. Para tener una copia fuera de ella, hay que darles un remoto.
---
## 1. Repositorios
Los dos repos están en el Gitea privado `g.activething.com` (solo LAN, certificado autofirmado para `git.activething.com`; git funciona, `curl` necesita `-k`). **Ese servidor no es del autor**: no se proponen cambios en él. La integración continua es el gate local.
Los repos con remoto están en el Gitea privado `g.activething.com` (solo LAN, certificado autofirmado para `git.activething.com`; git funciona, `curl` necesita `-k`). **Ese servidor no es del autor**: no se proponen cambios en él. La integración continua es el gate local.
| Repo | Rama | Commit | Estado |
|---|---|---|---|
| `datekeys-go` (`go/DateKeys`) | `main` | `3e4755e` | Spec v0.8.2 cerrada, con el tag anotado **`spec-v0.8.2`** en `9ac9cd9`. Después, `datekeys.SpecVersion`, `datekeys.Version()` y `datekeys version`, sin cambios en `testdata`. |
| | `v0.8.2` | `9ac9cd9` | El commit del tag; ya no hace falta. |
| `App` (`go/DateKeys-App`) | `main` | `48d6704` | Versión `0.1.0-dev`, que implementa el spec 0.8.2 (`VERSION` y `SPEC_VERSION`, también en el pie de la página). Librería TypeScript con la inspección (pasos 1 a 8) y la apertura (pasos 9 a 18), en memoria o desde un `Blob` hacia un stream de salida, como un fichero OPFS. Página `/inspect` con la acción "abrir". `testdata` sincronizado a `9ac9cd9`. Fase 2 completa (pasos 2 a 8), incluidos el cifrado tlock y la interoperabilidad de TypeScript a Go. Los 65 casos del corpus pasan por `open` con el código y el paso de Go. 2 611 tests, ninguno saltado; `npm run verify` en verde. |
| `AppOld` (solo local) | `master` | `4d2b0a1` | Prototipo antiguo. No se toca. |
| | `v0.9` | `1189f2f` | Borrador del spec v0.9, sin aprobar (§2.5). |
| `datekeys-ts`, antes `App` (`go/DateKeys-App`) | `main` | `5ee8813` | Desde `5ee8813`, sin `docs/` y con el paquete `datekeys-ts` (§0). Versión `0.1.0-dev`, que implementa el spec 0.8.2 (`VERSION` y `SPEC_VERSION`, también en el pie de la página). Librería TypeScript con la inspección (pasos 1 a 8) y la apertura (pasos 9 a 18), en memoria o desde un `Blob` hacia un stream de salida, como un fichero OPFS. Página `/inspect` con la acción "abrir". `testdata` sincronizado a `9ac9cd9`. Fase 2 completa (pasos 2 a 8), incluidos el cifrado tlock y la interoperabilidad de TypeScript a Go. Los 65 casos del corpus pasan por `open` con el código y el paso de Go. 2 611 tests, ninguno saltado; `npm run verify` en verde. |
| `docs` (solo local) | `main` | | Este repo: handoff, planes, revisiones y reglas. |
| `archive/prototype`, antes `AppOld` (solo local) | `master` | `4d2b0a1` | Prototipo antiguo. No se toca. |
Verificación ya hecha sobre `datekeys-go`:
- fuzzing de 30 min en cada uno de los 15 objetivos sobre `3820066`, limpio;
@ -39,10 +64,7 @@ Verificación ya hecha sobre `datekeys-go`:
- `main` avanzó por fast-forward hasta `9ac9cd9` y lleva el tag `spec-v0.8.2`. Los dos están subidos.
- `App` sincronizó `testdata` con `9ac9cd9` en `71ab8fb`. Solo cambia `testdata/README.md`.
Siguen valiendo estas reglas:
- `App/testdata` solo se actualiza desde `datekeys-go`, con `scripts/sync-testdata.mjs`, y nunca se generan fixtures en `App`. Una guarda falla si aparece un fichero de `testdata` que ningún test ejecuta.
- Si cambia un texto de error de Go en los pasos 1 a 8, el TypeScript lo sigue. Hoy coinciden byte a byte.
- Un cambio normativo posterior ya no modifica la v0.8.2: abre una versión nueva, con su caso en §76.
Las reglas que siguen valiendo (testdata, textos de error y versiones cerradas del spec) están en el [README](README.md#reglas).
### 2.2 Fase 2: abrir cápsulas en el navegador
@ -68,8 +90,14 @@ El vector de GT (`vectors/tlock_ibe.json`) ya está cubierto en `App`. El paso 9
**Estado al parar:**
- `datekeys-go`, rama `v0.9` (`1189f2f`, subida): borrador del spec v0.9, sin aprobar, en `spec/DateKeys_Protocol_Specification_v0.9.md`, con `spec/datekeys.cddl` actualizado. `main` no cambia.
- El repaso final encontró 21 problemas, con su arreglo propuesto (salida del workflow `spec-v0.9-draft`, fichero `scratchpad/v09/review.md` de la sesión, que puede haber desaparecido). Se estaban aplicando cuando se paró el trabajo: **pueden estar a medias**. Lo primero mañana es comprobarlos uno a uno contra el borrador y terminarlos. También falta la entrada v0.9 en `spec/README.md` y ejecutar `go test ./...`, por si algún test lee el CDDL.
- `App`: `docs/PLAN_fase3_escritura.md` (plan del writer TypeScript) y `docs/REVISION_completitud_protocolo.md` (revisión del protocolo). El plan describe aún el writer de la v0.8.2 y hay que replantearlo sobre la v0.9.
- El repaso final encontró 22 problemas, no 21, cada uno con su arreglo propuesto. Están en [spec_v0.9/review.md](spec_v0.9/review.md), la salida del workflow `spec-v0.9-draft`.
- **Comprobado el 29-09 a mediodía: no hay ninguno aplicado.** El borrador no cambió después de la revisión: los números de línea coinciden, y los 15 problemas que se revisaron uno a uno conservan el texto original.
- Hay que aplicarlos todos y verificarlos. Tres puntos:
- el 2.º, el MUST NOT de §56 frente a los lectores que escriben en streaming, necesita una decisión del autor: suavizarlo, o mantenerlo entre las reglas que tiene que confirmar;
- el 10.º, sobre §70, da por respondida la pregunta abierta 4;
- el 4.º es la entrada v0.9 de `spec/README.md`.
- Después hay que ejecutar `go test ./...`, por si algún test lee el CDDL.
- En este repo están [PLAN_fase3_escritura.md](PLAN_fase3_escritura.md), el plan del writer TypeScript, y [REVISION_completitud_protocolo.md](REVISION_completitud_protocolo.md), la revisión del protocolo. El plan describe aún el writer de la v0.8.2 y hay que replantearlo sobre la v0.9.
**Decisiones del autor del 29-09 para la v0.9:**
- D1: `time_and_key` lleva siempre exactamente 16 stanzas X25519 en `INNER_ACCESS_AGE`. Los que sobran son señuelos, y todos van en orden aleatorio. Como mucho hay 16 credenciales, contando la `.dkk`.
@ -97,23 +125,23 @@ El vector de GT (`vectors/tlock_ibe.json`) ya está cubierto en `App`. El paso 9
Hay además reglas añadidas fuera de D1-D7 que confirmar: L_MAX = 2⁵³ − 2⁴⁶, el orden uniforme de los stanzas, y el MUST NOT de §56 sobre entregar el contenido antes de que termine el paso 17.
**Orden de trabajo:**
1. Terminar y verificar las 21 correcciones.
1. Aplicar y verificar las 22 correcciones.
2. El autor aprueba el texto de la v0.9.
3. La referencia Go implementa el formato 2, con fixtures nuevos y mutaciones, y pasa `check.sh`.
4. Se pone el tag `spec-v0.9`.
5. `App` sincroniza `testdata` y el lector TypeScript abre el formato 2.
5. `datekeys-ts` sincroniza `testdata` y el lector TypeScript abre el formato 2.
6. Se replantea el plan de la fase 3 y se escribe el writer TypeScript del formato 2.
**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…`.
- `App` sigue en `0.1.0-dev`; decidir si se cierra `0.1.0`.
- `datekeys-ts` sigue en `0.1.0-dev`; decidir si se cierra `0.1.0`.
### 2.3 Depende del autor
- Crear `security@datekeys.com` y, si se quiere, un `security.txt` en la web. Después, actualizar `SECURITY.md`, que hoy dice `info@activething.com`.
- Elegir la ruta pública del módulo Go (propuesta: `datekeys.com/go/datekeys`, en minúsculas) y el espejo público, que no puede ser GitHub (por ejemplo Codeberg). Publicar la página `go-import` en `datekeys.com`. Después: renombrar el módulo y poner el tag `v0.1.0` cuando `go get` funcione desde una máquina limpia.
- Decidir si `App` pasa de `0.1.0-dev` a `0.1.0`, ahora que la fase 2 está completa.
- Decidir si `datekeys-ts` pasa de `0.1.0-dev` a `0.1.0`, ahora que la fase 2 está completa.
### 2.4 Más adelante
@ -123,19 +151,15 @@ Fase 3 (writer TypeScript de cápsulas), Release API sobre la librería, traducc
## 3. Reglas del proyecto
- **Dependencias:** en ejecución, solo `age`, `drand`, `tlock` y lo que ellas arrastran. El tooling de desarrollo sale de la lista del README. Nada nuevo sin aprobación escrita. Nunca GitHub como servicio.
- **Spec:** en español, estilo RFC 2119. Todo cambio normativo se registra en §76 con su caso reproducible, y se actualiza el SHA-256 de `spec/README.md`.
- **Código y comentarios:** en inglés. Commits con `Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>`.
- **Precedencia de errores (§69.1):** trama; tipo y versión; perfil CBOR y CDDL; campos con código propio, en orden de clave. Entre objetos decide el orden de pasos de §63.
- **Subagentes:** con `model: "opus"`.
Están en el [README](README.md#reglas) de este repo, que el `CLAUDE.md` de la raíz carga en cada sesión.
---
## 4. Documentos
- Planes en `App/docs`: `PLAN_libreria_go.md`, `PLAN_codec_cbor_y_pagina_svelte.md` (v2) y `PLAN_fase2_ibe_noble2.md` (v2).
- 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.8.2.md`, `spec/datekeys.cddl` y `spec/README.md`;
- `spec/DateKeys_Protocol_Specification_v0.8.2.md`, el borrador `spec/DateKeys_Protocol_Specification_v0.9.md` (rama `v0.9`), `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 esta sesión (el diferencial Go/TypeScript de `tsreview/` y las copias congeladas `dkgo-ref-<commit>`) están en el scratchpad temporal y pueden haber desaparecido. Su descripción está en los mensajes de los commits de `App` y en el README de `App`.
- 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.
