71 lines
2.8 KiB
Markdown
71 lines
2.8 KiB
Markdown
# 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.
|