comunidadhll/docs/crcon-advanced-metrics-origin-audit.md

# CRCON Advanced Metrics Origin Audit

## Validation Date

- 2026-03-24

## Scope

Auditoria tecnica del origen probable de metricas avanzadas visibles en
ecosistemas tipo CRCON / HLL Records, separando:

- RCON directo implementado hoy en esta repo
- campos historicos ya visibles en la capa publica tipo scoreboard
- metricas que solo resultan plausibles con eventos/logs y agregacion propia

No se implementa captura nueva, tablas nuevas ni cambios de producto.

## Evidence Reviewed

- `docs/rcon-data-capability-audit.md`
- `docs/monthly-player-ranking-data-audit.md`
- `docs/historical-crcon-source-discovery.md`
- `backend/README.md`
- `backend/app/rcon_client.py`
- `backend/app/providers/rcon_provider.py`
- `backend/app/data_sources.py`

## Confirmed Boundary In This Repository

La evidencia local confirma dos superficies distintas:

- RCON live directo para estado actual del servidor
- historico CRCON / scoreboard publico para partidas cerradas y metricas ricas

El cliente RCON implementado en `backend/app/rcon_client.py` solo usa:

- `ServerConnect`
- `Login`
- `GetServerInformation`

El proveedor `RconLiveDataSource` solo convierte eso en:

- nombre del servidor
- estado online
- jugadores actuales
- capacidad maxima
- mapa actual
- metadata de procedencia del snapshot

La repo no contiene hoy evidencia de comandos RCON integrados para:

- killer -> victim
- kills por arma
- teamkills por evento
- duelos jugador contra jugador
- ledger tactico de acciones
- reconstruccion historica de partidas cerradas

## What The Historical Source Already Exposes

La discovery historica local ya documenta que el detalle CRCON / scoreboard
publico expone campos avanzados como:

- `kills_by_type`
- `most_killed`
- `death_by`
- `weapons`
- `death_by_weapons`

Ademas, `docs/monthly-player-ranking-data-audit.md` confirma que esos campos
existen en el origen, aunque la persistencia actual del proyecto todavia no los
guarda.

## Technical Interpretation

La mejor lectura tecnica basada en la repo es esta:

- RCON puro hoy solo cubre estado live operativo
- metricas como `most_killed` y `death_by` no salen del cliente RCON actual
- esas metricas ya existen en una capa historica enriquecida externa al cliente
  RCON local
- para reproducirlas dentro del proyecto haria falta una persistencia propia o
  una fuente historica equivalente que conserve eventos o agregados avanzados

Esto no demuestra por si solo el mecanismo interno exacto de CRCON o HLL
Records, pero si permite descartar algo importante: en esta repo no hay base
para afirmar que esas metricas provengan de RCON directo ya listo para usar.

## Plausible Origin Paths

### 1. Direct RCON Commands

Plausibilidad en esta repo: baja para metricas avanzadas.

Motivo:

- no hay comandos RCON avanzados integrados en codigo
- no hay provider historico RCON operativo
- `RconHistoricalDataSource` es solo un placeholder que falla con
  `Historical RCON provider is not implemented yet.`

Conclusion:

- RCON directo es plausible para live state
- no hay evidencia local suficiente para atribuirle `most_killed`,
  `death_by`, killer/victim o kills por arma

### 2. Event Stream Or Server Logs

Plausibilidad en esta repo: alta como origen tecnico necesario si el proyecto
quisiera reconstruir esas metricas por cuenta propia.

Motivo:

- killer/victim requiere granularidad por evento o al menos por encounter
- kills por arma requieren capturar el arma asociada al kill
- teamkills por evento requieren distinguir el evento individual
- clasificaciones como infantry / tank / artillery requieren una senal por tipo
  de kill o contexto del evento

Conclusion:

- para producir estas metricas dentro de HLL Vietnam, un pipeline de eventos o
  logs es la hipotesis tecnica mas consistente

### 3. CRCON Internal Storage / Enriched Aggregation

Plausibilidad en esta repo: alta para explicar lo que ya se observa en el
scoreboard publico.

Motivo:

- la fuente publica ya devuelve campos agregados que el proyecto no calcula
- esos campos no se derivan del snapshot live RCON implementado hoy
- `most_killed` y `death_by` parecen vistas agregadas de encounters, no simples
  contadores live del servidor

Conclusion:

- CRCON / HLL Records probablemente sirve esos campos desde una capa historica
  propia ya enriquecida y persistida, no desde la llamada live minima que esta
  repo usa por RCON

## Origin Matrix By Metric

| Metrica | RCON directo hoy en esta repo | Requiere eventos/logs para reproducirla | Requiere agregacion/persistencia propia | Origen probable segun evidencia local |
| --- | --- | --- | --- | --- |
| Estado live del servidor | Si | No | No | RCON directo |
| Jugadores actuales | Si | No | No | RCON directo |
| Mapa actual | Si | No | No | RCON directo |
| Scoreboard live basico por jugador | No confirmado | Posiblemente no siempre | Posiblemente no | No confirmado en la repo |
| `most_killed` | No | Si o fuente historica equivalente | Si | Capa historica enriquecida |
| `death_by` | No | Si o fuente historica equivalente | Si | Capa historica enriquecida |
| killer -> victim | No | Si | Si | Eventos/logs + persistencia |
| kills por arma | No | Si | Si | Eventos/logs + persistencia |
| `kills_by_type` | No | Si | Si | Eventos/logs + persistencia |
| `death_by_weapons` | No | Si | Si | Eventos/logs + persistencia |
| teamkills por evento | No | Si | Si | Eventos/logs + persistencia |
| teamkills agregados historicos | No desde RCON actual | Si | Si | Agregacion historica |
| duelos reutilizables | No | Si | Si | Eventos/logs + persistencia |
| distincion infantry / tank / artillery | No | Si | Si | Eventos/logs + clasificacion propia |
| acciones tacticas finas | No confirmadas | Si | Si | No confirmadas, pero no salen del RCON actual |

## What RCON Purely Can Plausibly Provide

Con evidencia local, RCON puro queda limitado a:

- estado actual del servidor
- jugadores presentes
- capacidad maxima
- mapa actual
- metadata live util para un panel operativo

Eso sirve para monitoreo live, no para un MVP mensual V2 con rivalidades,
armas, killers, victims o taxonomias tacticas.

## What Seems To Require Event Capture Or Logs

Las metricas siguientes solo son defendibles si el proyecto capta eventos o
logs con granularidad suficiente:

- killer -> victim
- `most_killed`
- `death_by`
- kills por arma
- `kills_by_type`
- `death_by_weapons`
- teamkills por evento
- segmentacion infantry / tank / artillery

La razon comun es que todas dependen de relaciones o atributos de eventos
individuales, no solo de un snapshot agregado del servidor.

## What Seems To Require Historical Aggregation

Incluso con eventos capturados, haria falta una capa propia de persistencia y
agregacion para exponer de forma estable:

- rivales mas frecuentes
- resumen `most_killed`
- resumen `death_by`
- perfiles de armas por jugador
- acumulados mensuales auditables por servidor

Sin esa capa, la señal estaria dispersa en eventos crudos y no seria operativa
para un ranking MVP V2.

## Final Conclusion

La conclusion mas solida que soporta esta repo es:

- `most_killed`, `death_by`, killer/victim y kills por arma no salen del RCON
  directo implementado hoy
- esas metricas ya son visibles en una fuente historica enriquecida externa al
  cliente RCON local
- para reproducirlas dentro del proyecto haria falta una canalizacion nueva de
  eventos/logs y una persistencia historica propia con agregados derivados

## Recommended Follow-Up

La siguiente task tecnica correcta es disenar el pipeline minimo de eventos de
jugador necesario para alimentar una V2 del ranking mensual sin asumir que RCON
directo ya entrega esas metricas listas.