Make backend RCON-first with safe fallback

ai/tasks/done/TASK-093-rcon-first-source-selection-and-fallback-policy.md

@@ -0,0 +1,60 @@
+# TASK-093-rcon-first-source-selection-and-fallback-policy
+
+## Goal
+Convertir la aplicación a una política RCON-first real para extracción de datos, manteniendo fallback automático a los métodos antiguos solo cuando RCON falle.
+
+## Context
+La repo ya tiene piezas RCON para live y captura prospectiva, pero todavía no está orientada a RCON-first por defecto.
+Ahora mismo el sistema sigue arrancando con defaults antiguos y la política funcional real no coincide con el objetivo del producto.
+
+Queremos:
+- live/state de servidores -> RCON primero, A2S solo como fallback
+- histórico/recopilación -> RCON primero, CRCON/public-scoreboard solo como fallback
+- selección de fuente transparente, consistente y observable
+
+## Steps
+1. Auditar la selección actual de fuentes en:
+   - `backend/app/data_sources.py`
+   - `backend/app/payloads.py`
+   - `backend/app/collector.py`
+   - providers live e históricos actuales
+   - `backend/app/rcon_historical_read_model.py`
+2. Introducir una política explícita de “source arbitration” o equivalente:
+   - RCON como fuente primaria
+   - fallback a A2S para live si RCON falla
+   - fallback a public-scoreboard/CRCON para histórico si RCON falla o no puede servir la operación concreta
+3. Definir criterios claros de fallback:
+   - error de red / timeout / auth / target no disponible
+   - falta de cobertura o capacidad para una operación histórica concreta
+4. Hacer que la respuesta backend deje trazabilidad clara:
+   - fuente primaria intentada
+   - fuente finalmente usada
+   - si hubo fallback
+   - motivo del fallback
+5. Ajustar defaults/config para que el comportamiento por defecto del proyecto sea coherente con RCON-first.
+6. Actualizar README con una sección clara:
+   - política de prioridad de fuentes
+   - casos de fallback
+   - qué capacidades históricas siguen siendo parciales en RCON y cuándo entra CRCON/public-scoreboard
+
+## Constraints
+- No romper compatibilidad con los métodos antiguos.
+- No eliminar A2S ni public-scoreboard.
+- No tocar frontend salvo que haga falta exponer metadata mínima ya existente.
+- Mantener el comportamiento observable y fácil de depurar.
+
+## Validation
+- El backend intenta RCON primero para live.
+- Si RCON live falla, el backend cae a A2S de forma controlada.
+- El backend intenta RCON primero para histórico.
+- Si RCON histórico falla o no soporta una operación concreta, el backend cae a public-scoreboard/CRCON.
+- Las respuestas reflejan qué fuente se usó realmente.
+- README queda alineado con la política RCON-first.
+
+## Expected Files
+- `backend/app/data_sources.py`
+- `backend/app/payloads.py`
+- `backend/app/collector.py`
+- providers/fuentes necesarias bajo `backend/app/`
+- `backend/README.md`
+- `backend/app/config.py` si hace falta para defaults explícitos

ai/tasks/done/TASK-094-rcon-first-historical-orchestration-and-safe-fallback.md

@@ -0,0 +1,67 @@
+# TASK-094-rcon-first-historical-orchestration-and-safe-fallback
+
+## Goal
+Reorientar la orquestación histórica para que RCON sea la vía principal de recopilación cuando esté disponible, dejando el flujo CRCON/public-scoreboard como fallback seguro y no como camino primario permanente.
+
+## Context
+Actualmente:
+- existe `historical_runner`
+- existe `rcon_historical_worker`
+- existe locking single-writer
+Pero la orquestación no representa todavía una estrategia RCON-first coherente.
+Queremos una orquestación donde:
+- la recopilación prospectiva por RCON sea la prioridad
+- el refresh histórico clásico solo entre cuando RCON falle o no cubra la operación
+- no haya starvation del lock por loops demasiado agresivos
+- las automatizaciones sean operables en Docker sin bloquear trabajo manual innecesariamente
+
+## Steps
+1. Auditar:
+   - `backend/app/historical_runner.py`
+   - `backend/app/historical_ingestion.py`
+   - `backend/app/rcon_historical_worker.py`
+   - `backend/app/writer_lock.py`
+   - `docker-compose.yml`
+2. Definir una estrategia clara:
+   - RCON historical capture como flujo primario
+   - historical_ingestion clásico como fallback
+   - snapshots/rebuilds alineados con esa política
+3. Evitar que el worker RCON monopolice el writer lock:
+   - revisar intervalos por defecto
+   - revisar duración del trabajo por loop
+   - revisar si conviene separar captura frecuente y rebuild menos frecuente
+4. Asegurar que las pasadas manuales sean razonables:
+   - si hay automatización activa, que el operador tenga mensajes claros
+   - reducir riesgo de starvation o lock ocupado permanente
+5. Mejorar el manejo de stale locks entre contenedores Docker si es necesario:
+   - no depender solo del hostname si eso da falsos locks persistentes
+   - mantener seguridad y evitar liberar locks válidos por error
+6. Ajustar `docker-compose.yml` para que el stack quede alineado con el nuevo comportamiento por defecto.
+7. Actualizar README/runbook:
+   - qué proceso captura RCON primero
+   - cuándo entra el fallback histórico clásico
+   - cómo lanzar pasadas manuales
+   - cómo interpretar locks ocupados
+
+## Constraints
+- No eliminar el locking compartido.
+- No volver al comportamiento sin coordinación de writers.
+- No dejar CRCON/public-scoreboard como camino principal encubierto.
+- No romper la captura prospectiva RCON ya existente.
+
+## Validation
+- La automatización prioriza RCON para recopilación histórica.
+- El flujo clásico entra solo como fallback.
+- El lock compartido sigue funcionando.
+- La operativa Docker no queda en starvation constante.
+- Las pasadas manuales tienen comportamiento claro y documentado.
+- README/runbook queda actualizado.
+
+## Expected Files
+- `backend/app/historical_runner.py`
+- `backend/app/historical_ingestion.py`
+- `backend/app/rcon_historical_worker.py`
+- `backend/app/writer_lock.py`
+- `docker-compose.yml`
+- `backend/README.md`
+- otros archivos backend si la orquestación lo requiere

ai/tasks/done/TASK-095-restore-community-scores-link-and-source-aware-ui.md

@@ -0,0 +1,40 @@
+# TASK-095-restore-community-scores-link-and-source-aware-ui
+
+## Goal
+Restaurar correctamente el enlace/botón hacia los scores/histórico de comunidad y asegurar que la UI no pierda acciones útiles por depender de mapas hardcodeados incompletos.
+
+## Context
+Se ha detectado que el botón/enlace hacia los scores/histórico de comunidad ha desaparecido o se degrada en algunos casos.
+La lógica actual depende de un mapa hardcodeado incompleto y no cubre bien todos los servidores o casos reales.
+
+## Steps
+1. Auditar:
+   - `frontend/index.html`
+   - `frontend/assets/js/main.js`
+   - `frontend/assets/css/styles.css`
+   - si hace falta, el payload backend consumido por `/api/servers`
+2. Restaurar el CTA de scores/histórico para todos los servidores relevantes.
+3. Evitar depender exclusivamente de un mapa hardcodeado incompleto cuando haya información backend utilizable.
+4. Mantener una experiencia estable:
+   - si existe URL conocida -> mostrar enlace
+   - si no existe -> degradar de forma clara, no desaparecer silenciosamente
+5. Mantener el diseño coherente con la landing actual.
+6. No mezclar esta task con refactors amplios no relacionados.
+
+## Constraints
+- No rehacer toda la homepage.
+- No tocar la UI histórico V1/V2 salvo necesidad estricta.
+- No inventar enlaces falsos.
+- Si una URL no está disponible, la UI debe indicarlo de forma limpia.
+
+## Validation
+- El botón/enlace a scores/histórico vuelve a mostrarse correctamente.
+- No desaparece por un mapa hardcodeado incompleto.
+- La landing sigue renderizando bien.
+- La repo queda consistente.
+
+## Expected Files
+- `frontend/index.html`
+- `frontend/assets/js/main.js`
+- `frontend/assets/css/styles.css`
+- opcionalmente backend si se necesita exponer mejor la URL o metadata correspondiente