Fix historical aggregate snapshots and empty states
This commit is contained in:
devRaGonSa
@@ -0,0 +1,80 @@
|
||||
# TASK-055-fix-all-servers-historical-aggregate
|
||||
|
||||
## Goal
|
||||
Corregir el agregado histórico `all-servers` / `Totales / Todos` para que resumen, tops semanales y partidas recientes reflejen realmente la suma o agregación de los servidores con histórico disponible, en vez de devolver snapshots vacíos.
|
||||
|
||||
## Context
|
||||
La situación actual del histórico es esta:
|
||||
- `comunidad-hispana-01` muestra datos correctos
|
||||
- `comunidad-hispana-02` muestra datos correctos
|
||||
- `Totales / Todos` aparece vacío
|
||||
- `comunidad-hispana-03` todavía no debe considerarse error, porque no se ha ejecutado bootstrap para ese servidor
|
||||
|
||||
Esto indica un fallo específico en la generación o persistencia del agregado lógico `all-servers`, no un problema general de la capa histórica.
|
||||
|
||||
## Steps
|
||||
1. Revisar la implementación actual del agregado lógico `all-servers` en:
|
||||
- snapshots
|
||||
- payloads
|
||||
- rutas
|
||||
- generación/prewarm
|
||||
2. Verificar cómo se construyen actualmente:
|
||||
- resumen global
|
||||
- weekly leaderboards globales
|
||||
- recent matches globales
|
||||
3. Corregir la lógica para que `all-servers` agregue correctamente los servidores con histórico disponible.
|
||||
4. Asegurar que el agregado:
|
||||
- incluya `comunidad-hispana-01`
|
||||
- incluya `comunidad-hispana-02`
|
||||
- no dependa de que `comunidad-hispana-03` ya tenga histórico
|
||||
- no colapse a vacío si uno de los servidores no tiene datos aún
|
||||
5. Verificar que los snapshots globales se generen con datos reales y no se sobrescriban con vacíos.
|
||||
6. Regenerar los snapshots necesarios de `all-servers`.
|
||||
7. Validar que en la UI:
|
||||
- `Totales / Todos` deje de mostrar 0 partidas / 0 jugadores
|
||||
- los tops globales ya tengan datos
|
||||
- recent matches globales ya tengan contenido si existe histórico en #01 y #02
|
||||
8. Documentar brevemente la semántica final del agregado global.
|
||||
9. No tratar todavía `#03` como parte obligatoria del agregado si no hay bootstrap para ese servidor.
|
||||
10. Al completar la implementación:
|
||||
- dejar el repositorio consistente
|
||||
- hacer commit
|
||||
- hacer push al remoto si el entorno lo permite
|
||||
|
||||
## Files to Read First
|
||||
- AGENTS.md
|
||||
- backend/README.md
|
||||
- backend/app/historical_storage.py
|
||||
- backend/app/historical_snapshots.py
|
||||
- backend/app/historical_snapshot_storage.py
|
||||
- backend/app/payloads.py
|
||||
- backend/app/routes.py
|
||||
- frontend/assets/js/historico.js
|
||||
- frontend/historico.html
|
||||
|
||||
## Expected Files to Modify
|
||||
- backend/app/historical_storage.py
|
||||
- backend/app/historical_snapshots.py
|
||||
- backend/app/historical_snapshot_storage.py
|
||||
- backend/app/payloads.py
|
||||
- backend/app/routes.py
|
||||
- backend/README.md
|
||||
- opcionalmente frontend/assets/js/historico.js si hace falta ajustar cómo se interpreta el agregado global
|
||||
|
||||
## Constraints
|
||||
- No romper #01 ni #02.
|
||||
- No exigir histórico de #03 para que `all-servers` funcione.
|
||||
- No crear páginas nuevas.
|
||||
- No hacer cambios destructivos.
|
||||
- Mantener el trabajo centrado en arreglar el agregado global.
|
||||
|
||||
## Validation
|
||||
- `Totales / Todos` deja de estar vacío.
|
||||
- El resumen global tiene partidas, jugadores y mapas si #01 y #02 tienen histórico.
|
||||
- Los tops globales funcionan.
|
||||
- Las partidas recientes globales funcionan.
|
||||
- Los cambios quedan committeados y se hace push al remoto si el entorno lo permite.
|
||||
|
||||
## Change Budget
|
||||
- Preferir menos de 6 archivos modificados o creados.
|
||||
- Preferir menos de 240 líneas cambiadas.
|
||||
@@ -0,0 +1,73 @@
|
||||
# TASK-056-historical-empty-state-and-copy-polish
|
||||
|
||||
## Goal
|
||||
Mejorar los estados vacíos y el copy de la página histórica para que `comunidad-hispana-03` se muestre de forma honesta mientras no tenga bootstrap ejecutado, y para que la información de cobertura y fallback semanal suene más natural y menos técnica.
|
||||
|
||||
## Context
|
||||
Tras los últimos cambios, la página histórica ya funciona para #01 y #02, pero aún hay aspectos de UX/copy mejorables:
|
||||
- `comunidad-hispana-03` aparece vacía, lo cual ahora mismo es normal porque no se ha ejecutado bootstrap para ese servidor
|
||||
- algunos textos siguen sonando demasiado técnicos
|
||||
- labels como `672,1 días registrados` no son la mejor forma de presentar cobertura histórica
|
||||
- el texto del fallback semanal es correcto, pero demasiado largo y técnico
|
||||
|
||||
## Steps
|
||||
1. Revisar los textos actuales de:
|
||||
- resumen
|
||||
- badges de cobertura
|
||||
- periodo registrado
|
||||
- fallback semanal
|
||||
- estados vacíos de resumen / tops / recientes
|
||||
2. Hacer que `comunidad-hispana-03` muestre un estado explícito y honesto del tipo:
|
||||
- sin histórico registrado todavía
|
||||
- pendiente de bootstrap / pendiente de registro histórico
|
||||
- o equivalente mejor, siempre claro y natural
|
||||
3. Evitar que `#03` parezca un error roto si simplemente aún no se ha cargado histórico.
|
||||
4. Revisar la forma de mostrar la cobertura histórica. Priorizar formulaciones más naturales como:
|
||||
- cobertura histórica
|
||||
- desde X hasta Y
|
||||
- periodo registrado
|
||||
sobre expresiones demasiado técnicas o poco naturales como el número decimal de días aislado.
|
||||
5. Simplificar el texto del fallback semanal para que comunique:
|
||||
- que se está mostrando la última semana cerrada
|
||||
- porque la semana actual aún no tiene suficiente actividad
|
||||
sin meter demasiado detalle técnico en el bloque principal
|
||||
6. Mantener la estética actual de la página histórica.
|
||||
7. No cambiar la lógica de negocio más allá de lo necesario para mostrar estados/copy correctos.
|
||||
8. No crear páginas nuevas.
|
||||
9. Al completar la implementación:
|
||||
- dejar el repositorio consistente
|
||||
- hacer commit
|
||||
- hacer push al remoto si el entorno lo permite
|
||||
|
||||
## Files to Read First
|
||||
- AGENTS.md
|
||||
- frontend/historico.html
|
||||
- frontend/assets/js/historico.js
|
||||
- frontend/assets/css/historico.css
|
||||
- backend/app/payloads.py
|
||||
- backend/README.md
|
||||
|
||||
## Expected Files to Modify
|
||||
- frontend/historico.html
|
||||
- frontend/assets/js/historico.js
|
||||
- frontend/assets/css/historico.css
|
||||
- opcionalmente backend/app/payloads.py si hace falta ajustar labels o metadatos presentables
|
||||
- opcionalmente backend/README.md si el comportamiento visible cambia y conviene dejarlo documentado
|
||||
|
||||
## Constraints
|
||||
- No romper la UI histórica que ya funciona para #01 y #02.
|
||||
- No convertir esta task en un rediseño grande.
|
||||
- No introducir frameworks nuevos.
|
||||
- No hacer cambios destructivos.
|
||||
- Mantener el trabajo centrado en estados vacíos y copy.
|
||||
|
||||
## Validation
|
||||
- `#03` deja de parecer un fallo ambiguo y muestra un estado vacío claro y honesto.
|
||||
- La cobertura histórica se presenta de forma más natural.
|
||||
- El texto del fallback semanal se entiende mejor.
|
||||
- La UI sigue siendo coherente con la landing y con el resto de la página histórica.
|
||||
- Los cambios quedan committeados y se hace push al remoto si el entorno lo permite.
|
||||
|
||||
## Change Budget
|
||||
- Preferir menos de 5 archivos modificados.
|
||||
- Preferir menos de 220 líneas cambiadas.
|
||||
Reference in New Issue
Block a user