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.