WEB APP / STATE / SECURITY / QA

Foundry
companion web

Una web estática que terminó resolviendo tres problemas a la vez: presentar datos canónicos, mantener estado temporal durante una sesión y sincronizarlo sin convertir una URL pública en una credencial.

Escala6 personajes · 361 entidades auditadas
FrontendDesktop + mobile independiente
SyncGoogle Sheets + Apps Script
QAPlaywright + suites específicas
01 / CONTEXTO

Una interfaz útil no podía romper la fuente de verdad.

El proyecto parte de exports completos de actores de Foundry VTT. Esos datos canónicos incluyen estadísticas, hechizos, equipo, rasgos, recursos y acciones. El desafío fue construir una experiencia más usable —especialmente en mobile— sin mezclar datos permanentes con estado de sesión ni introducir correcciones manuales frágiles.

La solución separa capas: bundle canónico, overrides determinísticos de presentación y stores temporales de sesión.

02 / ARQUITECTURA

Desktop, mobile y estado temporal como piezas separadas.

La vista mobile no es una reducción del DOM desktop. Tiene su propio view model y renderers para combate, hechizos, equipo, rasgos y estado adicional. Esto permite que cada interfaz responda a su contexto sin acoplarse visualmente a la otra.

01 / DATA361 entidades

126 hechizos, 80 ítems de equipo y 155 rasgos auditados.

02 / STATE1 store por personaje

HP, recursos, slots, inventario y estado temporal en un registro unificado.

03 / TTL5 horas

Estado temporal renovable con reset explícito mediante sessionId.

04 / QAAutomatizado

Suites para mobile, browser, session store, sync, backend y localización.

03 / SEGURIDAD

Un backend público no tiene por qué ser un backend abierto.

La sincronización remota usa Apps Script y Google Sheets, pero el diseño es fail-closed. La URL del Web App puede ser pública; leer o escribir estado requiere POST autenticado. El token vive en Script Properties y, del lado cliente, sólo temporalmente en sessionStorage.

HARDENING

El QA del backend cubrió autenticación, protocolo, esquema, conflictos, TTL, whitelist, límites de tamaño y locking; el hardening documentado pasó 51/51 comprobaciones locales.

El token no se publica en GitHub, query strings, logs ni archivos de configuración. Cuando se importa por fragmento URL, el fragmento se elimina inmediatamente de la barra de direcciones.

04 / QA Y HANDOFF

El proyecto tenía que sobrevivir a otra sesión y a otra persona.

Además del código, el repo incluye un punto de entrada, instrucciones para agentes y un handoff específico para continuar desde otra cuenta sin depender del historial de chat. La continuidad queda documentada en el repositorio, no en memoria informal.

El Browser Mobile QA cubre Chromium Android simulado, WebKit iPhone simulado, Chromium desktop, seis personajes y cinco pestañas mobile. La capa de localización de hechizos registró 633 comprobaciones sin fallos durante su validación.

05 / QUÉ DEMUESTRA

Separación de responsabilidades, estado y seguridad operativa.

El valor técnico del proyecto no está en “hacer fichas de juego”. Está en resolver sincronización temporal, autenticación, compatibilidad entre interfaces, QA automatizado y handoff mantenible sobre una base de datos canónica que no debía corromperse.