@ -6,22 +6,27 @@ Sirve para retomar sin contexto previo, sea una persona o una sesión de Claude.
---
## En curso: la segunda sesión del 5 de octubre
## La segunda sesión del 5 de octubre: etapas 2 y 3 de Dart
Corre en Opus 5.5. Se abrió en `App` y a los pocos minutos pasó a la raíz con la herramienta de carpetas de la app, sin cerrarse. Siguió la lista de abajo:
Corrió en Opus 5.5. Se abrió en `App` y a los pocos minutos pasó a la raíz con la herramienta de carpetas de la app, sin cerrarse. Hizo los puntos 1 a 4 de la lista de abajo:
- **Repos:** comprobados; estaban como dice la lista.
- **Dart, etapa 2:** hecha y revisada. Son los commits `0c21f55` a `82fa714` de `v0.11`, solo en local, con el gate en verde: 296 pruebas en la VM y 83 en Node. La revisión está en [PLAN_dart.md](PLAN_dart.md), al final.
- **Dart, etapa 3:** el autor pidió adelantarla, y su agente trabaja en paralelo en el worktree `G:\bussines\datekeys\datekeys-dart-stage3`, rama `stage3`, desde `c8bf3c0`.
Si esta sesión se cierra antes de integrarla:
1. Mira qué commits tiene `stage3` y si el worktree está limpio.
2. Revísalos.
3. Pon `stage3` encima de `v0.11` con `rebase` o `cherry-pick`. Los conflictos solo pueden estar en `README.md`, `CHANGELOG.md` y `lib/datekeys.dart`.
4. Pasa `tool/check.sh` y borra el worktree con `git worktree remove`.
Si el trabajo quedó a medias, relanza el agente con el esquema de [PLAN_dart.md](PLAN_dart.md), apartado «Cómo se hacen las etapas».
Desde el 5-10, G: tiene 26 GB libres: el autor liberó unos 24 GB.
- **Dart, etapa 2:** hecha y revisada, commits `0c21f55` a `82fa714`.
- **Dart, etapa 3:** el autor pidió adelantarla, y se hizo en paralelo con la 2, en un worktree aparte. Está revisada e integrada encima de la 2, commits `cdd1c89` a `b81bdfa`. El worktree y su rama ya están borrados.
Las revisiones de las dos etapas están en [PLAN_dart.md](PLAN_dart.md), al final; ninguna encontró fallos.
**Estado al cerrar:**
- `datekeys-dart`: rama `v0.11` en `b81bdfa`, limpia, solo en local. El gate pasa, con 367 pruebas en la VM, más una aplazada, y 113 en Node.
- `datekeys-go` y `App` no se tocaron.
- G: tiene 26 GB libres desde el 5-10, porque el autor liberó unos 24 GB.
**Siguiente:**
1. **Dart, etapa 4:** formatos, inspección y apertura. Antes hace falta una salida `-dart` del generador `internal/pathrule/gen` de `datekeys-go`, para las tablas de Unicode: es un cambio en el repo de Go.
2. Lo que sigue abierto de la lista de abajo:
- la aprobación del borrador v0.12 y la medida del área de 32 KiB, que el autor dejó para luego;
- el TypeScript sin urgencia;
- las observaciones sin decisión.
3. Medir BLS12-381, PBKDF2 y scrypt en un móvil de gama media, cuando haya app.
## Retomar aquí (al cerrar la sesión del 5 de octubre)
@ -11,7 +11,7 @@ Un paquete Dart **puro**: sin Flutter y sin plataforma.
Estado de la máquina: el 5-10, Flutter está instalado en `C:\dev\flutter`, y su Dart 3.13.0 es el `dart` del PATH. La librería no necesita Flutter; la app sí.
**Hecho:** la etapa 0 (`5aa5eed`), la etapa 1 (`da63bc3` a `10b0895`) y la etapa 2 (`0c21f55` a `82fa714`), el 5-10, en la rama `v0.11` de `datekeys-dart`. El estado de cada etapa está en su README.
**Hecho:** la etapa 0 (`5aa5eed`), la etapa 1 (`da63bc3` a `10b0895`), la etapa 2 (`0c21f55` a `82fa714`) y la etapa 3 (`cdd1c89` a `b81bdfa`), el 5-10, en la rama `v0.11` de `datekeys-dart`. El estado de cada etapa está en su README.
## Decidido (2 de octubre)
@ -115,4 +115,33 @@ Las etapas 1 y 2 se encargaron a un agente Opus, que trabaja en el propio `datek
- el texto de «mixed case» del Bech32 usa las mayúsculas y minúsculas de Unicode de Dart, como el TypeScript, y puede diferir del de Go con entradas no ASCII que los tres rechazan;
- `age.json` y `age_fixtures.json` cambian en cada ejecución del generador, porque `age` usa `crypto/rand`: son vectores congelados.
La etapa 3, BLS12-381 y tlock, sigue el mismo esquema. El autor pidió el 5-10 adelantarla, y corre en paralelo con la 2: su agente trabaja en un worktree aparte, `G:\bussines\datekeys\datekeys-dart-stage3`, en la rama `stage3`, que sale de `c8bf3c0`. Solo crea ficheros nuevos, y deja los cambios a los ficheros comunes para un último commit. La sesión la integra después sobre `v0.11` y borra el worktree. 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`.
**La etapa 3, BLS12-381 y tlock,** siguió el mismo esquema. El 5-10 el autor pidió adelantarla, así que corrió en paralelo con la 2. Su agente trabajó en un worktree aparte, en la rama `stage3`, que salía de `c8bf3c0`. Solo creó ficheros nuevos, y dejó los cambios a los ficheros comunes para un último commit.
La sesión revisó la etapa 3 contra Go y contra el TypeScript:
- `verifyRelease`, contra `provider.Verify` de Go;
- `unwrapTlockStanza`, contra `NewTimeIdentity` y su `Unwrap`;
- el IBE, contra `DecryptCCAonG2`, `EncryptCCAonG2`, `h3` (con el desplazamiento del primer byte y el límite de iteraciones), H2 y H4 de kyber;
- la decodificación de puntos, contra `FromCompressed` de kilic: flags, signo y subgrupo;
- `fetchRelease`, contra `sourceFailure` de `capsule`.
No encontró ningún fallo. La aritmética de la curva la cubren los vectores de Go: GT, hash a G1, firmas y el stanza de cada fixture.
Después la integró: `rebase` sobre `v0.11`, con conflictos solo en el README, el CHANGELOG y `lib/datekeys.dart`, y avance de `v0.11` sin fusión. El gate pasó, con 367 pruebas en la VM, más una aplazada, y 113 en Node. La sesión borró luego el worktree y la rama.
Notas:
- **Diferencias con Go, a propósito, las mismas que en el TypeScript:**
- solo se verifica el scheme de Quicknet;
- una firma en el infinito nunca vale, mientras que Go la acepta si la clave también es el infinito, una clave que ningún perfil pinneado tiene.
- **SHA-256:** BLS12-381 y tlock usan el de `package:crypto`, aunque la etapa 2 ya trae uno propio. Las dos opciones están permitidas, y se puede unificar más adelante.
- **Pendiente:**
- medir en un móvil de gama media;
- `Random.secure` no funciona en `dart test -p node`, así que las dos pruebas que sacan un sigma aleatorio corren solo en la VM.
- **Tiempos en la VM:**
- un emparejamiento, 11 ms;
- la verificación de la firma de una ronda, 16 ms;
- el descifrado del stanza, 20 ms;
- los pasos 10 y 11 juntos, 35 ms.
En Node, unas veinte veces más.
**Siguiente, la etapa 4:** formatos, inspección y apertura. Necesita una salida `-dart` del generador `internal/pathrule/gen` de `datekeys-go`, es decir, un cambio en el repo de Go.
