go
/
datekeys-doc
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '4564e56a0b'
${ noResults }
datekeys-doc/HANDOFF.md

9.2 KiB
Raw Blame History

Handoff DateKeys

Estado al 6 de octubre de 2026 por la noche. Lo que pasó hasta aquí, sesión a sesión, está en HANDOFF_historial.md.

Sirve para retomar sin contexto previo, sea una persona o una sesión de Claude.

Antes de empezar:

  • La sesión se abre en G:\bussines\datekeys, la raíz, que es la que tiene la memoria y el CLAUDE.md.
  • Comprueba que corre en Opus. Una sesión del 1-10 corrió por descuido con Sonnet 5.5 y hubo que revisarla entera. Los trailers Co-Authored-By de los commits dicen qué modelo escribió cada uno.
  • Comprueba cada repo con git status y git log: todo lo de abajo estaba subido al cerrar.

Estado

Repo Rama y commit Tags Qué es
datekeys-go v0.14 en 22f184c; main en 39b2033 spec-v0.14 en 39b2033, y los de las versiones anteriores Spec v0.14 aprobada, implementación de referencia, testdata compartido
App (datekeys-ts) v0.10 y main en 3abd7bf v0.3.0 en 3abd7bf, v0.2.0, v0.1.0 Librería TypeScript 0.3.0, de la spec 0.14, y páginas /inspect y /create
datekeys-dart v0.14 en 013b069 ninguno Librería Dart completa, de la spec 0.14; las ramas v0.11 a v0.13 se quedan atrás
docs main — Este repo
web main en f2b8a38 — Landing de datekeys.com, sin remoto
  • Spec: la v0.14 está aprobada desde el 6-10, con SHA-256 390922135931dd61a263ed90259c7a978b5d92944405e641e94cc194f84fb459. No hay ningún borrador abierto. Las versiones aprobadas y sus SHA-256 están en datekeys-go/spec/README.md.
  • Las tres implementaciones coinciden en todos los vectores compartidos de datekeys-go/testdata en 39b2033, 136 ficheros. Gates el 6-10:
    • Go: scripts/check.sh entero, y scripts/fuzz.sh 20s en 39b2033 con sus 26 objetivos;
    • TypeScript: npm run verify en 3abd7bf, con 8 030 pruebas;
    • Dart: tool/check.sh en 013b069, con 2 193 pruebas en la VM y 681 en Node.
  • La revisión externa: el paquete está listo en revision_externa/, con commits congelados (39b2033, 22f184c para la documentación de Go, 3abd7bf y 013b069). Su nota dice qué decidió el autor y qué falta: elegir revisor, alcance y presupuesto, el NDA, los bundles y el envío.

Qué queda

En el orden que recomendó la sesión del 6-10 y aceptó el autor: este HANDOFF, después la recuperación a largo plazo y después las recomendaciones de la v0.14 en los clientes.

Protocolo

  1. La revisión externa. El paquete está listo; lo que falta es del autor. Al recibir el informe, se abre la versión siguiente con sus hallazgos, el párrafo de idioma y precedencia del final del §1, las etiquetas del §76 que hoy llaman independientes a revisiones de IA, y el registro de la revisión (§75, punto 10). Todo eso lo aprobó el autor el 6-10; ver revision_externa/precedence_and_language.md.
  2. La recuperación a largo plazo. Es lo más grave que queda abierto: una cápsula a veinte años depende de que alguien conserve el release de su ronda. El §74 lo deja como trabajo futuro: un objeto de release, su fuente de archivo y el uso del reloj local en el paso 9.c. Hace falta un diseño para que el autor decida.
  3. Medir el área de 32 KiB y cerrar el perfil CMS (§74; §75, punto 13), con firmas reales con certificado de varios países y sellos de autoridades reales. Necesita firmas del autor o permiso para pedir sellos a una autoridad pública.
  4. Lo que el §74 aún llama provisional: los esquemas de bytes de la cabecera, el control y la .dkk, los límites de los campos y los vectores definitivos del perfil. Conviene congelarlo con el informe de la revisión delante.
  5. El registro de perfiles firmado (§71), que no existe.
  6. Más adelante: un tipo de acceso post-cuántico, y quizá una derivación más dura que PBKDF2 para la llave de palabras.

Librerías y clientes

  • Las recomendaciones de la v0.14 al SDK oficial, que no aplican ni /create ni la CLI de Go:
    • recomendar time_and_key para horizontes largos (§7.6);
    • ofrecer por defecto palabras al azar (§38.1). El autor tiene que elegir la lista: cuál, en qué idioma y con qué licencia;
    • avisar del estado de un perfil (§71).
  • La página web, cuando se publique (§59): builds reproducibles con sus hashes, Subresource Integrity y un cliente sin conexión.
  • El localizador en las páginas: las tres librerías lo tienen, pero /create no crea sobres e /inspect no descarga el resto.
  • Go no tiene ninguna release del módulo; la primera, cuando haya un repo accesible desde fuera para go get. govulncheck avisa de GO-2026-6443 en grpc, que el código no alcanza: subir grpc cuando salga la 1.85.0.
  • Dart: sin versión ni tag. Medir los tiempos en un móvil espera a la app.

Espacio de trabajo

  • Del autor: renombrar la carpeta App a datekeys-ts y borrar enquiry.php de la raíz, pendientes desde el 29-09.
  • web sigue sin remoto.

Decisiones del autor que siguen vigentes

  • La app Flutter está archivada «para un futuro» (6-10). No se empieza sin que lo pida.
  • La revisión externa (6-10):
    • primero, buscar un revisor que lea español; si no lo hay, traducir solo el núcleo normativo;
    • dos niveles de alcance, con presupuesto cerrado por nivel;
    • código entero en bundles de git cifrados con age;
    • un NDA mutuo;
    • la v0.15, después del informe.
  • locator.Open sigue leyendo como mucho 1 MiB del localizador (6-10).
  • El cifrado tlock queda en BigInt, sin tiempo constante, documentado en Dart y TypeScript («continúa», 6-10).
  • El reporte del posible fallo de dart2js al equipo de Dart, solo con permiso del autor. Está documentado en el README de datekeys-dart.
  • Mostrar Q1 y Q10 de la revisión al equipo de drand antes de pagar una revisión es decisión del autor, porque supone enseñar el proyecto fuera.
  • El diseño de las páginas: nunca un fondo oscuro, nada del estilo de la landing, usar la skill frontend-design sobre la página real y no gastar en maquetas. Ver la memoria.

Para trabajar

  • Subir al Gitea. El nombre g.activething.com a veces resuelve a 89.46.247.16, que no responde. Entonces se sube a la IP de la red local, sin tocar el remoto:

    git -C <repo> push https://192.168.18.112/go/<repo-remoto>.git <rama>

    y después git -C <repo> update-ref refs/remotes/origin/<rama> <rama>. Los remotos son go/DateKeys, go/DateKeys-App, go/dateKeys-dart y go/datekeys-doc. El servidor no es del autor: no se propone ningún cambio en él.

  • Cerrar una versión del spec, como la v0.12, la v0.13 y la v0.14:

    1. en Go, la cabecera del spec con «aprobado por su autor ese día» y nada más del texto;
    2. SpecVersion;
    3. go run ./internal/testkit/genfixtures -out testdata, y el campo spec a mano en los dos congelados, security_cms.json y locator.json;
    4. el SHA-256 en spec/README.md, y los README, SECURITY.md, la trazabilidad, testdata/README.md y el CHANGELOG;
    5. scripts/check.sh, con el árbol limpio tras el commit;
    6. el tag anotado spec-vX.Y y main avanzado sin fusión (git fetch . <rama>:main);
    7. en TypeScript y Dart, la versión del spec, testdata sincronizado con sus scripts, mutation-texts.json regenerado con Go en un módulo temporal (G:\tmp\mutgo), y el campo spec de los vectores propios que salen de Go.

    Tras aprobar no se añade texto normativo sin enseñarlo: fue el fallo E1 de la v0.11.

  • Encargos a agentes:

    • con model: "opus";
    • en worktrees junto a los repos, para que ../datekeys-go resuelva;
    • nunca dos agentes en los mismos ficheros;
    • solo ficheros nuevos, y los comunes en un último commit;
    • la sesión revisa contra Go antes de integrar.

  • Herramientas de esta máquina:

    • los heredocs de Bash rompen las barras invertidas, \n incluido;
    • la herramienta Write quita los espacios de final de línea (los saltos de Markdown del §77) y convierte \uXXXX en caracteres;
    • para cambios con barras o espacios exactos, un script de Python escrito con Write que use chr(92), o la herramienta Edit;
    • cd en Bash mueve el directorio de la sesión: usa ( cd … ) o git -C.

  • Vista previa de la página: la configuración inspector-dev-app de .claude/launch.json arranca App, mientras la carpeta no se renombre. No pares el servidor mientras el autor lo usa. vite.config.ts prepara las dependencias que se cargan bajo demanda (optimizeDeps.include), para que la primera apertura no recargue la página.

  • Fuzzing: usa FUZZ_PARALLEL=4. Un «context deadline exceeded» sin entrada que falle es del motor de Go, no del código; se vuelve a pasar.

  • Disco: C: está casi lleno con las cachés de Go y Dart; los temporales van en G:\tmp, y nunca se borra con comodines.

Documentos

El README los lista. Para retomar, lo principal es:

Powered by TurnKey Linux.