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`.
**La 5b, hecha y revisada el 5-10:** `95f9c5a` a `a7a7423`, en `v0.11`. El gate pasa con 1 378 pruebas en la VM y 305 en Node, y `testdata` tiene 133 ficheros, en `c531e93`.
Qué hizo:
- **Sincronización:** al pasar `testdata` a la v0.12 no apareció ninguna diferencia con Go, así que la librería no necesitó arreglos. Go regeneró los vectores que leen `testdata`.
- **Firma y sello:**
- `author.dart`, los compromisos;
- `security.dart`, `SECURITY_CBOR` y su evaluación, con la interfaz `CmsEvaluator` para la 5c;
- los textos y las líneas de los veredictos en `verdicts.dart`.
El evaluador real es el de por defecto al abrir. `alg` 2 y `seal_type` 2 quedan «no evaluados» hasta la 5c, sin inventar un veredicto.
- **Pruebas:** 23 de los 24 casos de `security.json` coinciden con Go; el que falta es de la 5c. Un diferencial de 1 730 evaluaciones de Go coincide también, y las pruebas detectaron los 12 fallos inyectados.
La revisión de la sesión comparó con Go los compromisos, byte a byte, y `EvaluateSecurityIn`, `evaluateSignature` y `setSeal`. Coinciden también en que un pánico o un fallo de una parte solo afecta a su propio veredicto. No encontró fallos.
