Complete historical coverage and UI review tasks

ai/tasks/done/TASK-033-historical-full-bootstrap-and-coverage-validation.md

@@ -0,0 +1,72 @@
+# TASK-033-historical-full-bootstrap-and-coverage-validation
+
+## Goal
+Ejecutar y consolidar una carga histórica completa real para los 2 servidores de la comunidad, validando la cobertura temporal y cuantitativa del histórico persistido para asegurar que la base histórica sea suficientemente representativa antes de seguir refinando la UI y las métricas.
+
+## Context
+La capa histórica ya existe y funciona, pero el estado actual del proyecto indica que el histórico persistido parece insuficiente para representar con credibilidad una semana completa de actividad. La UI actual muestra resúmenes basados en lo que haya cargado en la base, y si la cobertura es corta puede inducir a interpretar mal el estado del histórico. Antes de seguir afinando la capa histórica, hace falta asegurar un bootstrap real y comprobar la cobertura conseguida para ambos servidores.
+
+## Steps
+1. Revisar la implementación actual de bootstrap, refresh incremental y persistencia histórica.
+2. Confirmar si el histórico actual está subpoblado por haber usado refrescos parciales, límites de páginas, validaciones locales u otras restricciones.
+3. Ejecutar o dejar implementado el flujo de bootstrap completo real para ambos servidores de la comunidad, sin limitar la carga a una ventana artificialmente corta.
+4. Persistir el histórico completo disponible desde la fuente CRCON scoreboard JSON para ambos servidores.
+5. Verificar y documentar, por servidor:
+   - número total de partidas históricas persistidas
+   - número de jugadores únicos
+   - rango temporal cubierto
+   - fecha/hora de primera partida persistida
+   - fecha/hora de última partida persistida
+6. Validar que la persistencia sigue siendo idempotente tras el bootstrap completo.
+7. Detectar si hay límites reales de origen (por ejemplo, datos antiguos no disponibles ya en la fuente) y documentarlos claramente.
+8. Revisar si hace falta ajustar el flujo bootstrap para que sea operativamente reproducible y comprensible.
+9. Documentar el estado real de cobertura alcanzado tras este bootstrap.
+10. No crear todavía UI histórica nueva en esta task.
+11. 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
+- ai/repo-context.md
+- ai/architecture-index.md
+- docs/historical-crcon-source-discovery.md
+- docs/historical-domain-model.md
+- docs/historical-data-quality-notes.md
+- backend/README.md
+- backend/app/config.py
+- backend/app/historical_ingestion.py
+- backend/app/historical_storage.py
+- backend/app/historical_models.py
+- backend/app/routes.py
+- backend/app/payloads.py
+
+## Expected Files to Modify
+- backend/README.md
+- backend/app/historical_ingestion.py
+- backend/app/historical_storage.py
+- backend/app/config.py
+- opcionalmente nuevos módulos auxiliares si son necesarios para consolidar bootstrap y validación de cobertura
+- un documento técnico nuevo o actualizado, por ejemplo:
+  - docs/historical-coverage-report.md
+  - docs/historical-data-quality-notes.md
+
+## Constraints
+- No basar el histórico en A2S.
+- No crear UI histórica nueva en esta task.
+- No depender del HTML público de `/games` como fuente final.
+- No romper el flujo actual de live status.
+- No hacer cambios destructivos.
+- Mantener el trabajo centrado en bootstrap completo, cobertura e idempotencia.
+
+## Validation
+- Existe un bootstrap histórico completo real para ambos servidores.
+- La cobertura histórica real queda medida y documentada.
+- El histórico persistido contiene un volumen y rango temporal coherentes con la disponibilidad real de la fuente.
+- La persistencia sigue siendo idempotente.
+- Los cambios quedan committeados y se hace push al remoto si el entorno lo permite.
+
+## Change Budget
+- Preferir menos de 7 archivos modificados o creados.
+- Preferir menos de 260 líneas cambiadas.

ai/tasks/done/TASK-034-historical-summary-semantics-and-coverage-badging.md

@@ -0,0 +1,78 @@
+# TASK-034-historical-summary-semantics-and-coverage-badging
+
+## Goal
+Corregir la semántica del resumen histórico y de los indicadores visibles para que la UI y la API distingan claramente entre cobertura histórica importada y ventana temporal semanal, evitando interpretaciones erróneas como asumir que un número bajo de partidas representa una semana completa de actividad.
+
+## Context
+La UI histórica actual puede llevar a confusión porque el usuario puede interpretar ciertos resúmenes como si describieran una semana completa, cuando en realidad reflejan solo la cobertura actualmente persistida en base. Aunque el ranking semanal y el resumen de servidor son conceptos distintos, hoy esa diferencia no queda visual ni semánticamente lo bastante clara.
+
+## Steps
+1. Revisar el payload y la lógica actual del resumen histórico por servidor.
+2. Revisar qué información muestra hoy la UI histórica sobre:
+   - cobertura temporal
+   - número de partidas
+   - rango de fechas
+   - ranking semanal
+3. Definir una semántica clara para distinguir:
+   - cobertura histórica importada
+   - ventana semanal usada para rankings
+   - resumen agregado del servidor
+4. Ajustar el backend para exponer, si hace falta, campos más claros sobre cobertura histórica real, por ejemplo:
+   - first_match_at
+   - last_match_at
+   - imported_matches_count
+   - coverage_status
+   - cualquier otro metadato útil y honesto
+5. Ajustar la UI para que el usuario entienda correctamente:
+   - qué parte es “últimos 7 días”
+   - qué parte es “cobertura total importada”
+   - cuándo la cobertura es parcial o insuficiente
+6. Eliminar formulaciones ambiguas o visualmente engañosas.
+7. Mantener la estética y coherencia de la UI histórica.
+8. No abrir todavía nuevas grandes vistas históricas.
+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
+- ai/repo-context.md
+- ai/architecture-index.md
+- docs/historical-data-quality-notes.md
+- docs/historical-coverage-report.md
+- backend/README.md
+- backend/app/routes.py
+- backend/app/payloads.py
+- backend/app/historical_storage.py
+- frontend/historico.html
+- frontend/assets/js/historico.js
+- frontend/assets/css/historico.css
+
+## Expected Files to Modify
+- backend/app/routes.py
+- backend/app/payloads.py
+- backend/app/historical_storage.py
+- frontend/historico.html
+- frontend/assets/js/historico.js
+- frontend/assets/css/historico.css
+- opcionalmente backend/README.md o documentación técnica mínima si hace falta reflejar la nueva semántica
+
+## Constraints
+- No crear páginas usando la URL de la comunidad.
+- No depender de HTML externo.
+- No romper la UI histórica existente.
+- No romper el ranking semanal.
+- No hacer cambios destructivos.
+- Mantener el trabajo centrado en claridad semántica, payload y UI.
+
+## Validation
+- La UI ya no induce a interpretar mal la cobertura histórica.
+- Queda clara la diferencia entre cobertura importada y ranking de la última semana.
+- El resumen del servidor es más honesto y comprensible.
+- El backend expone metadatos suficientes para soportar esa claridad.
+- 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 220 líneas cambiadas.

ai/tasks/done/TASK-035-historical-ui-after-bootstrap-review.md

@@ -0,0 +1,71 @@
+# TASK-035-historical-ui-after-bootstrap-review
+
+## Goal
+Revisar y ajustar la UI histórica propia del proyecto una vez que el bootstrap histórico completo y la semántica de cobertura estén resueltos, para asegurar que el resultado final sea visualmente claro, útil y coherente con el resto del producto.
+
+## Context
+La UI histórica ya existe, pero fue construida antes de confirmar que la cobertura histórica completa estuviera realmente cargada y antes de clarificar suficientemente la semántica entre resumen y ranking semanal. Una vez el histórico esté bien poblado y la capa semántica corregida, hace falta una pasada de revisión específica sobre la experiencia visual e informativa de la página histórica.
+
+## Steps
+1. Revisar la UI histórica actual después del bootstrap completo y de los ajustes de semántica/cobertura.
+2. Validar el comportamiento visual y de contenido de:
+   - resumen de servidor
+   - ranking semanal
+   - selector de servidor
+   - estado vacío/error/carga
+   - cualquier otro bloque histórico ya presente
+3. Comprobar si el volumen real de datos cambia la lectura de la interfaz y obliga a reajustar:
+   - textos
+   - jerarquía
+   - espaciado
+   - orden de secciones
+   - presentación de métricas
+4. Corregir defectos pequeños o medianos detectados en esta revisión.
+5. Asegurar que la UI histórica:
+   - sea comprensible
+   - no sobreinterprete los datos
+   - mantenga coherencia visual con la landing
+6. No abrir todavía nuevas features históricas grandes en esta task.
+7. 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
+- ai/repo-context.md
+- ai/architecture-index.md
+- docs/historical-data-quality-notes.md
+- docs/historical-coverage-report.md
+- backend/app/routes.py
+- backend/app/payloads.py
+- frontend/historico.html
+- frontend/assets/js/historico.js
+- frontend/assets/css/historico.css
+- frontend/index.html
+- frontend/assets/css/styles.css
+
+## Expected Files to Modify
+- frontend/historico.html
+- frontend/assets/js/historico.js
+- frontend/assets/css/historico.css
+- opcionalmente frontend/index.html o frontend/assets/css/styles.css si hace falta un ajuste menor de acceso o coherencia visual
+- opcionalmente documentación mínima si algún comportamiento visible necesita quedar reflejado
+
+## Constraints
+- No crear nuevas páginas basadas en URLs externas.
+- No abrir nuevas grandes features históricas.
+- No romper la UI histórica existente.
+- No hacer cambios destructivos.
+- Mantener el trabajo centrado en revisión final, claridad y pulido después del bootstrap real.
+
+## Validation
+- La UI histórica refleja correctamente el histórico ya poblado.
+- La presentación del resumen y del ranking es clara.
+- La experiencia visual es coherente con el resto del proyecto.
+- No se detectan malentendidos graves entre cobertura histórica y ranking semanal.
+- Los cambios quedan committeados y se hace push al remoto si el entorno lo permite.
+
+## Change Budget
+- Preferir menos de 5 archivos modificados o creados.
+- Preferir menos de 200 líneas cambiadas.