Auditoría

Cada mutación relevante queda registrada en auditoria con un hash encadenado: hash = sha256(hashPrevio + contenido). Alterar o borrar una fila rompe la cadena para todos los posteriores.

Qué se registra

Solo mutaciones (nunca lecturas).
Campos: actorTipo (participante | admin | sistema), actorId, accion, entidadTipo/entidadId, datosAntes/datosDespues, ip, userAgent, requestId, ocurridoAt.
Los jobs y workers registran como sistema (p. ej. notificacion.procesar_lote).
Nunca se auditan secretos (hashes, tokens, contraseñas).

Leer la bitácora

GET /auditoria/?entidadTipo=reserva&entidadId=<uuid>&limit=50

Filtros: entidadTipo, entidadId, actorTipo, actorId, accion, desde/hasta (date-time), limit + cursor (opaco).

Verificar la cadena

curl -X POST http://localhost:5000/auditoria/verificar \
  -H 'content-type: application/json' -H "authorization: Bearer $TOKEN" \
  -d '{"desdeId":1,"limite":1000}'

{ "revisados": 1000, "ok": true, "ultimoId": 1000, "hayMas": true, "falloEn": null }

Recomputa sha256(hashPrevio + contenido) por lotes.
ok: false + falloEn: <id> → el primer id alterado.
hayMas: true → quedan lotes; sigue con desdeId: ultimoId + 1.
Un hueco (id faltante) también deja ok: false.

Inmutabilidad

Dos triggers lo garantizan a nivel de DB (no es solo convención de app):

auditoria no acepta UPDATE ni DELETE: cualquier intento directo falla con auditoria es inmutable… (P0001).
Los hashes se calculan con pg_advisory_xact_lock para que dos escrituras concurrentes no se salten el encadenado.

Por eso la bitácora no tiene endpoints de escritura: solo los services del dominio insertan, dentro de su transacción.

Siguiente paso

→ Jobs programados