# TASK-050-live-snapshot-refresh-and-frontend-polling-alignment

## Goal
Alinear la captura periodica de snapshots y el consumo del frontend para que la web muestre datos mucho mas cercanos al estado real actual de los servidores, evitando que se queden estancados durante horas.

## Context
La pagina ya consume datos reales A2S, pero en la practica estaba mostrando snapshots demasiado antiguos, con mapas y poblacion desactualizados. Esto degrada la percepcion de fiabilidad del producto. El sistema necesitaba una politica mas util de refresco local y una lectura periodica razonable desde frontend.

## Steps
1. Revisar como se ejecuta actualmente el scheduler local de snapshots.
2. Revisar la frecuencia de captura actual o la ausencia de ejecucion continua.
3. Definir una frecuencia de refresco razonable para entorno local de desarrollo y demo, por ejemplo:
   - captura backend cada 60 segundos
   - refresco frontend cada 60-90 segundos
4. Ajustar el scheduler o su configuracion para facilitar un refresco frecuente y controlado.
5. Revisar el frontend para que vuelva a consultar el backend periodicamente sin necesidad de recargar la pagina.
6. Asegurar que el refresco no rompa la UI ni genere comportamiento agresivo.
7. Mantener el sistema simple y apropiado para la fase actual.
8. Documentar claramente como arrancar el backend y el refresco para ver datos vivos.

## Files to Read First
- AGENTS.md
- ai/repo-context.md
- backend/README.md
- backend/app/config.py
- backend/app/scheduler.py
- backend/app/collector.py
- frontend/assets/js/main.js
- frontend/index.html

## Expected Files to Modify
- backend/README.md
- backend/app/config.py
- backend/app/scheduler.py
- frontend/assets/js/main.js
- opcionalmente frontend/index.html si requiere una alineacion minima

## Constraints
- No introducir infraestructura pesada.
- No anadir librerias nuevas.
- No hacer cambios destructivos.
- No abrir nuevas fuentes de datos.
- Mantener la solucion simple, local y util para producto actual.

## Validation
- El sistema puede refrescar snapshots reales con una frecuencia razonable.
- El frontend actualiza la vista sin depender de recarga manual.
- Los mapas y jugadores cambian cuando cambian realmente en los servidores.
- La documentacion deja claro como usar este flujo en local.

## Change Budget
- Preferir menos de 5 archivos modificados.
- Preferir menos de 180 lineas cambiadas.

## Outcome
- `backend/app/config.py` baja el intervalo por defecto del scheduler local a `60` segundos para acercar la persistencia a una demo viva.
- `backend/app/scheduler.py` alinea la ayuda del comando con ese nuevo comportamiento orientado a desarrollo y demo.
- `frontend/index.html` expone `data-server-refresh-ms=\"60000\"` y `frontend/assets/js/main.js` reutiliza ese valor para relanzar `hydrateServers()` cada `60` segundos sin recargar la pagina y sin solapar peticiones.
- `backend/README.md` documenta el flujo local recomendado con backend, scheduler y polling del frontend.

## Validation Result
- Validado con `node --check frontend/assets/js/main.js`.
- Validado con `python -m py_compile backend/app/config.py backend/app/scheduler.py backend/app/collector.py`.
- Revisado en diff: la task queda limitada a `backend/README.md`, `backend/app/config.py`, `backend/app/scheduler.py`, `frontend/assets/js/main.js`, `frontend/index.html` y este archivo de task.

## Decision Notes
- Se mantuvo el polling solo sobre el bloque de servidores para no convertir toda la landing en una pagina con refresco agresivo. Salud del backend y trailer siguen siendo una hidratacion inicial simple.