Etapa 3: log de auditoria, deshacer y rollback de mapas

[leocagli]

Parte de #2 (modo construcción). Depende de la capa de persistencia.

Por qué

Editar el mundo en vivo es destructivo y va a haber accidentes. Sin poder deshacer, un error de una persona con permisos borra trabajo de horas y no hay forma de saber quién lo hizo.

Lo que ya existe

La tabla game_data_revisions (kind, entity_id, action, checksum) ya registra cambios de game data. Sirve como base, pero para deshacer hace falta guardar el estado anterior, no sólo un checksum.

Alcance

1. Log de auditoría consultable: quién cambió qué mapa, cuándo y qué cambió exactamente.
2. Deshacer la última operación sobre un mapa.
3. Rehacer.
4. Volver un mapa a una revisión anterior (rollback).
5. Diff entre dos revisiones de un mapa.

Decisión de diseño a resolver

Guardar el estado completo del mapa por revisión es simple pero pesado: 10.000 tiles por mapa, y una sesión de edición genera muchas revisiones.

Guardar sólo el delta de cada operación es mucho más liviano y hace el undo natural, pero reconstruir un estado arbitrario obliga a reproducir la cadena.

Sugerencia: deltas, con un snapshot completo cada N revisiones para acotar el costo de reconstrucción.

Criterios de aceptación

• Toda mutación de mapa queda en el log con autor, fecha y contenido del cambio
• Deshacer revierte exactamente la última operación
• Rehacer restaura lo deshecho
• Se puede volver a una revisión anterior arbitraria
• El diff entre dos revisiones es legible
• Deshacer una operación ya publicada exige republicar (no cambia el mundo en silencio)
• Tests de integración

Archivos relevantes

• api/src/repositories/ (todos los repos que ya escriben en game_data_revisions)
• api/schema.sql

[ardaerturk]

Hola — me gustaría tomar este bounty si sigue disponible. Antes de abrir un PR, revisaría el modelo actual de game_data_revisions y propondría un diseño de deltas + snapshots periódicos que preserve autoría, undo/redo, rollback y diffs legibles sin copiar 10.000 tiles por cada operación. Lo implementaría con pruebas de integración para round-trip undo/redo, rollback arbitrario y la regla de que deshacer una revisión publicada exige republicar. ¿Preferís que primero deje una nota corta con el esquema y las invariantes, o que avance directamente con un PR enfocado?

[atiqur-rahman-pro]

Hola @leocagli,

Ya tengo lista la solución completa para la Issue #12 con el diseño de deltas + snapshots periódicos cada 20 revisiones, historial auditable, undo/redo bidireccional, rollback y diffs estructurados (api/src/repositories/gameMapRevisions.ts), además de la suite de pruebas unitarias en Vitest.

¿Te gustaría que abra el PR inmediatamente?