Add rcon-first elo mmr foundation

ai/tasks/done/TASK-096-rcon-first-historical-runtime-selection.md

@@ -0,0 +1,57 @@
+# TASK-096-rcon-first-historical-runtime-selection
+
+## Goal
+Hacer que el histórico backend funcione realmente en modo RCON-first en runtime, con fallback automático, observable y seguro a public-scoreboard/CRCON cuando RCON falle o no soporte una operación concreta.
+
+## Context
+Hoy la repo ya tiene:
+- live RCON-first con fallback a A2S
+- captura prospectiva RCON
+- read model histórico RCON parcial
+- histórico clásico por public-scoreboard/CRCON
+Pero el runtime histórico aún no se comporta como una política RCON-first completa.
+
+## Steps
+1. Auditar la selección histórica actual en:
+   - `backend/app/data_sources.py`
+   - `backend/app/payloads.py`
+   - `backend/app/historical_ingestion.py`
+   - `backend/app/historical_runner.py`
+   - `backend/app/rcon_historical_read_model.py`
+2. Introducir arbitraje histórico explícito:
+   - intento primario por RCON
+   - fallback a public-scoreboard/CRCON si:
+     - RCON falla
+     - RCON no tiene cobertura
+     - RCON no soporta esa operación concreta
+3. Asegurar trazabilidad en payloads:
+   - `primary_source`
+   - `selected_source`
+   - `fallback_used`
+   - `fallback_reason`
+   - `source_attempts`
+4. Ajustar el runtime y los defaults para que la política efectiva del stack sea coherente con histórico RCON-first.
+5. Mantener compatibilidad con el histórico clásico sin romper snapshots ni workers existentes.
+6. Actualizar `backend/README.md` y runbook para que el comportamiento real quede claro.
+
+## Constraints
+- No romper live RCON-first ya existente.
+- No eliminar public-scoreboard/CRCON.
+- No degradar el request path HTTP en latencia o estabilidad de forma evitable.
+- No fingir soporte RCON en operaciones que todavía no están cubiertas.
+
+## Validation
+- `/health` y/o la metadata funcional relevante reflejan una política histórica RCON-first coherente.
+- Los endpoints históricos compatibles intentan RCON primero.
+- Cuando RCON no sirve, el fallback a public-scoreboard/CRCON es observable y claro.
+- La repo queda consistente.
+
+## Expected Files
+- `backend/app/data_sources.py`
+- `backend/app/payloads.py`
+- `backend/app/historical_ingestion.py`
+- `backend/app/historical_runner.py`
+- `backend/app/rcon_historical_read_model.py`
+- `backend/app/config.py`
+- `backend/README.md`
+- `docker-compose.yml` si hace falta

ai/tasks/done/TASK-097-elo-mmr-capabilities-and-data-contract.md

@@ -0,0 +1,65 @@
+# TASK-097-elo-mmr-capabilities-and-data-contract
+
+## Goal
+Definir e implementar la base de contrato de datos, capabilities y storage para un sistema de MMR persistente + MonthlyRankScore mensual inspirado en `sistema_elo_mensual_hll.pdf`, adaptado a la telemetría real disponible hoy.
+
+## Context
+El PDF define una arquitectura con:
+- MMR persistente
+- ranking mensual visible
+- calidad de match
+- subíndices por rol
+- ImpactScore
+- MatchScore
+- MonthlyRankScore
+Pero la repo actual no dispone de todas las métricas del documento con precisión total.
+
+Hace falta una base sólida que no mezcle:
+- lo que el PDF ideal propone
+- lo que hoy se puede calcular de verdad
+
+## Steps
+1. Leer el PDF `sistema_elo_mensual_hll.pdf` y descomponerlo en:
+   - inputs obligatorios
+   - inputs opcionales
+   - inputs no disponibles todavía
+2. Auditar las fuentes reales actuales:
+   - live RCON
+   - read model histórico RCON
+   - player-event V2
+   - histórico clásico CRCON/public-scoreboard
+3. Crear una especificación operativa dentro del repo para el sistema Elo/MMR:
+   - qué campos existen
+   - cuáles son exactos
+   - cuáles son aproximados
+   - cuáles no están disponibles
+4. Diseñar e implementar storage mínimo para:
+   - snapshots o checkpoints mensuales de rating
+   - MMR persistente por jugador
+   - MatchScore / impacto por match cuando proceda
+   - metadata de capabilities por cálculo
+5. Dejar una capa de contrato o modelos Python claros para:
+   - match validity
+   - quality factor Q
+   - role bucket
+   - subindices
+   - monthly eligibility
+   - penalties
+6. No cerrar todavía las fórmulas finales si falta señal; primero dejar bien cerrada la base de datos y contrato semántico.
+
+## Constraints
+- No inventar métricas inexistentes.
+- No mezclar cálculo final con datos no soportados.
+- No romper MVP V1/V2 actuales.
+- La documentación debe dejar cristalino qué parte del PDF está soportada hoy y cuál no.
+
+## Validation
+- Existe documentación técnica concreta de capabilities del sistema Elo/MMR.
+- Existen modelos/contratos/backend storage listos para cálculo incremental.
+- La repo deja clara la diferencia entre exacto, aproximado y no disponible.
+- La repo queda consistente.
+
+## Expected Files
+- `docs/elo-mmr-monthly-ranking-design.md`
+- uno o varios archivos nuevos bajo `backend/app/` para modelos/contratos/storage Elo
+- `backend/README.md`

ai/tasks/done/TASK-098-elo-mmr-core-engine-v1-backed-by-real-signals.md

@@ -0,0 +1,67 @@
+# TASK-098-elo-mmr-core-engine-v1-backed-by-real-signals
+
+## Goal
+Implementar una primera versión operativa del motor de MMR persistente + MonthlyRankScore mensual usando únicamente señales reales o aproximaciones justificadas por la telemetría disponible hoy.
+
+## Context
+Esta task debe apoyarse en la especificación y capabilities de la task anterior.
+
+La implementación debe seguir el espíritu del PDF:
+- validar matches
+- factor de calidad Q
+- OutcomeScore
+- ImpactScore por rol
+- DeltaMMR
+- MatchScore
+- MonthlyRankScore
+Pero sin fingir precisión donde no existe.
+
+## Steps
+1. Implementar la validación de partida y el factor de calidad Q con las señales disponibles reales.
+2. Implementar la lógica de bucket mínima viable:
+   - rol principal
+   - modo si está disponible
+   - tramo de duración
+3. Implementar los subíndices soportables hoy:
+   - OutcomeScore
+   - CombatIndex
+   - UtilityIndex cuando haya señal
+   - LeadershipIndex cuando haya señal
+   - DisciplineIndex con teamkills / abandonos / AFK si la fuente real lo permite
+   - ObjectiveIndex exacto o aproximado solo si está realmente soportado
+4. Implementar `ImpactScore` con pesos por rol inspirados en el PDF.
+5. Implementar actualización de `MMR` persistente.
+6. Implementar `MatchScore` mensual.
+7. Implementar agregación mensual de `MonthlyRankScore` con:
+   - Confidence
+   - Activity
+   - Consistency
+   - StrengthOfSchedule
+   - PenaltyPoints
+8. Marcar explícitamente en el resultado de cada cálculo:
+   - qué partes se calcularon con señal exacta
+   - qué partes fueron aproximadas
+   - qué partes quedaron no disponibles
+9. Exponer una API o endpoints internos/backend claros para consultar:
+   - rating persistente del jugador
+   - leaderboard mensual Elo/MMR
+   - metadata de cálculo/capabilities
+10. Mantener MVP V1/V2 existentes sin romperse.
+
+## Constraints
+- No vender esta V1 del motor como “idéntica al PDF” si hay aproximaciones.
+- No usar valores mágicos sin documentarlos.
+- No romper endpoints históricos actuales.
+- No rehacer toda la UI en esta task.
+
+## Validation
+- Existe cálculo persistente de MMR para jugadores soportados.
+- Existe cálculo mensual visible de ranking/score.
+- El resultado expone metadata de exactitud/aproximación.
+- La repo queda consistente.
+- La documentación queda alineada con lo realmente implementado.
+
+## Expected Files
+- archivos backend nuevos o modificados bajo `backend/app/` para engine/storage/routes/payloads Elo
+- `backend/README.md`
+- `docs/elo-mmr-monthly-ranking-design.md`

ai/tasks/done/TASK-099-elo-mmr-product-exposure-and-ui-minimal.md

@@ -0,0 +1,46 @@
+# TASK-099-elo-mmr-product-exposure-and-ui-minimal
+
+## Goal
+Exponer de forma mínima y útil en producto el nuevo sistema de rating/MMR mensual sin romper el histórico actual ni mezclarlo de forma confusa con MVP V1/V2.
+
+## Context
+Una vez exista el motor base, hace falta hacer visible el sistema:
+- leaderboard mensual Elo/MMR
+- score visible del mes
+- rating persistente o skill score
+- metadata suficiente para no confundir al usuario
+
+## Steps
+1. Auditar la UI histórica actual y decidir el punto de exposición mínimo más claro.
+2. Añadir un bloque o vista mínima para:
+   - rating persistente
+   - score mensual
+   - elegibilidad mensual
+   - indicación básica de si el cálculo es exacto / aproximado / parcial
+3. Mantener separación clara respecto a:
+   - MVP V1
+   - MVP V2
+   - player-events V2
+4. No saturar la UI.
+5. Si procede, añadir copy/tooltip/legend breve explicando:
+   - que el sistema prioriza señales reales
+   - que algunas métricas avanzadas pueden estar en modo parcial según cobertura
+6. Validar que los enlaces/histórico existentes no se rompen.
+
+## Constraints
+- No rehacer toda la página histórica.
+- No borrar MVP V1/V2.
+- No esconder la naturaleza parcial si el cálculo aún no es completo.
+- Mantener UX legible y estable.
+
+## Validation
+- El sistema Elo/MMR aparece en producto de forma entendible.
+- No rompe bloques existentes.
+- La UI deja claro qué representa cada score.
+- La repo queda consistente.
+
+## Expected Files
+- `frontend/historico.html`
+- `frontend/assets/js/historico.js`
+- `frontend/assets/css/historico.css`
+- backend solo si hace falta ajustar payloads expuestos