Process historical bootstrap and leaderboard tasks

ai/tasks/done/TASK-057-server-03-historical-bootstrap-and-snapshots.md

@@ -0,0 +1,70 @@
+# TASK-057-server-03-historical-bootstrap-and-snapshots
+
+## Goal
+Cargar histórico real para `comunidad-hispana-03` desde su fuente CRCON configurada, persistirlo en la base histórica del proyecto y generar los snapshots necesarios para que la UI deje de mostrarlo como pendiente de bootstrap.
+
+## Context
+El servidor `comunidad-hispana-03` ya existe en la configuración del proyecto, pero actualmente la UI lo muestra con un estado honesto de “pendiente de histórico” porque todavía no se ha ejecutado bootstrap/backfill real para ese servidor. El objetivo de esta task es convertir ese servidor en un origen histórico real dentro del producto, dejándolo operativo igual que `#01` y `#02`.
+
+## Steps
+1. Revisar la configuración actual del servidor `comunidad-hispana-03`.
+2. Confirmar que la fuente histórica configurada sigue siendo válida y accesible.
+3. Ejecutar bootstrap/backfill real para `comunidad-hispana-03` con un enfoque operativo seguro y reanudable.
+4. Persistir en SQLite:
+   - matches
+   - players
+   - stats por match
+   - progreso/backfill
+5. Generar snapshots JSON para `comunidad-hispana-03`, al menos de:
+   - server-summary
+   - weekly-kills
+   - weekly-deaths
+   - weekly-matches-over-100-kills
+   - weekly-support
+   - recent-matches
+6. Verificar que la UI deja de mostrar el estado de “pendiente de bootstrap” si ya existe histórico real.
+7. Documentar el resultado del bootstrap de `#03`, incluyendo cobertura alcanzada si es posible.
+8. No tocar la semántica de #01, #02 ni Totales salvo lo estrictamente necesario.
+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
+- backend/README.md
+- backend/app/config.py
+- backend/app/historical_ingestion.py
+- backend/app/historical_storage.py
+- backend/app/historical_snapshots.py
+- backend/app/historical_snapshot_storage.py
+- backend/app/historical_runner.py
+- backend/app/payloads.py
+- frontend/assets/js/historico.js
+- docs/historical-coverage-report.md
+
+## Expected Files to Modify
+- backend/README.md
+- backend/app/historical_ingestion.py
+- backend/app/historical_snapshots.py
+- backend/app/historical_snapshot_storage.py
+- opcionalmente docs/historical-coverage-report.md
+- y los snapshots generados bajo:
+  - backend/data/snapshots/comunidad-hispana-03/
+
+## Constraints
+- No usar A2S para esta carga histórica.
+- No crear páginas nuevas.
+- No romper #01, #02 ni Totales.
+- No hacer cambios destructivos.
+- Mantener el trabajo centrado en dejar #03 con histórico real y snapshots útiles.
+
+## Validation
+- `comunidad-hispana-03` deja de aparecer como pendiente de bootstrap si hay histórico suficiente.
+- Existen snapshots JSON no vacíos para `#03` cuando la fuente devuelve datos.
+- El histórico bruto de `#03` queda persistido en SQLite.
+- Los cambios quedan committeados y se hace push si el entorno lo permite.
+
+## Change Budget
+- Preferir menos de 6 archivos modificados o creados, sin contar los snapshots generados.
+- Preferir menos de 240 líneas cambiadas.

ai/tasks/done/TASK-058-monthly-historical-leaderboards-api.md

@@ -0,0 +1,67 @@
+# TASK-058-monthly-historical-leaderboards-api
+
+## Goal
+Ampliar la API histórica de leaderboards para soportar una dimensión mensual además de la semanal, reutilizando las mismas métricas actuales del producto.
+
+## Context
+La página histórica ya muestra tops semanales por métrica:
+- kills
+- muertes
+- partidas con más de 100 kills
+- soporte
+
+Ahora se quiere añadir una segunda dimensión temporal: mensual. La API debe poder servir snapshots o payloads equivalentes para el periodo mensual con la misma claridad que ya existe en semanal.
+
+## Steps
+1. Revisar la implementación actual de tops semanales y su semántica temporal.
+2. Diseñar una dimensión mensual coherente para leaderboards históricos.
+3. Definir la política temporal mensual, idealmente basada en mes natural cerrado o en el mes actual si la política del proyecto lo requiere, dejándolo claro.
+4. Implementar soporte backend para leaderboards mensuales con estas métricas:
+   - kills
+   - muertes
+   - partidas con más de 100 kills
+   - soporte
+5. Asegurar que la API exponga metadatos claros del rango temporal real usado.
+6. Integrar el soporte mensual en la capa de snapshots JSON en disco.
+7. Mantener compatibilidad con la capa semanal existente.
+8. Documentar la nueva capacidad en backend.
+9. No crear todavía la pestaña visual en esta task si no es imprescindible.
+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/payloads.py
+- backend/app/routes.py
+- backend/app/historical_storage.py
+- backend/app/historical_snapshots.py
+- backend/app/historical_snapshot_storage.py
+- frontend/assets/js/historico.js
+
+## Expected Files to Modify
+- backend/app/payloads.py
+- backend/app/routes.py
+- backend/app/historical_storage.py
+- backend/app/historical_snapshots.py
+- backend/app/historical_snapshot_storage.py
+- backend/README.md
+- opcionalmente documentación técnica adicional si hace falta aclarar la política mensual
+
+## Constraints
+- No romper tops semanales existentes.
+- No usar A2S para estos tops históricos.
+- No hacer cambios destructivos.
+- Mantener el trabajo centrado en leaderboards mensuales y metadatos temporales claros.
+
+## Validation
+- Existen leaderboards mensuales para las métricas soportadas.
+- La API distingue correctamente entre semanal y mensual.
+- Los snapshots mensuales se generan y persisten correctamente.
+- Los cambios quedan committeados y se hace push si el entorno lo permite.
+
+## Change Budget
+- Preferir menos de 6 archivos modificados o creados.
+- Preferir menos de 240 líneas cambiadas.

ai/tasks/done/TASK-059-historical-leaderboards-timeframe-tabs-ui.md

@@ -0,0 +1,75 @@
+# TASK-059-historical-leaderboards-timeframe-tabs-ui
+
+## Goal
+Ampliar la sección de tops de la página histórica para permitir alternar entre rankings semanales y mensuales dentro de la misma zona visual, manteniendo también las pestañas por métrica.
+
+## Context
+La sección de tops ya tiene pestañas por métrica:
+- Top kills
+- Top muertes
+- Partidas 100+ kills
+- Soporte
+
+Ahora se quiere añadir una segunda capa de navegación temporal dentro de esa misma sección para consultar:
+- semanal
+- mensual
+
+La experiencia debe seguir siendo clara, rápida y coherente con el estilo actual de la página.
+
+## Steps
+1. Revisar la UI actual de la sección de leaderboards.
+2. Revisar la nueva API mensual y cómo convive con la semanal.
+3. Diseñar una navegación clara para el marco temporal, por ejemplo:
+   - Semanal
+   - Mensual
+4. Mantener las pestañas de métricas ya existentes dentro de ese marco temporal.
+5. Hacer que la UI pueda alternar entre:
+   - semanal + kills
+   - semanal + muertes
+   - semanal + 100+ kills
+   - semanal + soporte
+   - mensual + kills
+   - mensual + muertes
+   - mensual + 100+ kills
+   - mensual + soporte
+6. Mostrar el rango temporal real usado de forma clara y natural.
+7. Mantener estados de loading, empty y error.
+8. Mantener el rendimiento percibido razonable y compatible con la estrategia actual de snapshots.
+9. No crear una nueva página; la ampliación debe quedar dentro de la sección actual de tops.
+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
+- frontend/historico.html
+- frontend/assets/js/historico.js
+- frontend/assets/css/historico.css
+- backend/app/routes.py
+- 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 docs mínimas si cambia el contrato visible de uso
+
+## Constraints
+- No romper el flujo actual semanal.
+- No introducir frameworks nuevos.
+- No crear páginas nuevas.
+- No hacer cambios destructivos.
+- Mantener el trabajo centrado en la navegación temporal dentro de los tops.
+
+## Validation
+- La sección de tops permite alternar entre semanal y mensual.
+- Siguen funcionando las métricas actuales.
+- El rango temporal mostrado es claro.
+- La UI sigue siendo coherente con el resto de la página histórica.
+- Los cambios quedan committeados y se hace push si el entorno lo permite.
+
+## Change Budget
+- Preferir menos de 5 archivos modificados.
+- Preferir menos de 220 líneas cambiadas.