Restaura los sistemas en un orden deliberado

890. Identidad de la lección

Módulo

2.13 — Guardado y carga

Lección

Restaura los sistemas en un orden deliberado

Tipo académico

Laboratorio de depuración

Tipo de esquema

Práctica

Orden

Lección 2 del módulo

Tiempo estimado

40–50 minutos

891. Objetivo de aprendizaje

Al terminar esta lección, podrás redactar un contrato de carga, implementar una ruta de restauración acotada y validar un cambio de persistencia asistido por IA según reglas explícitas de validación de origen, migración, secuencia, fallos durante la aplicación y estado final de los sistemas.

892. Por qué importa

Un archivo guardado que se ha podido interpretar todavía no constituye un estado de juego seguro. Profile, Inventory y Loadout pueden ser responsables de datos distintos, mientras que el HUD solo presenta el estado confirmado por esos sistemas. Si un sistema cambia y otro posterior rechaza la restauración, el juego puede quedar con una mezcla de datos antiguos y nuevos aunque el cargador informe de un error.

La IA puede redactar un cargador, pero no debe decidir por ti el orden de autoridad ni el contrato de fallos. Esas decisiones deben quedar escritas antes de implementar y comprobarse tanto en el diff completo como en el estado final observable.

893. Ruta inicial

Usa el arnés ejecutable de persistencia proporcionado por el instructor si tu proyecto todavía no dispone de una ruta de carga adecuada. El arnés incluye:

• interfaces acotadas de Profile, Inventory, Loadout y HUD;
• fixtures de texto para la versión actual y la versión 1;
• fixtures con datos malformados y relaciones entre campos no válidas;
• un interruptor de fallo de restauración controlado mediante datos de prueba o configuración, sin depender de una interfaz concreta;
• tablas del estado anterior y posterior a la carga;
• plantillas para el contrato, la revisión de archivos modificados y los resultados de aceptación.

Puedes manejar el arnés con cualquier editor accesible, ejecutor de pruebas, interfaz de comandos o control proporcionado por el instructor. La evidencia requerida es la misma transición de estado y el mismo registro de revisión, no un método de entrada específico.

894. Concepto central: dos niveles de validación antes de restaurar

895. Flujo de restauración

Un fallo de validación y un fallo durante la aplicación no son lo mismo:

• Fallo de validación o comprobación previa: ningún sistema del juego ha cambiado, por lo que basta con rechazar la carga antes de modificar el estado.
• Fallo durante la aplicación: al menos un sistema puede haber cambiado. No basta con devolver un error; el cargador debe recuperar la coherencia según el contrato.

896. Estrategias de coherencia durante la aplicación

Elige una estrategia compatible con la implementación acotada:

1. Aplicación atómica por etapas

Cada sistema prepara un estado candidato sin publicarlo. El cargador publica todos los estados preparados como una sola operación. Si la preparación falla, no se publica ninguno.

2. Instantánea y reversión

Antes de aplicar cambios, captura el estado anterior necesario para restaurar cada sistema que pueda cambiar. Aplica los cambios en orden. Si falla Inventory o Loadout, restaura todos los sistemas ya modificados a partir de sus instantáneas y reconstruye el HUD desde el estado anterior recuperado.

3. Transición a un estado seguro definido

Si no se dispone de una aplicación atómica ni de una reversión fiable, define en el contrato un único estado seguro completo. Si la aplicación falla, lleva todos los sistemas relevantes a ese estado y reconstruye el HUD a partir de él. El estado seguro debe indicar los valores finales o reglas de reinicio de Profile, Inventory y Loadout; «mostrar un error» no define un estado.

Una política de reparación para datos incoherentes es distinta de la recuperación tras un fallo de aplicación. Toda reparación debe realizarse sobre el candidato normalizado en memoria, quedar documentada y superar la validación del esquema actual antes de iniciar la restauración.

897. Ejemplo concreto

La versión actual 2 usa esta estructura:

{
  "version": 2,
  "profile": { "credits": 120, "rank": 3 },
  "ownedItems": ["scanner"],
  "activeLoadout": ["scanner"]
}

Una ruta segura desde la versión 1 sigue estos pasos:

1. Interpretar el texto.
2. Confirmar que version está presente y contiene el valor admitido 1.
3. Validar únicamente los campos y tipos de la versión 1 que necesita la migración documentada.
4. Producir por separado un candidato de versión 2 en memoria.
5. Validar el candidato completo de versión 2 y sus invariantes entre campos.
6. Crear y comprobar el plan ordenado para Profile, Inventory y Loadout.
7. Aplicarlo con la estrategia de coherencia elegida.
8. Reconstruir el HUD desde el estado confirmado resultante.

Si el candidato contiene "grappler" en activeLoadout, pero no en ownedItems, el cargador debe seguir la regla escrita: rechazar el candidato o aplicar una reparación documentada antes de completar la validación actual. No debe conceder el objeto en silencio solo para que la presentación parezca coherente.

898. Traza de fallo

Supón que el estado anterior a la carga es:

El candidato solicita 120 créditos, scanner y grappler en propiedad, y grappler activo. Profile aplica sus datos, pero el interruptor de fallo hace que Loadout falle.

La prueba no se supera solo porque el cargador informe de un failure. Debe comprobarse el estado final de los cuatro sistemas:

• Con reversión, Profile, Inventory y Loadout coinciden con todo el estado anterior, y el HUD se reconstruye desde ese estado recuperado.
• Con una transición a un estado seguro definido, los tres sistemas de juego coinciden con el contrato de estado seguro, y el HUD refleja ese estado.
• Con una aplicación atómica por etapas, ningún dato del candidato llega a hacerse visible.

Una mezcla final como un Profile nuevo, un Loadout antiguo y un HUD actualizado es contradictoria e incumple el contrato.

899. Flujo de trabajo nativo de IA

1. Completa la plantilla breve del contrato: versiones admitidas, esquemas de origen, resultado de migración, invariantes actuales, orden de sistemas, estrategia de coherencia, definición de reversión o estado seguro y comprobaciones del estado final.
2. Proporciona a la IA únicamente el punto de entrada del cargador, las interfaces acotadas, los fixtures, los archivos permitidos y las comprobaciones de aceptación.
3. Exige una lista previa de archivos que pretende modificar y de los supuestos que está haciendo.
4. Pide una migración sin mutación y un plan de restauración explícito. No aceptes que se modifique el estado campo por campo mientras se interpretan o migran los datos.
5. Exige que la implementación exponga el interruptor de fallo configurable proporcionado para la restauración de Inventory o Loadout.
6. Revisa el diff completo con esta lista: solo archivos previstos, ninguna creación oculta de propiedad, ningún dato de presentación tratado como duradero, ninguna modificación antes de validar el candidato normalizado y ninguna ruta de error que deje un estado parcial sin especificar.
7. Justifica cada archivo modificado con una frase vinculada al brief. Rechaza o revierte los cambios no respaldados.

900. Práctica guiada

Usa el arnés inicial o una ruta existente equivalente.

1. Completa la plantilla del contrato de carga. Para los fallos durante la aplicación, elige reversión, aplicación atómica por etapas o una transición a un estado seguro completamente especificado.
2. Define el esquema mínimo de origen de la versión 1 y el esquema completo de la versión 2. Escribe la transformación sin mutación entre ambos.
3. Define el invariante de propiedad entre activeLoadout y ownedItems.
4. Implementa o revisa esta secuencia: interpretación, validación de origen, migración, validación actual, plan, comprobación previa cuando exista, aplicación, reconstrucción del HUD e informe del resultado.
5. Revisa el diff completo y registra una justificación para cada archivo modificado.
6. Ejecuta estos casos de aceptación con los fixtures de texto proporcionados:
   • contenido actual válido;
   • contenido válido de la versión 1 admitida;
   • texto malformado o ausencia del discriminador de versión;
   • contenido de una versión de origen que no cumple el esquema mínimo necesario para migrar;
   • contenido normalizado con propiedad incoherente;
   • fallo provocado durante la aplicación en Inventory o Loadout.
7. Para cada caso, completa una tabla de resultado esperado y observado para Profile, Inventory, Loadout, HUD y el resultado informado.
8. Documenta una propuesta rechazada por exceder el brief.

901. Evidencia

Entrega el contrato de carga, el brief acotado para la IA, el artefacto de implementación, la revisión del diff completo, las justificaciones de los archivos y la tabla de aceptación. La evidencia debe mostrar:

• validación de la versión y del esquema de origen antes de migrar;
• una migración que no modifica los sistemas ni el contenido de origen;
• validación completa del esquema actual y sus invariantes antes de restaurar;
• un plan de restauración ordenado y comprobación previa cuando la interfaz lo permita;
• un mecanismo concreto de aplicación atómica, reversión o transición a estado seguro para fallos durante la aplicación;
• comprobaciones del estado final de Profile, Inventory, Loadout y HUD tras el fallo provocado;
• reconstrucción del HUD a partir del estado de juego final y confirmado;
• una propuesta fuera de alcance rechazada.

902. Puntos clave

• Valida el discriminador de versión y la estructura mínima de origen antes de migrar.
• Migra a un candidato independiente en memoria y después valida el contrato actual completo.
• Rechazar antes de modificar el estado resuelve fallos de validación, no fallos posteriores a la aplicación de un sistema.
• Un fallo durante la aplicación exige publicación atómica, reversión de todos los sistemas modificados o una transición a un estado seguro completamente definido.
• Comprueba el estado final de los sistemas, no solo el error informado.
• Los sistemas de presentación deben observar el estado de juego restaurado y confirmado, no valores de presentación serializados; este mismo límite de observación conduce al siguiente módulo sobre audio.

903. Próxima lección

Continúa con 2.14 — Audio.

904. Comprobación