Handoff for the next session: where every repo is, and stage 2 of Dart to relaunch

The session of 5 October closes with its context nearly full. The handoff
says how to start the next one (in the root, on Opus), the commit of each
repo, and that stage 2 of Dart was stopped before its agent wrote anything:
PLAN_dart.md keeps the brief to launch it again, and stage 3 follows, as
the author asked.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
main
dev 2 days ago
parent affdd8d01a
commit a60da38954

@ -8,6 +8,16 @@ Sirve para retomar sin contexto previo, sea una persona o una sesión de Claude.
## Retomar aquí (al cerrar la sesión del 5 de octubre)
**Para empezar la sesión siguiente.** La del 5-10 se cerró porque tenía el contexto casi lleno.
1. Abre la sesión en `G:\bussines\datekeys`, la raíz, no en `App`, y comprueba que corre en Opus.
2. Comprueba que los repos están como dice este apartado (`git status` y `git log` en cada uno). Todos estaban limpios al cerrar:
- `datekeys-go`: rama `v0.12` en `424cdf3`, subida;
- `App`: rama `v0.10` en `289fe71`, subida;
- `datekeys-dart`: rama `v0.11` en `c8bf3c0`, solo en local;
- `docs`: en el commit de este handoff, solo en local.
3. **Dart, etapa 2.** Se encargó a un agente y se detuvo antes de que escribiera nada en el repo. Hay que relanzarla con el encargo de [PLAN_dart.md](PLAN_dart.md), apartado «Cómo se hacen las etapas», revisar su resultado y pasar `tool/check.sh`.
4. **Dart, etapa 3**, BLS12-381 y tlock: el autor la pidió el 5-10 para después de la 2.
**Qué pasó.** Una sesión en Opus, abierta otra vez en `App`, hizo los puntos 2, 3 y 4 de la lista del 2-10: lo que faltaba de Go, la segunda parte del TypeScript y las etapas 0 y 1 de Dart. El autor decidió además una ampliación del borrador v0.12. El trabajo grande se repartió entre agentes Opus en worktrees y repos aparte, y cada resultado se revisó e integró en la sesión.
**`datekeys-go`, rama `v0.12`, subida:**
@ -64,8 +74,9 @@ Sirve para retomar sin contexto previo, sea una persona o una sesión de Claude.
Decidido el 5-10 («sí a las dos»):
- **«Con texto» en el §29.7:** el titular toma `givenName` y `surname` solo si los dos tienen texto no vacío, y el emisor toma el `organizationName` si no tiene un `commonName` con texto. Es lo que ya hacían Go y el TypeScript. Está en `424cdf3`, subido.
- **`dart test -p node` en el gate de Dart:** `c8bf3c0`.
2. **Dart, etapa 2:** las primitivas y `age`, según [PLAN_dart.md](PLAN_dart.md). En curso el 5-10, con un agente.
3. **TypeScript, sin urgencia:** el localizador, que aún no está portado; que la página muestre la nota pública, que ya lee `inspect`; y lo pendiente del §2.5.
2. **Dart, etapa 2:** las primitivas y `age`, según [PLAN_dart.md](PLAN_dart.md). Se encargó el 5-10 y se detuvo sin escribir nada al cerrar la sesión: hay que relanzarla.
3. **Dart, etapa 3:** BLS12-381 y tlock, pedida por el autor para después de la 2.
4. **TypeScript, sin urgencia:** el localizador, que aún no está portado; que la página muestre la nota pública, que ya lee `inspect`; y lo pendiente del §2.5.
**Observaciones del 5-10, sin decisión:**
- El error de una nota pública con un tabulador dice «in the declared author», porque la nota usa las reglas del autor declarado. Está en `note.json` y el TypeScript lo copia: cambiarlo exige tocar los dos lados.

@ -78,3 +78,36 @@ datekeys-dart/
La app Flutter lo usa con `datekeys: { path: ../datekeys-dart }`, o con una dependencia de git cuando haya remoto.
**Ramas.** La librería sigue la versión del spec que implementa: empieza en `v0.11` y pasa a `v0.12` cuando `datekeys-go` cierre esa versión.
## Cómo se hacen las etapas
Las etapas 1 y 2 se encargaron a un agente Opus, que trabaja en el propio `datekeys-dart`. La sesión revisa después su trabajo y pasa el gate. La etapa 1 salió bien así. El encargo de la etapa 2 se interrumpió el 5-10, antes de que el agente escribiera nada, porque la sesión cerraba. Hay que relanzarlo con esto:
- **Alcance:**
- HMAC-SHA256 propio, con una compresión SHA-256 propia y los estados interior y exterior calculados una vez, para el PBKDF2 de 600 000 iteraciones;
- HKDF-SHA256, scrypt con Salsa20/8, ChaCha20-Poly1305 con comparación del tag en tiempo constante, X25519 con clamping y secreto todo a ceros rechazado, y Ed25519 estricto (port de `internal/ed25519strict`);
- lectura de `age` v1 portada de `filippo.io/age` v1.3.2: la cabecera y sus límites, el MAC, los stanzas X25519 y scrypt (con factor de trabajo acotado, como `authorkey` de Go), la clave del payload y el STREAM de `internal/stream`, con los mismos casos de fin de fichero que Go, y las reglas de `agewrap` y del §28.1;
- las identidades `AGE-SECRET-KEY-1…` en Bech32;
- errores con la finura suficiente para reproducir en la etapa 4 los textos de Go (ver `agefile.ts` y `mutation-texts.json` en `datekeys-ts`).
- **Exactitud:**
- los enteros siguen la regla de la etapa 1: exactos en la VM y en la web;
- en Poly1305, los productos y las sumas de los limbs quedan por debajo de 2^53;
- la aritmética de 32 bits es correcta también compilada a JavaScript.
- **Vectores:**
- los de las RFC 7748, 8439, 5869, 7914 y 8032 y los de PBKDF2, producidos con las librerías de Go de la caché de módulos, nunca escritos de memoria. El generador va en `tool/` con `//go:build ignore`, y su salida en `test/vectors/`;
- ficheros `age` de `filippo.io/age`, con recipients X25519 y scrypt, cortes y manipulaciones;
- `ed25519_strict.json`;
- el PAYLOAD_AGE de cada fixture, con su `payload_identity`, y el INNER_ACCESS_AGE de los `time_and_key`.
- **Pruebas:**
- las que leen ficheros, con `@TestOn('vm')`;
- pruebas de las primitivas que también corran en Node, con parámetros pequeños;
- al final, fallos inyectados de uno en uno para comprobar que las pruebas los detectan.
- **Informe:** los tiempos en la VM y en Node de X25519, Ed25519, ChaCha20-Poly1305 por MiB, PBKDF2 a 600 000 iteraciones y scrypt con logN 16; y los commits.
- **Reglas:**
- sin dependencias nuevas;
- código, comentarios y commits en inglés, y README y CHANGELOG en español;
- `tool/check.sh` antes de cada commit;
- decir en el código y en el README que `BigInt` no es de tiempo constante;
- no tocar `testdata/`, `datekeys-go` ni `datekeys-ts`.
La etapa 3, BLS12-381 y tlock, va después y con el mismo esquema. Las referencias son `bls12381.ts`, `ibe.ts`, `tlock.ts` y `release.ts` de `datekeys-ts`, y kyber y tlock de Go, con sus vectores `tlock_ibe.json`, `ibe-vectors.json` y `tlock-vectors.json`.

Loading…
Cancel
Save

Powered by TurnKey Linux.