@ -21,13 +21,16 @@ Las revisiones de las dos etapas están en [PLAN_dart.md](PLAN_dart.md), al fina
- G: tiene 26 GB libres desde el 5-10, porque el autor liberó unos 24 GB.
- G: tiene 26 GB libres desde el 5-10, porque el autor liberó unos 24 GB.
**Siguiente:**
**Siguiente:**
1. **Dart, etapa 4**, que el autor aprobó el 5-10 y ya está en marcha. Se reparte en las partes 4a, 4b y 4c, descritas en [PLAN_dart.md](PLAN_dart.md), al final. La salida `-dart` del generador de tablas ya está hecha: `c531e93` en `datekeys-go`, subido, y `1e7753d` en `datekeys-dart`.
1. **Dart, etapa 5**, pedida por el autor el 5-10 («sigue con la etapa 5»). Está en marcha.
La 4a y la 4b ya están hechas, revisadas e integradas en `v0.11`, en `d8c790d`. La 4c corre en la copia principal. Si la sesión se cierra a medias:
La etapa 4 está completa: 4a, 4b y 4c hechas, revisadas e integradas en `v0.11`, hasta `8e0e993`. La salida `-dart` del generador de tablas está en `c531e93` de `datekeys-go`, subido.
1. mira qué commits hay después de `d8c790d`;
La etapa 5 se reparte en 5a, 5b y 5c, descritas en [PLAN_dart.md](PLAN_dart.md), al final. La 5a trabaja en el worktree `datekeys-dart-stage5a`, rama `stage5a`, y la 5b en la copia principal. Si la sesión se cierra a medias:
1. mira qué commits hay en `v0.11` después de `8e0e993` y en `stage5a`;
2. revísalos;
2. revísalos;
3. pasa el gate;
3. integra `stage5a` encima de `v0.11` y pasa el gate;
4. si quedó a medias, relanza la 4c con el esquema de [PLAN_dart.md](PLAN_dart.md).
4. borra el worktree;
5. lanza la 5c.
2. Lo que sigue abierto de la lista de abajo:
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;
- la aprobación del borrador v0.12 y la medida del área de 32 KiB, que el autor dejó para luego;
- **4b:** el relleno, las tramas y la resolución de rondas y tiempos, comparados con Go, porque son la parte aritmética, la delicada en la web. El resto lo cubre un diferencial contra Go de unos 6 400 casos, con el resultado, el código y el texto, y cada par de fallos de capas distintas del §69.1.
- **4b:** el relleno, las tramas y la resolución de rondas y tiempos, comparados con Go, porque son la parte aritmética, la delicada en la web. El resto lo cubre un diferencial contra Go de unos 6 400 casos, con el resultado, el código y el texto, y cada par de fallos de capas distintas del §69.1.
- **Ninguna de las dos tiene fallos.** Lo único distinto entre Go en `c531e93` y el tag `spec-v0.11` es la regla de los codificadores del §72, que el tag no tiene.
- **Ninguna de las dos tiene fallos.** Lo único distinto entre Go en `c531e93` y el tag `spec-v0.11` es la regla de los codificadores del §72, que el tag no tiene.
**La 4c corre desde el 5-10** en la copia principal, sobre `d8c790d`.
**La 4c, hecha y revisada el 5-10:** `e18045e` a `8e0e993`. Con ella la etapa 4 queda completa. El gate pasa con 1 320 pruebas en la VM y 291 en Node.
Qué hace:
- el head, la nota pública, la inspección de los pasos 1 a 8 y la apertura de los pasos 9 a 18 de los formatos 1 a 3;
- abre cápsulas grandes en streaming, desde una fuente de acceso aleatorio, y la memoria no crece con el tamaño;
- deja preparado el enganche de los veredictos para la etapa 5.
Resultados:
- las 210 mutaciones del corpus dan el código, el paso y el texto de Go;
- 5 110 inspecciones mutadas no dan ninguna diferencia con Go;
- los 24 fixtures abren con cada credencial;
- las pruebas detectaron los 15 fallos inyectados.
La revisión de la sesión comparó con Go `open3.go` y el paso 17 de los formatos 1 y 2: el orden de los subpasos, el SHA-256 de cada fichero, el relleno, la salida que se cierra solo cuando pasa el paso 17 y que se aborta ante cualquier fallo, y el enganche de `Accept`. No encontró fallos.
Notas:
- **Un fallo de dart2js en Dart 3.13,** ajeno a la librería. Un objeto que llega al campo de otro a través de `c ? null : objeto` puede perder las escrituras que recibe ahí. Está documentado en el README. Reportarlo al equipo de Dart sería publicar fuera: solo con permiso del autor.
- `Opened.payloadLength` solo se rellena cuando la apertura sale bien.
- Las identidades se pasan como claves X25519 en bruto, como en TypeScript.
**La etapa 5, en marcha desde el 5-10**, cuando el autor dijo «sigue con la etapa 5». Se reparte como la 4:
- **5a, en paralelo con la 5b:** el lector CMS con el perfil de certificado de la v0.12, ECDSA y RSA propios en `BigInt` y los sellos RFC 3161, port de `internal/cms`. Trabaja en el worktree `G:\bussines\datekeys\datekeys-dart-stage5a`, rama `stage5a`, desde `8e0e993`.
- **5b, en paralelo con la 5a,** en la copia principal:
1. sincroniza `testdata` con `datekeys-go` en `c531e93`, la cabeza de `v0.12`, cuyo `testdata` es idéntico al de `601e6d2`, el de TypeScript. `specVersion` sigue en 0.11, y la sincronización trae 26 fixtures y 218 mutaciones. Después regenera los vectores;
2. hace los compromisos, `SECURITY_CBOR`, la firma `alg` 1 y los veredictos con sus textos y líneas, conectados a la apertura.
- **5c, después de integrar las dos:**`securitycms`, es decir, `alg` 2 y `seal_type` 2 en los veredictos, con los 135 casos de `security_cms.json`.
