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ágina /inspect	go/DateKeys-App
web/	Landing de datekeys.com, con api/enquiry.php	ninguno
docs/	Este repositorio	ninguno
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 y npm run verify en datekeys-ts.
• 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 en datekeys-ts nunca se generan fixtures. 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
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
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