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

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.