Promote rcon historical model to primary

ai/tasks/done/TASK-102-rcon-historical-competitive-read-model-primary.md

@@ -0,0 +1,54 @@
+# TASK-102-rcon-historical-competitive-read-model-primary
+
+## Goal
+Construir una capa histórica competitiva primaria basada en persistencia RCON, o en una materialización derivada de ella, suficiente para soportar el producto histórico sin depender de public-scoreboard como writer principal.
+
+## Context
+Hoy la repo ya tiene:
+- captura histórica prospectiva RCON
+- read model histórico RCON mínimo
+- histórico clásico por public-scoreboard
+- player-events V2
+- Elo/MMR mensual
+Pero el writer path histórico competitivo sigue dependiendo del archivo clásico importado por scoreboard.
+
+## Steps
+1. Auditar:
+   - `backend/app/rcon_historical_storage.py`
+   - `backend/app/rcon_historical_read_model.py`
+   - `backend/app/historical_storage.py`
+   - `backend/app/player_event_storage.py`
+   - `backend/app/elo_mmr_storage.py`
+   - `backend/app/payloads.py`
+2. Definir un modelo primario histórico competitivo RCON-backed:
+   - directo sobre persistencia RCON, o
+   - mediante tablas/materializaciones derivadas generadas desde RCON
+3. Ese modelo debe cubrir como prioridad:
+   - recent activity / recent matches
+   - historical server summary
+   - métricas mínimas competitivas reutilizables por MVP/Elo
+4. Si hacen falta tablas/materialized snapshots nuevas, crearlas.
+5. Dejar capabilities explícitas por dominio:
+   - exact
+   - approximate
+   - partial
+   - unavailable
+6. Documentar claramente qué parte del histórico ya puede dejar de depender del import clásico.
+7. Mantener scoreboard como fallback solo para lo que todavía no esté cubierto.
+
+## Constraints
+- No romper la persistencia RCON ya existente.
+- No eliminar el histórico clásico todavía.
+- No inventar granularidad que la captura RCON no tenga.
+- No degradar el request path HTTP innecesariamente.
+
+## Validation
+- Existe una capa histórica competitiva primaria RCON-backed real.
+- Al menos summary/recent activity dejan de depender del pipeline clásico como principal.
+- Las capabilities quedan visibles y honestas.
+- La repo queda consistente.
+
+## Expected Files
+- archivos backend nuevos o modificados bajo `backend/app/` para read model/materialización histórica RCON
+- `docs/elo-mmr-monthly-ranking-design.md` si hace falta
+- `backend/README.md`

ai/tasks/done/TASK-103-rcon-first-historical-aggregates-and-fallback-boundary.md

@@ -0,0 +1,51 @@
+# TASK-103-rcon-first-historical-aggregates-and-fallback-boundary
+
+## Goal
+Mover los agregados históricos de producto a una frontera RCON-first real, dejando scoreboard solo para las piezas que todavía no puedan calcularse desde el modelo histórico competitivo RCON-backed.
+
+## Context
+Una vez exista el modelo primario histórico competitivo RCON-backed, hace falta conectar realmente los endpoints y payloads de producto para que usen esa capa como primaria.
+
+## Steps
+1. Auditar:
+   - `backend/app/payloads.py`
+   - `backend/app/routes.py`
+   - `backend/app/historical_snapshots.py`
+   - `backend/app/historical_snapshot_storage.py`
+   - `backend/app/elo_mmr_engine.py`
+2. Reorientar como RCON-first real, al menos donde la nueva capa ya lo permita:
+   - historical server summary
+   - recent matches
+   - Elo/MMR mensual
+   - y cualquier agregado competitivo mínimo ya soportado
+3. Mantener fallback a public-scoreboard solo cuando:
+   - la capability sea partial/unavailable
+   - la cobertura RCON no alcance
+   - el cálculo falle
+4. Hacer visible la frontera exacta de fallback:
+   - qué endpoints ya son realmente RCON-first
+   - cuáles siguen cayendo a scoreboard
+   - por qué
+5. Ajustar snapshots/materializaciones si hace falta para no depender del request path directo.
+6. Alinear README/runbook con esta nueva frontera funcional.
+
+## Constraints
+- No afirmar que MVP V1/V2 completos ya sean 100% RCON-backed si no lo son.
+- No romper endpoints existentes.
+- No ocultar el fallback real.
+- Mantener latencia razonable.
+
+## Validation
+- Los endpoints históricos soportados ya usan RCON-backed como primario real.
+- El fallback a scoreboard queda reducido y explícito.
+- Elo/MMR mensual consume primariamente el modelo RCON-backed donde ya sea posible.
+- La repo queda consistente.
+
+## Expected Files
+- `backend/app/payloads.py`
+- `backend/app/routes.py`
+- `backend/app/historical_snapshots.py`
+- `backend/app/historical_snapshot_storage.py`
+- `backend/app/elo_mmr_engine.py`
+- `backend/README.md`
+- otros archivos backend si hace falta

ai/tasks/done/TASK-104-landing-loading-state-and-stale-lock-hardening.md

@@ -0,0 +1,45 @@
+# TASK-104-landing-loading-state-and-stale-lock-hardening
+
+## Goal
+Corregir dos problemas de producto/operación ya detectados:
+1. la landing muestra primero datos fake estáticos antes de hidratar
+2. los stale locks entre contenedores Docker siguen bloqueando pasadas manuales aunque los workers ya estén parados
+
+## Context
+Se ha confirmado que:
+- la homepage renderiza cards estáticas fake y luego las sustituye al hidratar
+- eso genera un flash de datos falsos
+- además, el lock compartido puede quedar huérfano entre contenedores y requiere borrado manual
+
+## Steps
+1. Para la landing:
+   - auditar `frontend/index.html`, `frontend/assets/js/main.js`, `frontend/assets/css/styles.css`
+   - aplicar la opción A:
+     - no mostrar cards fake iniciales
+     - dejar contenedor vacío o skeleton/loading state
+     - renderizar solo datos reales al hidratar
+     - degradar limpio si falla la API
+2. Para el stale lock:
+   - auditar `backend/app/writer_lock.py`
+   - mejorar la detección/recuperación de locks huérfanos entre contenedores Docker
+   - no depender únicamente del hostname si eso bloquea recuperación válida
+   - mantener seguridad para no liberar locks activos por error
+3. Documentar el comportamiento actualizado en README/runbook.
+
+## Constraints
+- No rehacer la landing completa.
+- No romper el single-writer lock.
+- No volver al comportamiento sin coordinación.
+- No introducir riesgo de liberar locks válidos sin comprobación suficiente.
+
+## Validation
+- La landing ya no muestra datos fake antes de hidratar.
+- Los locks huérfanos entre contenedores se recuperan mejor o quedan claramente resueltos.
+- La repo queda consistente.
+
+## Expected Files
+- `frontend/index.html`
+- `frontend/assets/js/main.js`
+- `frontend/assets/css/styles.css`
+- `backend/app/writer_lock.py`
+- `backend/README.md`