Add player event V2 pipeline foundation

ai/tasks/done/TASK-077-player-kill-event-source-adapter.md

@@ -0,0 +1,77 @@
+# TASK-077-player-kill-event-source-adapter
+
+## Goal
+Implementar una primera capa/adaptador de fuente de eventos centrada en eventos de kill/death para preparar la V2 del sistema de métricas de jugador.
+
+## Context
+Las auditorías previas concluyen que el cliente RCON live actual no basta por sí solo para obtener directamente todos los agregados avanzados visibles en ecosistemas tipo CRCON/HLL Records. Para construir métricas como:
+- killer -> victim
+- most_killed
+- death_by
+- kills por arma
+- teamkills por evento
+
+hace falta una fuente de eventos o una adaptación técnica que permita modelar esos datos en bruto antes de agregarlos.
+
+La V2 debe empezar por una primera capa mínima centrada en eventos de kill/death, sin abarcar todavía todo el resto de acciones tácticas.
+
+## Steps
+1. Revisar las auditorías y documentos de diseño V2:
+   - docs/rcon-data-capability-audit.md
+   - docs/crcon-advanced-metrics-origin-audit.md
+   - docs/player-event-pipeline-v2-design.md
+2. Identificar la fuente o punto técnico más viable dentro del proyecto actual para empezar a capturar eventos de kill/death.
+3. Diseñar e implementar un adaptador/fuente mínima para eventos de jugador que, como mínimo, pueda producir un formato común con campos base como:
+   - server
+   - match
+   - timestamp
+   - killer
+   - victim
+   - weapon si existe
+   - teamkill si existe
+4. Mantener esta capa desacoplada de la persistencia final.
+5. Documentar claramente:
+   - qué datos se capturan realmente en esta fase
+   - qué datos siguen fuera de alcance
+6. No implementar todavía snapshots/UI del MVP V2.
+7. No romper live RCON ni el histórico actual.
+8. 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
+- docs/rcon-data-capability-audit.md
+- docs/crcon-advanced-metrics-origin-audit.md
+- docs/player-event-pipeline-v2-design.md
+- backend/README.md
+- backend/app/rcon_client.py
+- backend/app/providers/rcon_provider.py
+- backend/app/data_sources.py
+
+## Expected Files to Modify
+- backend/README.md
+- opcionalmente nuevos módulos, por ejemplo:
+  - backend/app/player_event_source.py
+  - backend/app/providers/player_event_source_provider.py
+  - backend/app/event_sources/*.py
+- opcionalmente ai/architecture-index.md si conviene enlazar la nueva pieza
+
+## Constraints
+- No implementar todavía agregados finales ni UI.
+- No romper el proveedor RCON live actual.
+- No hacer cambios destructivos.
+- Mantener el trabajo centrado en una fuente mínima de eventos kill/death.
+
+## Validation
+- Existe una capa/adaptador clara para eventos de kill/death.
+- Produce un formato mínimo reutilizable por la persistencia posterior.
+- Queda documentado qué cubre y qué no cubre todavía.
+- Los cambios quedan committeados y se hace push si el entorno lo permite.
+
+## Change Budget
+- Preferir menos de 6 archivos modificados o creados.
+- Preferir menos de 240 líneas cambiadas.

ai/tasks/done/TASK-078-player-event-raw-ledger-storage.md

@@ -0,0 +1,65 @@
+# TASK-078-player-event-raw-ledger-storage
+
+## Goal
+Crear la persistencia raw mínima para eventos de jugador V2, permitiendo almacenar de forma fiable eventos de kill/death con claves estables, deduplicación y base para agregados posteriores.
+
+## Context
+Una vez exista una fuente/adaptador de eventos, hace falta una capa de persistencia en bruto. Esta capa debe ser lo bastante simple para operar ya, pero lo bastante sólida para soportar luego agregados como:
+- most_killed
+- death_by
+- kills por arma
+- teamkills por jugador
+- killer/victim mensual
+
+## Steps
+1. Revisar el diseño V2 del pipeline de eventos.
+2. Diseñar una tabla o conjunto mínimo de tablas para el ledger raw de eventos de jugador.
+3. Incluir como base, si la fuente lo permite:
+   - server key
+   - match reference
+   - event timestamp
+   - killer identity
+   - victim identity
+   - weapon
+   - teamkill flag
+   - event source reference o clave de deduplicación
+4. Implementar inicialización segura del storage de eventos.
+5. Implementar inserción idempotente o deduplicada.
+6. Mantener separada esta capa del histórico actual `historical_*`.
+7. Documentar la estructura y su propósito.
+8. No implementar todavía agregados finales ni UI.
+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
+- docs/player-event-pipeline-v2-design.md
+- backend/README.md
+- backend/app/historical_models.py
+- backend/app/historical_storage.py
+- cualquier módulo nuevo de la task anterior relacionado con eventos
+
+## Expected Files to Modify
+- backend/README.md
+- opcionalmente nuevos módulos, por ejemplo:
+  - backend/app/player_event_storage.py
+  - backend/app/player_event_models.py
+- opcionalmente docs/decisions.md si conviene fijar una decisión de persistencia
+
+## Constraints
+- No romper el histórico actual.
+- No mezclar esta persistencia con snapshots ni UI.
+- No hacer cambios destructivos.
+- Mantener el trabajo centrado en el ledger raw de eventos.
+
+## Validation
+- Existe una persistencia raw mínima para eventos de jugador.
+- Soporta deduplicación o idempotencia razonable.
+- Queda separada del histórico actual.
+- Los cambios quedan committeados y se hace push si el entorno lo permite.
+
+## Change Budget
+- Preferir menos de 6 archivos modificados o creados.
+- Preferir menos de 240 líneas cambiadas.

ai/tasks/done/TASK-079-player-event-ingestion-worker.md

@@ -0,0 +1,57 @@
+# TASK-079-player-event-ingestion-worker
+
+## Goal
+Añadir un worker/proceso incremental para ingerir eventos de jugador V2 de forma segura, reanudable y compatible con la operación actual del proyecto.
+
+## Context
+Con una fuente de eventos y un ledger raw, hace falta un proceso de ingestión incremental que capture eventos sin depender del request path del usuario y sin romper el pipeline actual de histórico y snapshots.
+
+## Steps
+1. Revisar la nueva capa de fuente de eventos y la persistencia raw.
+2. Diseñar un worker incremental específico para eventos de jugador.
+3. Añadir soporte para:
+   - ejecución manual
+   - reintentos básicos
+   - checkpoint o mecanismo de reanudación si aplica
+   - deduplicación segura
+4. Mantenerlo desacoplado del `historical-runner` actual si eso reduce riesgo operacional.
+5. Documentar cómo se ejecuta y cuál es su alcance.
+6. No implementar todavía snapshots finales ni UI del MVP V2.
+7. No romper el stack Docker actual ni el flujo histórico existente.
+8. 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
+- docs/player-event-pipeline-v2-design.md
+- backend/README.md
+- backend/app/historical_runner.py
+- backend/app/config.py
+- módulos de eventos añadidos en tasks previas
+
+## Expected Files to Modify
+- backend/app/config.py
+- backend/README.md
+- opcionalmente docker-compose.yml si hace falta dejar preparado el worker
+- opcionalmente nuevos módulos, por ejemplo:
+  - backend/app/player_event_worker.py
+  - backend/app/player_event_ingestion.py
+
+## Constraints
+- No romper el runner histórico actual.
+- No meter todavía lógica de scoring V2.
+- No tocar producto visible.
+- No hacer cambios destructivos.
+- Mantener el trabajo centrado en ingestión incremental de eventos.
+
+## Validation
+- Existe un worker o flujo incremental para eventos de jugador.
+- Puede ejecutarse de forma segura y reanudable.
+- No rompe el resto del sistema.
+- Los cambios quedan committeados y se hace push si el entorno lo permite.
+
+## Change Budget
+- Preferir menos de 6 archivos modificados o creados.
+- Preferir menos de 240 líneas cambiadas.

ai/tasks/done/TASK-080-player-event-derived-aggregates.md

@@ -0,0 +1,65 @@
+# TASK-080-player-event-derived-aggregates
+
+## Goal
+Construir los primeros agregados derivados V2 a partir del ledger raw de eventos de jugador, centrados en duelos y armas, para preparar una futura V2 del MVP.
+
+## Context
+Con eventos raw ya capturados, el siguiente paso es derivar métricas útiles y reutilizables. Las primeras más valiosas para la V2 del MVP son:
+- most_killed
+- death_by
+- killer/victim
+- kills por arma
+- teamkills por jugador
+
+## Steps
+1. Revisar la estructura del ledger raw y el diseño V2.
+2. Diseñar e implementar agregados básicos por:
+   - partida
+   - mes
+   - servidor
+   - all-servers cuando aplique
+3. Incluir al menos:
+   - most_killed
+   - death_by
+   - net duel summaries
+   - kills por arma
+   - teamkills derivados por jugador
+4. Mantener los agregados separados de la UI y del MVP V1.
+5. Documentar qué métricas derivadas quedan ya disponibles para una futura V2 del score.
+6. No implementar todavía la fórmula final del MVP V2 ni su UI.
+7. No hacer cambios destructivos.
+8. 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
+- docs/player-event-pipeline-v2-design.md
+- docs/crcon-advanced-metrics-origin-audit.md
+- backend/README.md
+- módulos de eventos raw ya implementados
+- backend/app/historical_storage.py
+- docs/monthly-mvp-ranking-scoring-design.md
+
+## Expected Files to Modify
+- backend/README.md
+- opcionalmente nuevos módulos, por ejemplo:
+  - backend/app/player_event_aggregates.py
+  - backend/app/player_event_queries.py
+- opcionalmente docs/decisions.md si hace falta fijar alguna decisión de agregación
+
+## Constraints
+- No tocar todavía la UI del MVP V2.
+- No romper el MVP V1.
+- No hacer cambios destructivos.
+- Mantener el trabajo centrado en agregados base de duelos y armas.
+
+## Validation
+- Existen agregados derivados básicos reutilizables para V2.
+- Queda clara su disponibilidad por servidor/mes/all-servers cuando aplique.
+- Los cambios quedan committeados y se hace push si el entorno lo permite.
+
+## Change Budget
+- Preferir menos de 6 archivos modificados o creados.
+- Preferir menos de 240 líneas cambiadas.