Plan de trabajo y estado del proyecto

Optimización DB · Fases 1-4

• Semana 1 22-26 jun Fase 1 · Diseño técnico

  Validado local Diseño del esquema de save_utility, reglas de escritura desde POST /save, lectura desde GET /save y criterio de estado vigente por usuario.

• Semana 2 29 jun-3 jul Fase 2 · Implementación backend QA

  Validado local La implementación backend, el backfill, la escritura con payload liviano, las validaciones de casos borde y una prueba ligera con frontend conectado al entorno local ya fueron validados. El siguiente paso es preparar el plan controlado para QA.

• Semana 3 6-10 jul Fase 3 · QA y validación

  Validado en QA Migración y backfill ejecutados y validados en la base QA (221 usuarios, sin duplicados, payloads verificados contra su fila de origen). El 15 jul se desplegó el backend optimizado en QA y se validó en vivo con el frontend: cada guardado real generó un marcador liviano en el histórico y conservó el payload completo en la tabla de estado vigente, con lectura servida desde save_utility. La sincronización con Zoho CRM también se validó en QA. El 15-16 jul se completó una campaña de pruebas de casos borde e integridad de base de datos (todas superadas, incluida una verificación criptográfica de que ningún dato se pierde al separar el estado vigente) y se corrigieron dos incidencias preexistentes detectadas durante las pruebas.

• Semana 4-5 13-20 jul Fase 4 · Producción y entrega

  Desplegado en producción Optimización desplegada en producción el 20 jul 2026, en secuencia controlada por etapas (migración → despliegue → backfill). La migración creó la tabla save_utility en la base productiva y el backend optimizado se desplegó sobre el stack fury-prod. Se validó en vivo con el frontend Unity (guardado y carga reales) y se pobló el estado vigente de 1,338 usuarios activos, sin duplicados y con el guardado en vivo protegido. Rollout completado con éxito.

Runtime AWS Lambda · Node.js 24

• Semana 5 20-24 jul Bloque A · Preparación y upgrade técnico

  Base técnica completada Serverless Framework v4 quedó configurado y validado; los accesos de despliegue están operativos y las credenciales de base de datos, Zoho y Firebase se gestionan de forma segura mediante AWS Secrets Manager. El runtime permanece temporalmente en nodejs20.x para ejecutar el salto final a nodejs24.x como un cambio aislado.

• Semana 5 20-24 jul Bloque B · Validación local / CI

  Validación base aprobada Build, lint, 24 pruebas automatizadas, empaquetado Serverless y plantilla CloudFormation aprobados. La configuración desplegable no contiene credenciales sensibles en plaintext.

• Semana 6 27-31 jul Bloque C · QA

  QA aprobado El runtime nodejs24.x está desplegado y validado en QA sobre las 25 funciones. Además se completó la actualización de dependencias de seguridad y la migración de la librería de base de datos, ambas aprobadas en QA con pruebas de endpoints, autenticación, guardado, borrado de cuenta, jobs programados y CloudWatch.

• Semana 6 27-31 jul Bloque D · Producción y cierre

  Completado Release desplegado en producción el 6 ago 2026. Las 25 funciones quedaron activas sobre nodejs24.x, los 25 grupos de logs quedaron con retención de 180 días y la ventana de observación cerró sin errores ni necesidad de rollback.

Resumen

Frente	Estado	Inicio	Entrega esperada	Notas
Optimización DB	Completado	22 jun 2026	20 jul 2026	Migración, despliegue y backfill completados en producción el 20 jul 2026 sobre el stack fury-prod. Estado vigente de 1,338 usuarios activos poblado sin duplicados; smoke test en vivo con el frontend Unity aprobado (guardado y lectura desde save_utility). La tabla histórica save no fue modificada. Rollout por etapas completado con éxito.
Upgrade Runtime Node.js 24	Desplegado en producción	7 jul 2026	6 ago 2026	Las 25 funciones de producción están activas y con actualización exitosa sobre nodejs24.x. El stack fury-prod quedó en UPDATE_COMPLETE, el endpoint de estado respondió HTTP 200 con base de datos conectada y los 25 grupos de logs conservan 180 días.
Seguridad de dependencias	Desplegado en producción	24 jul 2026	6 ago 2026	Las actualizaciones se resolvieron en bloques aislados y validados por separado. El release productivo quedó con 0 vulnerabilidades críticas y 0 altas en dependencias de producción. Las advertencias residuales aceptadas están documentadas con su alcance y criterio de revisión.

Tareas DB

Fase	Tarea	Estado	Validación esperada	Notas de avance
Fase 1	Definir esquema de save_utility.	Validado local	Esquema revisado y probado localmente.	El modelo conserva el estado vigente por usuario y reduce la dependencia operativa del histórico completo.
Fase 1	Especificar lógica de escritura doble y lectura desde save_utility.	Validado local	Reglas de precedencia documentadas y verificadas en entorno local.	La lectura mantiene compatibilidad con el contrato actual de GET /save.
Fase 2	Crear tabla save_utility e índice único por usuario activo.	Validado local	Tabla disponible y validada en Postgres local.	La muestra local mantiene una sola fila operativa por usuario.
Fase 2	Ejecutar backfill del último game_save vigente por usuario.	Validado local	Conteo de usuarios activos vs. filas resultantes validado.	Prueba local: 37 usuarios activos generaron 37 filas en save_utility, sin duplicados.
Fase 2	Modificar POST /save para escritura transaccional.	Validado local	Marcador liviano en save y payload completo en save_utility.	Prueba local aprobada: el histórico guarda un marcador pequeño y el estado vigente conserva el payload completo.
Fase 2	Modificar GET /save para leer desde save_utility.	Validado local	Respuesta compatible con contrato actual.	La muestra local confirma que la fuente vigente coincide con el resultado esperado del modelo anterior.
Fase 3	Probar POST /save y GET /save.	Validado local	Pruebas funcionales backend aprobadas localmente antes de QA.	Smoke test local aprobado contra Postgres Docker, prueba ligera con frontend local completada y validaciones básicas de payload aprobadas antes de escribir en DB.
Fase 3	Ejecutar migración y backfill controlado en la base QA.	Completado	Tabla creada y estado vigente poblado por usuario, con validación de conteos y payloads.	Ejecutado el 7 jul con verificación previa de la base destino: 221 usuarios activos generaron 221 filas en save_utility, sin duplicados y con cada payload idéntico a su fila de origen. La tabla histórica save no fue modificada.
Fase 3	Desplegar backend optimizado en QA.	Completado	Endpoints de QA operando con el nuevo flujo de guardado.	Desplegado el 15 jul 2026 sobre el stack fury-qa (15 endpoints, 25 funciones) con el runtime intermedio nodejs20.x requerido por AWS. La verificación de estado confirma conectividad de las funciones con la base QA.
Fase 3	Validar compatibilidad con Zoho CRM y frontend.	Completado	Frontend y sincronización con Zoho validados en QA.	Frontend Unity validado en vivo contra QA: guardado y carga funcionan con el nuevo flujo. La sincronización con Zoho también se validó en QA: un ciclo real envió los registros recientes al CRM (procesados: 6, pendientes: 0), con el histórico anterior excluido por diseño.
Fase 4	Rollout productivo por etapas DB -> Lambda.	Completado	Producción operando con el nuevo flujo.	Ejecutado el 20 jul 2026 en secuencia por etapas: migración de save_utility (única pendiente, aplicada transaccionalmente) → despliegue del backend sobre fury-prod (15 endpoints, 25 funciones) → backfill de 1,338 usuarios activos. Cada etapa se validó antes de continuar y quedó registrada en bitácora.
Fase 4	Monitoreo post-despliegue y documentación técnica de cierre.	Completado	Logs y verificación funcional sin errores nuevos.	Smoke test en producción aprobado (un guardado real generó marcador liviano en el histórico y payload completo en save_utility, con lectura servida desde la tabla vigente). El cierre técnico quedó documentado; continúan controles operativos regulares de Zoho y CloudWatch.

Tareas Runtime Node.js 24

Bloque	Tarea	Estado	Validación esperada	Notas de avance
Preparación	Confirmar funciones Lambda en alcance y stacks fury-qa / fury-prod.	Completado	Inventario confirmado.	Inventario confirmado: 25 funciones Lambda en QA y producción, con despliegue administrado mediante Serverless/CloudFormation.
Preparación	Configurar repositorio, variables, secretos y credenciales u OIDC.	Completado	Nuevo camino de despliegue autorizado.	Accesos locales de despliegue operativos. Las credenciales de base de datos, Zoho y Firebase de QA fueron migradas a AWS Secrets Manager y validadas sin exponer valores sensibles en la configuración desplegada.
Upgrade técnico	Actualizar runtime a nodejs24.x, workflows, tooling y Serverless.	Completado	Branch/PR listo para validación.	Cambio aplicado y validado: las 25 funciones de QA ejecutan nodejs24.x. Los workflows y el tooling de desarrollo se actualizaron en el mismo ciclo.
Validación	Ejecutar instalación, build, lint, empaquetado Serverless y validación CloudFormation.	Completado	Checks completados bajo Node.js 24.	Aprobado bajo Node.js 24: build, lint, empaquetado y CloudFormation, con la batería de pruebas automatizadas ampliada de 24 a 41, incluidas pruebas nuevas contra una base de datos real.
QA	Desplegar Lambdas de QA con nodejs24.x.	Completado	QA actualizado mediante Serverless/CloudFormation.	Desplegado el 24 jul 2026. Las 25 funciones quedaron activas sobre nodejs24.x sin incidencias.
QA	Ejecutar pruebas de humo y revisar CloudWatch.	Completado	Aprobación para despliegue productivo.	Aprobado. Estado del servicio, conexión a base de datos, autenticación, guardado y lectura desde el frontend Unity, borrado de cuenta y jobs programados verificados, con CloudWatch sin errores.
Seguridad	Actualizar dependencias con vulnerabilidades conocidas.	Completado	Sin vulnerabilidades críticas.	Ejecutado en cinco bloques aislados y validados por separado, para poder atribuir cualquier problema a un único cambio. Las 5 vulnerabilidades críticas iniciales quedaron en 0. Incluye la librería de autenticación, el SDK de Firebase y el reemplazo de un cliente HTTP obsoleto por el nativo de Node.js 24.
Seguridad	Migrar la librería de acceso a base de datos (TypeORM).	Completado	QA aprobado sin cambios de estructura.	Cambio mayor de versión, el de mayor riesgo del ciclo, aislado en su propia rama. Se comprobó que la estructura de la base de datos no cambió comparando un volcado del esquema antes y después. Validado en QA con guardado y lectura reales desde Unity y con un borrado de cuenta verificado contando registros antes y después, para descartar borrados incompletos.
Seguridad	Documentar las advertencias restantes y su criterio de aceptación.	Completado	Informe de residuales entregado.	Las advertencias que quedan son de tipo denegación de servicio en herramientas internas de compilación y búsqueda de archivos. No existe ruta desde peticiones de usuarios hacia ese código y dependen de correcciones de terceros aún no publicadas. Cada una queda documentada con su justificación y el evento que obligaría a revisarla.
Producción	Desplegar producción en ventana acordada.	Completado	Producción actualizada a nodejs24.x.	Desplegado el 6 ago 2026 desde main, commit 3528692. Preflight aprobado con snapshot disponible, esquema al día y baseline validado. Resultado: fury-prod en UPDATE_COMPLETE, 25/25 funciones activas sobre Node.js 24 y estado operativo HTTP 200.
Cierre	Verificar logs, estado del runtime y cierre del camino anterior de despliegue.	Completado	Un solo camino autorizado para producción.	Verificación completada: 25/25 grupos de logs a 180 días, cinco jobs naturales ejecutados correctamente y ventana de observación de 36 minutos sobre los 25 grupos, con 41 registros revisados y cero coincidencias de error. No se requirió rollback.

Registro de pruebas y validaciones por ambiente. La optimización DB fue desplegada y validada en producción el 20 jul 2026. El 6 ago 2026 se completó el release de Node.js 24, seguridad de dependencias, validación de acciones y retención de logs, con preflight, snapshot, verificación de datos, jobs naturales y observación posterior.

Local · Optimización DB

Paso	Objetivo	Estado	Evidencia
Base local aislada	Probar sin riesgo sobre QA.	Completado	Postgres local en Docker. No se escribieron cambios en la base QA.
Muestra representativa	Validar el modelo con varios usuarios y payloads reales exportados.	Completado	37 usuarios y 72 saves importados localmente desde los archivos de prueba.
Migraciones desde cero	Confirmar que el esquema se puede crear de forma reproducible.	Completado	Las migraciones corrieron correctamente y la validación del esquema quedó al día.
Backfill local	Crear el estado vigente por usuario sin duplicar filas operativas.	Completado	37 usuarios activos resultaron en 37 filas de save_utility; segunda ejecución idempotente.
Pruebas de borde	Revisar casos antes de tocar QA.	Completado	Casos borde validados localmente: JSON inválido, game_save no objeto, eco de marcador liviano, payload mayor a 8 MB y payload sin señales mínimas de partida jugable.

Forma del marcador liviano

El histórico save sigue recibiendo una fila por guardado para mantener compatibilidad, pero su campo game_save ya no guarda el payload jugable completo. En su lugar guarda un marcador pequeño que indica que el payload real fue movido a save_utility. La tabla save_utility conserva una sola fila operativa por usuario con el payload completo que usa GET /save.

-- forma de inspección del nuevo marcador y del payload real
select
  s.id as save_row_id,
  s.user_id,
  s.save_id,
  s.game_save ->> 'storage' as marker_storage,
  s.game_save ->> 'payload_moved' as payload_moved,
  s.game_save ->> 'payload_size_bytes' as payload_size_bytes,
  pg_column_size(s.game_save) as marker_bytes,
  su.id as utility_row_id,
  pg_column_size(su.game_save) as full_payload_bytes
from save s
join save_utility su on su.user_id = s.user_id
where s.game_save ->> 'storage' = 'save_utility'
order by s.created_at desc;

-- ejemplo local observado
-- marker_bytes: 262
-- full_payload_bytes: 106,131

-- ejemplo frontend local posterior
-- marker_bytes: 262
-- full_payload_bytes: 106,268
-- reducción observada: ~405.6x

Resultados locales

Prueba	Aplica a	Estado	Resultado / evidencia
Conteo de usuarios activos vs. filas en save_utility.	DB Fase 2 / Fase 3	Validado local	37 usuarios activos -> 37 filas en save_utility; 0 duplicados por usuario.
Revisión de muestras de payload migrado.	DB Fase 3	Validado local	Muestra local de 72 saves; la fila vigente migrada coincide con el último estado esperado por usuario.
POST /save registra telemetría y actualiza estado vigente.	DB Fase 3	Validado local	Smoke test local aprobado: marcador de 262 bytes en save vs. payload representativo de 115,262 bytes en save_utility.
GET /save lee desde save_utility sin romper contrato frontend.	DB Fase 3	Validado local	La prueba local y el consumo desde frontend devolvieron el payload completo desde save_utility.
Validaciones de casos borde antes de escritura.	DB Fase 3	Validado local	El backend rechaza payloads inválidos antes de abrir escritura DB: JSON inválido, game_save no objeto, marcador reenviado, payload mayor a 8 MB o payload sin señal mínima de partida jugable.

QA

Validación	Aplica a	Estado	Resultado / evidencia
Migración y backfill controlado en QA.	DB QA	Completado	Ejecutado el 7 jul 2026. Verificación previa de la base destino (18,083 filas de save, 221 usuarios). Resultado: 221 filas en save_utility, cero duplicados, cero marcadores y cada payload idéntico a su fila de origen. El backfill quedó protegido para que una re-ejecución nunca sobrescriba payloads reales.
Pruebas funcionales de POST /save y GET /save.	DB QA	Completado	Validado el 15 jul con una sesión real de juego contra QA: 6 guardados generaron 6 marcadores livianos de 230 bytes en el histórico save, conservando una sola fila de estado vigente en save_utility con el payload completo de 402,414 bytes (~393 KB). La lectura se sirvió directamente desde save_utility, sin recurrir al camino heredado. Reducción observada en el histórico: ~1,750x por guardado.
Compatibilidad con frontend en QA.	DB QA	Completado	El frontend Unity guardó y cargó correctamente contra QA con el nuevo flujo, incluyendo la continuación de partidas en dos cuentas existentes (con historial de 3,517 y 27 guardados). El contrato de GET /save y POST /save se mantuvo sin cambios para el cliente.
Ciclo de sincronización con Zoho CRM.	DB QA	Completado	Validado tanto por invocación manual (procesados: 6) como por el ciclo programado automático (procesados: 18, pendientes: 0). El marcador liviano no afecta a Zoho (no consume game_save), y la sincronización se limita a los registros recientes; el histórico anterior queda excluido por diseño.
Pruebas de casos borde de la API.	DB QA	Completado	16/16 casos aprobados: la API rechaza entradas inválidas antes de escribir (JSON malformado, payload no válido, payload sobredimensionado), procesa correctamente caracteres especiales, y mantiene un único estado vigente por usuario bajo guardados rápidos (10) y concurrentes (5).
Integridad de la base de datos.	DB QA	Completado	6/6 verificaciones sobre toda la base QA: una sola fila vigente por usuario, sin duplicados ni referencias rotas, y una verificación criptográfica (SHA-256) que confirma que ningún payload se perdió ni se alteró al separar el estado vigente. El backfill permanece intacto (220/220 usuarios idénticos a su origen).
Flujo de usuario nuevo (primer guardado).	DB QA	Completado	Validado el primer guardado de una cuenta nueva (creación del estado vigente desde cero), con lectura correcta y limpieza total de la cuenta de prueba.
Correcciones de calidad detectadas en QA.	Backend	Corregido	Las pruebas exhaustivas detectaron y se corrigieron dos incidencias preexistentes (no introducidas por la optimización): el borrado de un usuario con guardados y la validación del registro de usuarios. Ambas correcciones fueron desplegadas y validadas en QA.

Producción

Validación	Aplica a	Estado	Resultado / evidencia
Rollout productivo por etapas.	DB Producción	Completado	Ejecutado el 20 jul 2026. Verificación previa de la base productiva (una sola migración pendiente). Migración de save_utility aplicada transaccionalmente, backend desplegado sobre fury-prod, y backfill de 1,338 usuarios activos: 1,338 filas en save_utility, cero duplicados, cero marcadores mal almacenados. El guardado de prueba en vivo quedó protegido por el guard de timestamp (no se sobrescribió con datos más antiguos). La tabla histórica save no fue modificada.
Monitoreo post-despliegue.	DB Producción	Completado	Smoke test en vivo aprobado (POST y GET reales contra save_utility). El flujo permanece cubierto por monitoreo operativo regular de CloudWatch, integridad DB y colas de Zoho.
Preflight y punto de recuperación del release.	Release Producción	Completado	Identidad de despliegue, postura de recuperación RDS, baseline, colas Zoho y esquema validados. El snapshot fury-prod-pre-node24-action-validation-log180-retry-20260806T105910Z quedó disponible antes del retry.
Despliegue Node.js 24 y retención de logs.	Release Producción	Completado	Stack UPDATE_COMPLETE; 25/25 Lambdas nodejs24.x, Active y Successful; endpoint de estado HTTP 200 con database: true; 25/25 grupos de logs configurados a 180 días.
Integridad de base de datos.	Release Producción	Completado	Cero variación de filas en las 11 tablas rastreadas entre preflight y cierre; las ocho migraciones y las colas pendientes permanecieron sin cambios.
Jobs naturales y ventana de rollback.	Release Producción	Completado	Acciones, cuestionarios/respuestas, guardados, artículos y bancos completaron en Node.js 24. Observación de 36 minutos sobre 25 grupos y 41 registros: cero errores y rollback no requerido.

Resumen del release · 6 ago 2026

Archivos adjuntos

Archivo	Qué demuestra	Resultado
Resumen del release (JSON) →	Resultado final, recuperación del primer intento, estado del stack, runtime, retención, invariantes DB, jobs y ventana de rollback.	PASS
Preflight y snapshot →	Identidad verificada, RDS disponible y cifrado, retención de backup, snapshot disponible, baseline y esquema al día.	PASS
Traza del despliegue →	Commit, versión de Node/npm, validación de esquema y ventana exacta del despliegue Serverless exitoso.	PASS
Baseline final DB →	Conteos finales de las 11 tablas, colas Zoho, ocho migraciones y comparación con el preflight sin variaciones.	PASS
Gate final de QA →	Runtime, retención, validación de API, playtest Unity, persistencia, sincronización natural y logs limpios antes de producción.	PASS
Resolución Zoho cuestionarios →	La cola QA pasó de 893 respuestas pendientes a cero tras la corrección; producción también confirmó ambas colas vacías en el job natural posterior al release.	RESUELTO

Los adjuntos fueron sanitizados: no incluyen credenciales, tokens, llaves privadas, cadenas de conexión, IDs de cuenta AWS, payloads de juego ni identificadores del usuario de prueba.