GT-588: el cable de firma — toda decisión asentada emite un statement verificable

[beyondnetPeru]

La maquinaria de firma ya existía y estaba probada. Lo que no existía era nada que la invocara: AuditService recibía el grabador como parámetro opcional y new AuditService(...) no aparecía fuera de tests. La regla AUD-TRANSP castigaba un ledger que no verifica mientras nadie emitía ninguno.

Esto es ese cable, en el Tracker — donde ya viven las decisiones de compuerta y el expediente, y donde el Core no puede estar porque ADR-0101 lo define sin estado.

Cómo engancha

Un decorador de IAuditEntryRepository, no un cambio en cada llamante. Los caminos que asientan decisiones —evaluación de compuerta, registro de aprobación, publicación de decisión, turno de agente— ya pasan todos por esa interfaz. Enchufar ahí firma los cuatro sin tocar ninguno, y firma también el quinto que alguien añada mañana sin acordarse de esta ficha.

Lo que el decorador no hace: tumbar la operación si la firma falla. Una decisión de gobierno ya tomada no puede perderse porque el volumen del ledger no esté montado — eso convertiría una garantía de auditoría en un punto de caída del producto. La ausencia se nota después y con dientes: AUD-TRANSP-01 pone en rojo un ledger inexistente o vacío.

La parte difícil: interoperabilidad entre dos lenguajes

El Tracker firma en C# y quien verifica es evolith audit verify, escrito en TypeScript. Entre ambos hay cuatro capas donde un solo byte de diferencia lo rompe todo:

Capa	Cómo se hizo coincidir
JSON canónico	Claves ordenadas en toda profundidad, StringComparer.Ordinal para que otro locale no reordene, escapado relajado para igualar a JSON.stringify
CBOR determinista	CborConformanceMode.Canonical, que ordena las entradas de mapa por los bytes de la clave — igual que su codificador
COSE_Sign1	Cabecera protegida con claims CWT iss/sub, vds=1, payload desacoplado en el recibo
Merkle RFC 9162	Prefijos de dominio 0x00/0x01, y la misma k como mayor potencia de dos

Verificación: contra el CLI real, no contra estructuras C#

Los tests generan un ledger y se lo dan al evolith audit verify de verdad:

Entries     5
Anchors     anchored
Tree head   63d2f5c4...
Receipts    verify
Verdict     PASS

Y las dos direcciones que importan más ponen el ledger en rojo: editar un veredicto sin volver a firmar, y borrar una entrada del medio — cada línea restante sigue firmada y verifica por sí sola; lo que no cuadra es la raíz del árbol, que es exactamente para lo que el árbol está.

Un hallazgo por el camino. La primera versión firmaba con CreateDevelopment y esperaba verde. El CLI reportó Receipts verify —la interoperabilidad era correcta a la primera— y aun así Verdict FAIL, porque AUD-TRANSP-04 rechaza una clave que el proceso se acuñó a sí mismo. La regla tenía razón y mi expectativa no. Quedó como test propio.

Desactivado por defecto, y exigente cuando se activa

• Sin semillas de clave, el arranque falla en vez de caer a una clave de desarrollo: eso produciría un ledger que parece firmado y no prueba nada — peor que no tenerlo, porque induce confianza.
• El Issuer y el Servicio de Transparencia no pueden compartir clave. RFC 9943 sitúa esa autoridad en una entidad separada; con una sola, el recibo es una autoafirmación.

Dependencias

Solo NSec (Ed25519, que .NET no trae y el verificador exige). System.Formats.Cbor resultó venir ya en .NET 10, así que se quitó.

Alcance

Cierra el criterio 1 de GT-588. Los criterios 2 y 3 ya estaban (ver beyondnetcode/evolith_arch32#375).

Suite completa: 1160/1160 con Postgres.

🤖 Generated with Claude Code