Close TASK-106 with runtime validation evidence

ai/tasks/done/TASK-106-rcon-primary-summary-and-recent-runtime-fix.md

@@ -0,0 +1,80 @@
+# TASK-106-rcon-primary-summary-and-recent-runtime-fix
+
+## Goal
+Corregir la frontera runtime para que `historical server summary` y `recent historical matches` usen realmente la capa RCON-backed como fuente primaria cuando haya cobertura suficiente, dejando `public-scoreboard` solo como fallback explicito.
+
+## Context
+Las pruebas reales iniciales del sistema habian mostrado que:
+- `build_historical_server_summary_payload(...)`
+- `build_recent_historical_matches_payload(...)`
+
+seguian devolviendo en runtime:
+- `selected_source = "public-scoreboard"`
+- `fallback_used = true`
+
+cuando el objetivo de producto era que, si existe cobertura RCON suficiente, esas rutas fueran realmente RCON-first efectivas y no solo nominales.
+
+## Scope
+Backend solamente. Sin cambios en frontend.
+
+## Steps
+1. Auditar:
+   - `backend/app/payloads.py`
+   - `backend/app/rcon_historical_read_model.py`
+   - `backend/app/rcon_historical_storage.py`
+   - `backend/app/historical_snapshots.py`
+   - `backend/app/data_sources.py`
+2. Identificar por que `summary` y `recent-matches` seguian seleccionando `public-scoreboard` en las pruebas reales.
+3. Corregir la seleccion runtime para que:
+   - si hay cobertura/capability RCON suficiente -> `selected_source = "rcon"`
+   - si no la hay -> fallback explicito a `public-scoreboard`
+4. Mantener trazabilidad clara:
+   - `primary_source`
+   - `selected_source`
+   - `fallback_used`
+   - `fallback_reason`
+   - `source_attempts`
+5. Alinear snapshots o materializaciones si hace falta para que no obliguen a caer innecesariamente al historico clasico.
+6. Actualizar README/runbook explicando la frontera exacta de summary/recent.
+
+## Constraints
+- No fingir cobertura RCON si no existe.
+- No romper endpoints existentes.
+- No eliminar `public-scoreboard` como red de seguridad.
+- No tocar frontend.
+
+## Validation
+- `historical server summary` usa RCON como primario real cuando hay cobertura.
+- `recent historical matches` usa RCON como primario real cuando hay cobertura.
+- Cuando no haya cobertura, el fallback a `public-scoreboard` sigue siendo explicito y observable.
+- La repo queda consistente.
+
+## Expected Files
+- `backend/app/payloads.py`
+- `backend/app/rcon_historical_read_model.py`
+- `backend/app/rcon_historical_storage.py`
+- `backend/app/historical_snapshots.py`
+- `backend/app/data_sources.py`
+- `backend/README.md`
+- otros archivos backend solo si son estrictamente necesarios
+
+## Outcome
+- Ya existe evidencia runtime real suficiente para considerar cumplido el objetivo funcional de la task.
+- Para `server_slug = "comunidad-hispana-01"`:
+  - `build_historical_server_summary_payload(...)` devuelve:
+    - `selected_source = "rcon"`
+    - `fallback_used = false`
+    - `summary_basis = "rcon-competitive-windows"`
+  - `build_recent_historical_matches_payload(..., limit=2)` devuelve:
+    - `selected_source = "rcon"`
+    - `fallback_used = false`
+- Esto demuestra que la frontera runtime RCON-first ya funciona con cobertura real para al menos un servidor y que `summary` y `recent-matches` ya no quedan solo en una intencion nominal.
+- El fallback a `public-scoreboard` sigue intacto y sigue siendo la degradacion correcta cuando:
+  - no hay cobertura RCON suficiente
+  - un target falla
+  - la capability concreta no puede servirse de forma fiable desde RCON
+- `comunidad-hispana-03` sigue teniendo una incidencia separada de `auth/login`, pero eso no invalida el cierre funcional de esta task porque la frontera runtime pedida aqui ya quedo validada con datos reales en al menos un servidor con cobertura.
+
+## Validation Notes
+- Cierre administrativo basado en evidencia runtime ya validada y aportada fuera de esta actualizacion.
+- No se rehacen pruebas ni se introducen cambios funcionales adicionales para este cierre.