V6.8.7.50

Garlic SaveMgr — Cambios significativos de v6.8.1 a v6.8.7.50

Resumen técnico y funcional de la evolución del proyecto desde la última versión pública documentada v6.8.1 hasta la revisión v6.8.7.50.

Este documento destaca cambios de arquitectura, funcionalidad, estabilidad y observabilidad. No pretende sustituir el historial completo de revisiones.

Estado de partida — v6.8.1

La línea v6.8.1 ya había consolidado la reescritura del cliente desde Python/PySide6 hacia C# / .NET 8 / WPF, manteniendo el flujo principal de backup/restauración y añadiendo una interfaz moderna, perfiles de consola, autodetección, caché de payload y carátulas, SHA-256, ZIP, cancelación y diagnóstico.

La arquitectura de publicación partía todavía de un cliente fundamentalmente monolítico, con las capacidades principales integradas alrededor del host.

Evolución arquitectónica

De aplicación monolítica a host modular

La evolución posterior separó las capacidades en DLL independientes cargadas por el host:

• SEGURIDAD — integridad y auditoría SHA-256.
• PAPELERA — gestión independiente de Papelera PS5 y Papelera PC.
• SALUD — diagnóstico, observabilidad, histórico y análisis.
• ACTUALIZADOR — comprobación e instalación de nuevas versiones.

El contrato común IModuleHostContext / IExecutableModule permite evolucionar un módulo sin recompilar el host mientras no cambie el contrato compartido.

Servicios comunes centralizados

La lógica transversal quedó concentrada en GarlicSaveMgr/Services, evitando duplicar Backup, API Garlic, SHA-256, caché de carátulas, metadata, descubrimiento y operaciones.

Esto estableció una frontera más clara entre:

HOST
  → infraestructura y servicios comunes

MODULES
  → UI + estado + orquestación específica del dominio

Backup y Restore

La evolución mantuvo el flujo de datos y reforzó su seguridad:

• Los backups se almacenan como .img + metadata .json.
• SHA-256 pasa a formar parte del modelo de integridad.
• El tamaño de un backup se obtiene del fichero .img físico, no de snapshots ni metadata.
• La restauración valida el perfil/propietario antes de modificar la consola.
• Se mantiene el principio de fallo cerrado: sin datos suficientes para demostrar una coincidencia de perfil, no se restaura.
• Se corrigieron diferencias entre uid, id, account_id y aid entre distintos endpoints de Garlic.
• Se añadieron normalización y diagnóstico de identificadores sin convertir automáticamente bases numéricas ambiguas.
• La eliminación de consola pasó a utilizar el endpoint correcto de Garlic.
• Las operaciones destructivas requieren confirmación explícita.

Separación real de las dos Papeleras

Uno de los cambios conceptuales más importantes es la separación completa entre:

PS5 TRASH
PC TRASH

Quedan definidos como almacenes independientes.

Se estableció además un contrato de eventos separado:

backups-changed
ps5-trash-changed
pc-trash-changed

Por tanto:

• GUARDAR COPIA no crea ni refresca ninguna Papelera.
• Los cambios de backups activos no refrescan una Papelera.
• La Papelera PS5 y la Papelera PC reaccionan exclusivamente a sus propios eventos.

Esto evita que operaciones aparentemente inocuas produzcan movimientos o refrescos cruzados.

Smart Backup y operaciones seguras

El sistema adoptó una política conservadora:

coincidencia demostrable → puede omitirse la copia
duda                   → copiar

No se considera que una copia sea redundante por una inferencia ambigua.

También se reforzó la protección de operaciones destructivas para impedir que un fallo previo de backup deje a la consola sin una copia de seguridad válida.

Descubrimiento de consola y red

La autodetección de consola evolucionó de una comprobación básica a un flujo de descubrimiento controlado:

• Escaneo de la red local con hasta 1.275 direcciones como una fase lógica.
• Concurrencia limitada para el descubrimiento.
• Validación posterior contra Garlic.
• Separación entre el puerto de carga 9021 y la API Garlic 8082.
• Fallback de IP manual conservado.
• Selección de la consola Garlic activa más recientemente mediante LastSeenLocal.
• Se eliminó el falso aviso de "consola no válida" durante la ventana inicial de detección mediante InitialConnectionGate.

Sistema de carátulas

La resolución de carátulas pasó por varias etapas hasta llegar a un pipeline más resiliente.

Cambios relevantes

• Caché local.
• Deduplicación por TitleId.
• Descargas en segundo plano.
• Concurrencia limitada.
• Cancelación y espera correcta antes de liberar recursos.
• Telemetría separando COMPLETED, NOT_FOUND, FAILED y estados atascados.
• Resolución adicional TitleId → ContentId cuando es necesario.
• Uso de fuentes de catálogo/Store y CDN correspondientes.
• Fallback regional para títulos que no aparecen en una región concreta.

En v6.8.7.48 se estableció el fallback:

gb/en
  ↓
us/en
  ↓
es/es

evitando declarar NOT_FOUND después de un único 404 regional.

En v6.8.7.50 la documentación se sincronizó con el recorrido real de Chihiro y dejó de describir incorrectamente PlayStation Catalog v2 como única fuente canónica.

Nacimiento y evolución de SALUD

El antiguo MOTOR evolucionó a SALUD para describir mejor su responsabilidad.

SALUD dejó de ser simplemente una pantalla de estadísticas y pasó a concebirse como el subsistema de observabilidad global de Garlic SaveMgr.

SALUD 2.1 / 2.2

Se incorporaron:

• Health Score determinista.
• MotorReport / modelo estructurado de diagnóstico.
• detección de anomalías.
• histórico local de telemetría.
• tendencias básicas.
• recomendaciones.
• contexto estructurado para futura IA.
• observación del host, módulos, operaciones y carátulas.

Corrección fundamental del concepto de salud

Se separaron explícitamente:

HEALTH
    ¿Está funcionando correctamente el sistema ahora?

DIAGNOSTICS
    ¿Qué merece atención, aunque no sea un fallo operativo?

Por esta razón, elementos meramente históricos no deben degradar la salud.

Ejemplo:

2 snapshots history-only

puede ser información diagnóstica, pero no implica por sí mismo una pérdida de Health Score.

Del mismo modo, la severidad visual de una anomalía no implica automáticamente una penalización. El impacto sobre Health debe ser explícito.

Observabilidad global

La evolución más reciente amplía SALUD para vigilar el conjunto de la aplicación:

HOST
MÓDULOS
SERVICIOS
OPERACIONES ASÍNCRONAS
CARÁTULAS
CONEXIONES
BACKUPS
RESTORE
ALMACENAMIENTO
INTEGRIDAD
HISTÓRICO

Especialmente importante es la detección de tareas:

QUEUED
RUNNING
COMPLETED
FAILED
CANCELLED
TIMEOUT
STALLED

Así SALUD puede diferenciar entre:

operación lenta

y:

operación que lleva tiempo sin actividad o progreso

Esto permite detectar, por ejemplo, una carátula que permanece indefinidamente en cola o en RUNNING.

Motor de temas

El sistema visual pasó a utilizar un esquema declarativo basado en XML Schema 2:

• Default.xml embebido como fallback.
• herencia de valores ausentes.
• DynamicResource para actualización visual.
• validación de temas.
• aislamiento frente a XAML/código arbitrario.

Se estableció una regla importante:

no mutar SolidColorBrush.Color de un recurso existente

Cuando hace falta modificar el color, se sustituye el recurso por un brush nuevo.

Actualizador

El actualizador pasó a ser un módulo DLL integrado en el host en lugar de depender de un ejecutable auxiliar permanente.

El flujo actual:

GitHub Releases
    ↓
comparación de versión
    ↓
descarga del EXE
    ↓
validación PE
    ↓
SHA-256 cuando está disponible
    ↓
script temporal
    ↓
cierre del host
    ↓
sustitución
    ↓
reinicio

El update solo se permite cuando la versión remota es estrictamente superior.

Mejoras de robustez y diagnóstico

Durante la serie 6.8.7.x se corrigieron numerosos problemas que no eran visibles como grandes funcionalidades, pero sí afectaban a la fiabilidad:

• errores de compilación en módulos y tests.
• problemas de inferencia de tipos en tareas de carátulas.
• referencias a variables fuera de su ámbito.
• manejo más robusto de cancelación.
• eliminación de tareas pendientes antes de Dispose.
• protección contra avisos prematuros durante el descubrimiento.
• sincronización de versiones entre host, módulos y scripts.
• limpieza de código muerto y referencias obsoletas.
• pruebas de regresión para carátulas, descubrimiento y SALUD.

Resultado de la evolución

La transición puede resumirse así:

v6.8.1
Cliente C#/.NET 8 + WPF
        ↓
mejoras de backup / restore / detección
        ↓
servicios core centralizados
        ↓
arquitectura modular
        ↓
Security / Trash / Updater
        ↓
MOTOR
        ↓
SALUD
        ↓
Health + Diagnostics + History + Anomalies
        ↓
observabilidad global
        ↓
v6.8.7.50

La diferencia principal no es solamente el número de funciones. La aplicación pasó de ser principalmente un gestor de saves con herramientas auxiliares a una arquitectura donde:

HOST
  = shell estable

SERVICES
  = capacidades comunes

MODULES
  = dominios independientes

SALUD
  = observabilidad global

Cambios que deben considerarse parte del contrato actual

A partir de v6.8.7.50, cualquier evolución debe preservar como mínimo:

1. Independencia de los módulos respecto al host mientras no cambien los contratos.
2. Separación absoluta de PS5 TRASH y PC TRASH.
3. GUARDAR COPIA nunca crea/refresca una Papelera.
4. backups-changed, ps5-trash-changed y pc-trash-changed permanecen diferenciados.
5. Tamaños de backups físicos obtenidos del .img.
6. Snapshots tratados como historial, no como copias físicas adicionales.
7. Smart Backup conservador ante incertidumbre.
8. SHA-256 y trabajo de I/O fuera del hilo de interfaz.
9. Carátulas oportunistas: nunca deben bloquear Backup, Restore, Trash o el host.
10. SALUD observa y diagnostica; no se convierte en ejecutor automático de operaciones destructivas.
11. HEALTH y DIAGNOSTICS permanecen conceptualmente separados.
12. Ningún build/test debe declararse validado sin ejecución real.

---

Nota de versiones

v6.8.7.50 es la revisión operativa del proyecto; la versión de producto/assembly continúa siendo 6.8.7 / 6.8.7.0. El cambio 50 identifica la revisión de desarrollo y no constituye una nueva versión de producto.