Document RCON data capability audit
This commit is contained in:
devRaGonSa
@@ -71,5 +71,6 @@ Community website repository with a static landing in the current phase and a pl
|
||||
- The validated discovery for those historical sources is documented in `docs/historical-crcon-source-discovery.md`.
|
||||
- The persisted historical domain model for CRCON matches, players and ingestion runs is documented in `docs/historical-domain-model.md`.
|
||||
- The V1 monthly MVP scoring proposal for persisted historical player metrics is documented in `docs/monthly-mvp-ranking-scoring-design.md`.
|
||||
- The audited boundary between direct live RCON and future event-driven RCON metrics is documented in `docs/rcon-data-capability-audit.md`.
|
||||
- Frontend data consumption should remain progressive, endpoint by endpoint, with static fallbacks preserved during migration.
|
||||
- The frontend integration strategy is documented in `docs/frontend-data-consumption-plan.md`.
|
||||
|
||||
108
ai/tasks/done/TASK-074-rcon-data-capability-audit.md
Normal file
108
ai/tasks/done/TASK-074-rcon-data-capability-audit.md
Normal file
@@ -0,0 +1,108 @@
|
||||
# TASK-074-rcon-data-capability-audit
|
||||
|
||||
## Goal
|
||||
Auditar con precisión qué datos reales pueden obtenerse hoy mediante RCON en el proyecto, qué datos requieren captura de eventos o logs, y qué métricas serían viables para una futura V2 del ranking MVP.
|
||||
|
||||
## Context
|
||||
La integración live con RCON ya está funcionando en producción-like mode para el panel actual de servidores. Antes de evolucionar el sistema MVP mensual con métricas avanzadas, necesitamos saber con exactitud qué superficie de datos expone RCON realmente.
|
||||
|
||||
Es importante no confundir:
|
||||
- RCON puro
|
||||
- CRCON / scoreboard público
|
||||
- agregados históricos tipo HLL Records
|
||||
|
||||
Algunas métricas deseadas para una futura V2 podrían incluir:
|
||||
- kills por tipo de arma
|
||||
- distinción de artillery / tank / infantry
|
||||
- killer -> victim
|
||||
- most_killed
|
||||
- death_by
|
||||
- teamkills por evento
|
||||
- garrisons / OPs destruidos
|
||||
- otras señales tácticas
|
||||
|
||||
Pero todavía no sabemos cuáles salen realmente de RCON directo y cuáles requerirían una canalización propia de eventos o persistencia adicional.
|
||||
|
||||
## Steps
|
||||
1. Revisar la implementación actual del proveedor RCON:
|
||||
- backend/app/rcon_client.py
|
||||
- backend/app/providers/rcon_provider.py
|
||||
- backend/app/data_sources.py
|
||||
2. Auditar qué comandos/capacidades reales expone hoy el cliente RCON implementado.
|
||||
3. Verificar qué datos live pueden obtenerse ya de forma directa:
|
||||
- estado de servidor
|
||||
- jugadores
|
||||
- scoreboard actual
|
||||
- mapa
|
||||
- equipos
|
||||
- cualquier otro campo ya expuesto
|
||||
4. Investigar si la superficie RCON actual o el protocolo disponible permiten acceder a:
|
||||
- kills por arma
|
||||
- killer/victim
|
||||
- death_by
|
||||
- most_killed
|
||||
- teamkills
|
||||
- artillery/tank distinctions
|
||||
- garrisons / OPs destruidos
|
||||
- otras métricas tácticas útiles
|
||||
5. Separar claramente para cada métrica:
|
||||
- disponible por RCON directo hoy
|
||||
- disponible solo si se captura un flujo de eventos/logs
|
||||
- no confirmada
|
||||
- no disponible
|
||||
6. Documentar qué métricas podrían alimentar una V2 del ranking MVP y bajo qué condiciones.
|
||||
7. Aclarar qué parte requeriría:
|
||||
- ampliar el cliente RCON
|
||||
- capturar eventos
|
||||
- persistir nuevo histórico
|
||||
- agregar métricas propias
|
||||
8. No implementar todavía nuevas tablas, nuevas rutas, nuevas métricas visibles ni cambios de scoring.
|
||||
9. Al completar la implementación:
|
||||
- dejar el repositorio consistente
|
||||
- hacer commit
|
||||
- hacer push al remoto si el entorno lo permite
|
||||
|
||||
## Files to Read First
|
||||
- AGENTS.md
|
||||
- ai/repo-context.md
|
||||
- ai/architecture-index.md
|
||||
- backend/README.md
|
||||
- backend/app/rcon_client.py
|
||||
- backend/app/providers/rcon_provider.py
|
||||
- backend/app/data_sources.py
|
||||
- backend/app/payloads.py
|
||||
- docs/monthly-player-ranking-data-audit.md
|
||||
- docs/monthly-mvp-ranking-scoring-design.md
|
||||
|
||||
## Expected Files to Modify
|
||||
- docs/rcon-data-capability-audit.md
|
||||
- opcionalmente ai/architecture-index.md si conviene enlazar la auditoría
|
||||
- opcionalmente docs/decisions.md si surge una decisión técnica clara sobre el alcance de RCON para V2
|
||||
|
||||
## Constraints
|
||||
- No implementar todavía la V2 del MVP.
|
||||
- No tocar producto visible.
|
||||
- No confundir CRCON/source pública con RCON puro.
|
||||
- No hacer cambios destructivos.
|
||||
- Mantener el trabajo centrado en discovery técnico y viabilidad de métricas.
|
||||
|
||||
## Validation
|
||||
- Existe un documento claro que explica qué datos reales se pueden obtener hoy por RCON.
|
||||
- Queda claro qué métricas requerirían eventos/logs o persistencia adicional.
|
||||
- Queda claro qué subset de métricas sería viable para una futura V2 del MVP.
|
||||
- Los cambios quedan committeados y se hace push si el entorno lo permite.
|
||||
|
||||
## Change Budget
|
||||
- Preferir menos de 4 archivos modificados o creados.
|
||||
- Preferir menos de 220 líneas cambiadas.
|
||||
|
||||
## Outcome
|
||||
- Se documentó `docs/rcon-data-capability-audit.md` con el alcance real de RCON en la repo, separando RCON directo, CRCON público y métricas que requerirían pipeline de eventos/logs.
|
||||
- La auditoría deja confirmado que la integración RCON operativa hoy solo cubre estado live basado en `ServerConnect`, `Login` y `GetServerInformation`.
|
||||
- Quedó explícito que el proveedor histórico `rcon` sigue siendo un placeholder no operativo y que las métricas avanzadas para un MVP V2 no salen hoy de RCON directo en esta repo.
|
||||
- `ai/architecture-index.md` enlaza ahora la nueva auditoría para mantener visible ese límite arquitectónico.
|
||||
|
||||
## Validation Notes
|
||||
- Revisión de código completada sobre `backend/app/rcon_client.py`, `backend/app/providers/rcon_provider.py`, `backend/app/data_sources.py` y `backend/app/payloads.py`.
|
||||
- La auditoría se mantuvo dentro del alcance documental: no se añadieron tablas, rutas ni cambios visibles de producto.
|
||||
- La evidencia del repositorio sigue separando correctamente live por RCON frente a histórico por CRCON / scoreboard público.
|
||||
191
docs/rcon-data-capability-audit.md
Normal file
191
docs/rcon-data-capability-audit.md
Normal file
@@ -0,0 +1,191 @@
|
||||
# RCON Data Capability Audit
|
||||
|
||||
## Validation Date
|
||||
|
||||
- 2026-03-24
|
||||
|
||||
## Scope
|
||||
|
||||
Auditoria tecnica del alcance real de RCON en esta repo, separando con claridad:
|
||||
|
||||
- RCON directo implementado hoy en el backend
|
||||
- historico CRCON / scoreboard publico
|
||||
- metricas que solo serian posibles con captura propia de eventos o logs
|
||||
|
||||
No se implementa ninguna tabla, ruta, scoring ni captura adicional.
|
||||
|
||||
## Evidence Reviewed
|
||||
|
||||
- `backend/app/rcon_client.py`
|
||||
- `backend/app/providers/rcon_provider.py`
|
||||
- `backend/app/data_sources.py`
|
||||
- `backend/app/payloads.py`
|
||||
- `backend/README.md`
|
||||
- `docs/historical-crcon-source-discovery.md`
|
||||
- `docs/monthly-player-ranking-data-audit.md`
|
||||
- `docs/monthly-mvp-ranking-scoring-design.md`
|
||||
|
||||
## Current RCON Surface In This Repository
|
||||
|
||||
La implementacion RCON actual es minima y solo cubre estado live.
|
||||
|
||||
Capacidades confirmadas en codigo hoy:
|
||||
|
||||
- handshake `ServerConnect`
|
||||
- autenticacion `Login`
|
||||
- consulta `GetServerInformation`
|
||||
|
||||
No hay evidencia en la repo de otros comandos RCON ya integrados para:
|
||||
|
||||
- eventos de kill
|
||||
- detalle por arma
|
||||
- relaciones killer -> victim
|
||||
- teamkills por evento
|
||||
- destruccion de garrisons u OPs
|
||||
- historico de partidas cerradas
|
||||
|
||||
## What The Current Live Provider Exposes Today
|
||||
|
||||
El proveedor `RconLiveDataSource` solo normaliza estos campos para `/api/servers`:
|
||||
|
||||
- `external_server_id`
|
||||
- `server_name`
|
||||
- `status`
|
||||
- `players`
|
||||
- `max_players`
|
||||
- `current_map`
|
||||
- `region`
|
||||
- `source_name`
|
||||
- `snapshot_origin`
|
||||
- `source_ref`
|
||||
|
||||
Esto significa que RCON directo hoy ya alimenta de forma confirmada:
|
||||
|
||||
- disponibilidad online del servidor
|
||||
- nombre del servidor
|
||||
- numero de jugadores actual
|
||||
- capacidad maxima
|
||||
- mapa actual
|
||||
- metadata de procedencia del snapshot
|
||||
|
||||
## Data That Is Not Exposed By Direct RCON Today
|
||||
|
||||
Aunque la task pide revisar equipos, scoreboard actual y otros campos live, la
|
||||
repo no confirma que el proveedor actual los este devolviendo hoy.
|
||||
|
||||
No quedan expuestos en el snapshot live actual:
|
||||
|
||||
- composicion por equipos
|
||||
- scoreboard de jugadores en tiempo real
|
||||
- kills por jugador en la partida en curso
|
||||
- deaths por jugador en la partida en curso
|
||||
- support/combat/offense/defense live
|
||||
- teamkills live
|
||||
|
||||
Importante:
|
||||
|
||||
- esto no prueba que el protocolo HLL RCON no pueda ofrecer mas cosas
|
||||
- solo prueba que la implementacion actual de esta repo no las consulta ni las
|
||||
serializa
|
||||
|
||||
## Historical Boundary
|
||||
|
||||
La separacion entre live e historico queda clara en la repo:
|
||||
|
||||
- `get_live_data_source()` puede resolver `rcon`
|
||||
- `get_historical_data_source()` devuelve un placeholder `RconHistoricalDataSource`
|
||||
- ese proveedor historico lanza `RuntimeError("Historical RCON provider is not implemented yet.")`
|
||||
|
||||
Conclusion operativa:
|
||||
|
||||
- RCON esta operativo hoy para estado live de `/api/servers`
|
||||
- RCON no esta operativo hoy para ingesta historica
|
||||
- el historico reutilizable del proyecto sigue viniendo de CRCON / scoreboard publico
|
||||
|
||||
## Capability Matrix For Future MVP V2 Metrics
|
||||
|
||||
| Metrica / senal | RCON directo hoy en esta repo | Requeriria eventos/logs + persistencia | Estado actual |
|
||||
| --- | --- | --- | --- |
|
||||
| Estado del servidor | Si | No | Disponible |
|
||||
| Jugadores actuales totales | Si | No | Disponible |
|
||||
| Capacidad maxima | Si | No | Disponible |
|
||||
| Mapa actual | Si | No | Disponible |
|
||||
| Equipos live | No confirmado | Posiblemente no, depende de ampliar cliente | No expuesto hoy |
|
||||
| Scoreboard live por jugador | No confirmado | Posiblemente no, depende de ampliar cliente | No expuesto hoy |
|
||||
| Kills por arma | No | Si | Requiere pipeline nuevo |
|
||||
| Distincion artillery / tank / infantry | No | Si | Requiere pipeline nuevo |
|
||||
| Killer -> victim | No | Si | Requiere pipeline nuevo |
|
||||
| `most_killed` | No | Si | Requiere pipeline nuevo |
|
||||
| `death_by` | No | Si | Requiere pipeline nuevo |
|
||||
| Teamkills por evento | No | Si | Requiere pipeline nuevo |
|
||||
| Teamkills agregados por partida/mes | No desde RCON actual | Si | Requiere pipeline nuevo |
|
||||
| Garrisons destruidos | No confirmado | Si como minimo | No confirmado |
|
||||
| OPs destruidos | No confirmado | Si como minimo | No confirmado |
|
||||
| Otras metricas tacticas finas | No | Si | Requiere pipeline nuevo |
|
||||
| Partidas cerradas historicas | No | Si | No disponible hoy via RCON |
|
||||
|
||||
## What Can Feed An MVP V2 From RCON
|
||||
|
||||
Subset viable usando solo RCON directo ya implementado:
|
||||
|
||||
- ninguno de los componentes avanzados de scoring MVP
|
||||
- solo datos de presencia live del servidor, utiles para panel operativo pero no
|
||||
para ranking mensual
|
||||
|
||||
Subset viable si se amplia solo el cliente RCON pero sin pipeline historico:
|
||||
|
||||
- quiza mas detalle live si el protocolo ofrece comandos adicionales
|
||||
- aun asi no bastaria para un ranking mensual auditable, porque faltaria
|
||||
persistencia por evento o por partida cerrada
|
||||
|
||||
Subset viable si se construye una linea nueva de eventos/logs RCON:
|
||||
|
||||
- kills por arma
|
||||
- killer/victim
|
||||
- teamkills por evento
|
||||
- clasificacion artillery/tank/infantry
|
||||
- senales tacticas si el origen real las emite
|
||||
|
||||
Condiciones minimas para que eso sirva a un MVP V2:
|
||||
|
||||
- ampliar el cliente RCON con comandos o feeds adicionales reales
|
||||
- capturar eventos de forma continua fuera del request path HTTP
|
||||
- persistir historico propio por partida, jugador y evento
|
||||
- definir agregados reproducibles para mes y servidor
|
||||
|
||||
## Separation From CRCON / Public Scoreboard
|
||||
|
||||
La repo ya confirma que ciertas metricas avanzadas existen en CRCON publico,
|
||||
pero eso no debe confundirse con RCON directo.
|
||||
|
||||
La evidencia actual de CRCON/scoreboard publico incluye campos como:
|
||||
|
||||
- `kills_by_type`
|
||||
- `most_killed`
|
||||
- `death_by`
|
||||
- `weapons`
|
||||
- `death_by_weapons`
|
||||
|
||||
Eso pertenece al historico JSON publico ya documentado y no a la superficie
|
||||
RCON hoy implementada en `rcon_client.py`.
|
||||
|
||||
## Practical Conclusion
|
||||
|
||||
Para esta repo, la respuesta precisa hoy es:
|
||||
|
||||
- RCON directo sirve para estado live de servidores
|
||||
- RCON directo no sirve todavia para alimentar un MVP mensual V2
|
||||
- cualquier MVP V2 con armas, duelos, teamkills por evento o tacticas requiere
|
||||
una canalizacion nueva de eventos/logs y persistencia historica propia
|
||||
- garrisons y OPs siguen sin evidencia confirmada en la repo como metrica
|
||||
disponible por RCON
|
||||
|
||||
## Recommended Next Step
|
||||
|
||||
Antes de disenar scoring V2 sobre RCON, la siguiente decision tecnica correcta
|
||||
seria una task separada de discovery para definir:
|
||||
|
||||
- si el origen RCON real del servidor expone mas comandos aparte de `GetServerInformation`
|
||||
- si existe flujo de eventos reutilizable
|
||||
- que granularidad y frecuencia tendria la persistencia de esos eventos
|
||||
- que subset minimo merece convertirse en modelo historico propio
|
||||
Reference in New Issue
Block a user