comunidadhll/ai/tasks/done/TASK-088-rcon-historical-ingestion-feasibility.md

TASK-088-rcon-historical-ingestion-feasibility

Goal

Aterrizar con precision si la repo puede soportar una ingesta historica por RCON y, en caso afirmativo, definir una arquitectura minima, incremental y defendible sin asumir capacidades que hoy no estan probadas.

Context

La repo ya tiene:

• proveedor live por RCON
• seleccion de historical_data_source
• placeholder RconHistoricalDataSource

Pero todavia no existe una implementacion historica real por RCON. Antes de abrir trabajo de implementacion, hace falta una auditoria tecnica que determine:

• que datos puede dar realmente el cliente RCON actual
• si permiten reconstruccion historica, solo captura prospectiva o solo telemetria parcial
• que huecos deben mantenerse temporalmente en public-scoreboard
• que contrato minimo puede exponerse sin vender capacidades inexistentes

Steps

1. Revisar la capa actual de seleccion de proveedores y el adapter RCON existente.
2. Auditar el cliente RCON y documentar exactamente:
   • comandos soportados hoy
   • forma del payload disponible hoy
   • frecuencia de captura razonable
   • si hay o no base para historico real de partidas cerradas
3. Redactar una decision tecnica clara con una de estas salidas:
   • no viable con el cliente actual
   • viable solo para captura prospectiva
   • viable para una capa historica parcial
4. Diseñar la arquitectura minima recomendada:
   • almacenamiento
   • workers
   • checkpoints
   • compatibilidad con public-scoreboard
   • politica de degradacion si faltan metricas
5. Dejar una propuesta de fases realista:
   • fase 1: captura prospectiva
   • fase 2: lectura operativa minima
   • fase 3: metricas competitivas si la senal lo permite
6. Actualizar README para reflejar el estado real y evitar ambiguedad sobre “historico por RCON”.

Files to Read First

• backend/README.md
• backend/app/data_sources.py
• backend/app/providers/rcon_provider.py
• backend/app/rcon_client.py
• backend/app/historical_ingestion.py
• backend/app/historical_storage.py
• backend/app/player_event_worker.py
• backend/app/player_event_storage.py

Expected Files to Modify

• docs/rcon-historical-ingestion-design.md
• backend/README.md

Constraints

• No implementar aun la ingesta historica por RCON.
• No cambiar runtime behavior del backend.
• No tocar frontend.
• No asumir que RCON resuelve backfill retroactivo si eso no esta demostrado.
• Mantener el documento muy concreto y util para una implementacion posterior.

Validation

• Existe un documento de diseno con conclusion clara.
• El README deja claro que parte esta implementada y cual no.
• No se introducen cambios de comportamiento en produccion o desarrollo.
• El repositorio queda consistente.

Change Budget

• Preferir menos de 3 archivos modificados o creados.
• Preferir menos de 220 lineas cambiadas.