DateKeys: documentación del proyecto

Estado, planes, revisiones y reglas de trabajo del proyecto. Es un repositorio privado y no se publica: lo público vive en cada repo de código.

Para retomar el trabajo, lee HANDOFF.md: el estado de cada repo, lo que queda en orden y las decisiones del autor.

Espacio de trabajo

G:\bussines\datekeys es la carpeta de trabajo, no un repositorio. Cada repo es independiente y lleva sus propios commits; no hay repo padre. Las sesiones de Claude se abren en esta carpeta, que es la que tiene la memoria del proyecto y el CLAUDE.md.

Carpeta	Qué es	Remoto
datekeys-go/	Especificación del protocolo (spec/), CDDL, testdata compartido e implementación de referencia en Go: librería y CLI	go/DateKeys
datekeys-ts/	Implementación en TypeScript y páginas /inspect y /create; la carpeta sigue llamándose App. Versión 0.4.0 (tag v0.4.0), de la especificación 0.15; en desarrollo, la 0.5.0, con las palabras al azar	go/DateKeys-App
datekeys-dart/	Librería Dart para la app Flutter, según PLAN_dart.md. Rama v0.15: todas las etapas hechas, de la 0 a la 7, las palabras al azar y los dados, con testdata/ y wordlists/ en 92e7154 de datekeys-go, cuyo testdata es el del tag spec-v0.15. La app Flutter está archivada desde el 6-10	go/dateKeys-dart, desde el 6-10
web/	Landing de datekeys.com, con api/enquiry.php	ninguno
docs/	Este repositorio	go/datekeys-doc, desde el 6-10
brand/	Logos	no es un repo
archive/prototype/	Prototipo anterior (API Quicknet en Go, CLI tlock y cliente Svelte), commit 4d2b0a1. No se toca	ninguno
archive/spec-drafts/	Borradores v0.1 a v0.8.1 de la especificación, anteriores a su entrada en git	no es un repo

• Los remotos están en el Gitea privado g.activething.com. Sus nombres no coinciden con los de las carpetas y no se cambian. El servidor no es del autor: no se propone ningún cambio en él.
• La integración continua es el gate local de cada repo: scripts/check.sh en datekeys-go, npm run verify en datekeys-ts y tool/check.sh en datekeys-dart.
• La especificación está en datekeys-go porque cada cambio normativo va en el mismo commit que su caso reproducible en Go y sus fixtures. Pasará a un repo propio al publicarla (traducción, revisión externa, espejo público).
• La aplicación de producto, cuando exista, tendrá su propia carpeta.

Reglas

• Dependencias: en ejecución, solo age, drand, tlock y lo que ellas arrastran. El tooling de desarrollo sale de la lista del README de cada repo. Nada nuevo sin aprobación escrita. Al pedirla, decir si es un paquete nuevo o uno que ya va en el bundle, y ofrecer la alternativa de código propio. 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. Una versión cerrada con tag no cambia: el cambio siguiente abre una versión nueva.
• Idioma: la spec y los documentos de este repo, en español. Código, comentarios y mensajes de commit, en inglés.
• Commits con Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>.
• Testdata: datekeys-ts/testdata solo se actualiza desde datekeys-go, con scripts/sync-testdata.mjs, y datekeys-dart/testdata con tool/sync_testdata.dart. En ninguno de los dos se generan fixtures. Los dos scripts copian también, del mismo commit, las listas de palabras de wordkey/lists en wordlists/. En datekeys-ts, una guarda falla si aparece un fichero de testdata que ningún test ejecuta.
• Textos de error: si cambia un texto de error de Go en los pasos 1 a 8, el TypeScript lo sigue. Hoy coinciden byte a byte.
• 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 de Claude con model: "opus".

Documentos

Documento	Contenido
HANDOFF.md	Estado actual y trabajo pendiente
HANDOFF_historial.md	Lo que fue el handoff hasta el 6-10, sesión a sesión: por qué se decidió cada cosa y en qué commit quedó
PLAN_libreria_go.md	Plan de la librería Go, hitos M0 a M5 (hecho)
PLAN_codec_cbor_y_pagina_svelte.md	v2: codec CBOR propio en Go y TypeScript, librería TypeScript y página /inspect (hecho)
PLAN_fase2_ibe_noble2.md	v2: fase 2, abrir cápsulas en el navegador (hecho)
PLAN_fase3_escritura.md	Fase 3, writer TypeScript del formato 2 (v0.9). v3, hecha: la librería, su interoperabilidad con Go y la página /create (hasta 3a9d2b1 de datekeys-ts)
REVISION_completitud_protocolo.md	Qué le falta al protocolo antes de la v1.0
REVISION_completitud_v0.13.md	La misma revisión contra la v0.13 (6-10): qué está hecho, los huecos nuevos y los tres pasos siguientes antes de la v1.0
spec_v0.14/	El borrador v0.14: las decisiones para el autor, con su recomendación
revision_externa/	El paquete para una revisión criptográfica externa, en inglés, con una nota para el autor
diseno_recuperacion.md	Diseño de la recuperación a largo plazo: el objeto de release, el reloj del paso 9.c, el archivo de releases y el anexo de recuperación, con las decisiones para el autor. Su fichero .dkr se descartó al aprobar la v0.15
spec_v0.15/	La v0.15, aprobada el 7-10, la recuperación a largo plazo: las decisiones del autor, sin el fichero .dkr, que se descartó
spec_v0.9/	Papeles de trabajo del borrador v0.9: diseño, revisiones y correcciones pendientes
spec_v0.10/	Formato de cápsula 3 en diseño, en tres entregas: varios ficheros, firma de autor y sello de tiempo. El diseño, con sus revisiones incorporadas, la revisión de Fable y la revisión final del borrador del spec
spec_v0.11/	Papeles de trabajo de la v0.11, ya etiquetada. Contiene: la llave de palabras; la consulta a Fable y Astra sobre el tamaño del área de firmas y sellos y su propuesta; la revisión del borrador; la revisión de lo hecho en la sesión del 1 y 2 de octubre, con los fallos pendientes de arreglar
wordlists/	El script del borrador de la lista española de palabras al azar de la llave de palabras (7-10)
ideas/	Ideas de producto fuera de la cápsula del tiempo: el interruptor de liberación condicional con Sapphire y el almacén cifrado de la app móvil, con PIN de coacción