HLL Vietnam V2

.gitignore

@@ -28,3 +28,10 @@ backend/data/*.sqlite3-wal
 tmp/
 frontend/assets/img/weapons/black - copia/
 frontend/assets/img/weapons/black.zip
+.ai/
+
+/ai/
+/.ai/
+/tmp/
+/frontend/assets/img/weapons/black - copia/
+/frontend/assets/img/weapons/black.zip

ai/README.md

@@ -1,34 +0,0 @@
-# AI Platform Workspace
-
-This directory contains the AI Development Platform support layer integrated into HLL Vietnam.
-
-Its purpose is operational, not product-facing. It exists to help the project plan work through tasks, preserve repository context, coordinate specialist roles and keep changes small, reviewable and documented.
-
-## Included areas
-
-- `../ai-platform.json`: repository-specific platform configuration for local workers and validation
-- `task-template.md`: standard structure for every task
-- `repo-context.md`: repository and product context for planners and workers
-- `architecture-index.md`: quick map of the repository structure
-- `system-metrics.md`: lightweight log for platform execution metrics
-- `reports/`: generated local platform reports; Markdown reports are ignored except `.gitkeep`
-- `prompts/`: reusable planning prompts
-- `orchestrator/`: role guidance and orchestration documents
-- `tasks/`: task queue split by status
-
-## Task lifecycle
-
-- `tasks/pending/`: scoped tasks ready for a worker
-- `tasks/in-progress/`: tasks currently being executed
-- `tasks/review/`: completed work waiting for human or orchestrator review
-- `tasks/blocked/`: tasks that cannot continue without a decision or missing input
-- `tasks/obsolete/`: tasks intentionally retired without execution
-- `tasks/done/`: validated and completed tasks
-
-## HLL Vietnam usage rules
-
-- The platform must reflect the real state of HLL Vietnam, not generic sample content.
-- Tasks should be created only when there is a justified change to perform.
-- This integration does not add product features by itself.
-- The current product stack remains HTML, CSS and JavaScript on the frontend, with Python reserved for the future backend.
-- Codex workers must process explicit tasks only and use `ai-platform.json` for local platform paths where scripts support it.

ai/architecture-index.md

@@ -1,85 +0,0 @@
-# Architecture Index
-
-This file gives AI agents a fast overview of HLL Vietnam before they inspect the repository in detail.
-
-## Application Type
-
-Community website repository with a static landing in the current phase and a planned Python backend in later phases.
-
-## Top-Level Structure
-
-### Documentation
-
-- `README.md`
-- `AGENTS.md`
-- `ai-platform.json`
-- `docs/current-hll-servers-source-plan.md`
-- `docs/`
-
-### Frontend
-
-- `frontend/index.html`
-- `frontend/assets/css/`
-- `frontend/assets/js/`
-- `frontend/assets/img/`
-
-### Backend
-
-- `backend/`
-- `backend/app/`
-
-### AI Platform
-
-- `ai/`
-- `ai/orchestrator/`
-- `ai/prompts/`
-- `ai/reports/`
-- `ai/tasks/`
-
-### Automation And Support
-
-- `scripts/`
-- `.github/workflows/`
-
-## Current Technical Baseline
-
-- Frontend runtime is plain browser-loaded HTML, CSS and JavaScript.
-- Backend runtime is a minimal Python bootstrap with `GET /health` and room for placeholder API routes.
-- Python is the expected backend language for future development.
-- GitHub Actions and local PowerShell scripts may support the AI task workflow.
-
-## Editing Priorities
-
-- Product-facing changes usually start in `frontend/`.
-- Process and coordination changes usually start in `ai/`, `AGENTS.md` and `scripts/`.
-- Local AI worker configuration starts in `ai-platform.json`.
-- Backend changes must remain preparatory unless a task explicitly changes that scope.
-
-## Validation Expectations
-
-- Frontend changes should remain compatible with local browser opening where applicable.
-- AI platform changes should keep task paths and documentation aligned.
-- Script changes should fail safely when optional tools or tests are not configured.
-
-## Current Integration Direction
-
-- Discord and game server data remain in planning phase until sources, limits and security are validated.
-- Initial dynamic data should come from controlled backend placeholders, not direct frontend calls to external services.
-- The technical plan for these integrations is documented in `docs/discord-and-server-data-plan.md`.
-- Current Hell Let Loose servers may be exposed as a clearly marked provisional reference block before HLL Vietnam-specific data exists.
-- The phased source strategy for that provisional block is documented in `docs/current-hll-servers-source-plan.md`.
-- The ingestion strategy for converting that provisional block into normalized server snapshots is documented in `docs/current-hll-data-ingestion-plan.md`.
-- The logical storage foundation for persisting server snapshots is documented in `docs/stats-database-schema-foundation.md`.
-- Historical ingestion defaults to RCON-first; the public CRCON scoreboard JSON layer is a fallback for operations where RCON fails or lacks coverage, not the normal primary historical source.
-- 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`.
-- The first V2 player-event foundation now lives in dedicated `player_event_*` backend modules and starts from CRCON match-detail summaries, not from live RCON.
-- The default operational deployment is simplified to `backend` + `frontend`; historical workers and RCON historical capture are advanced/manual services.
-- Comunidad Hispana #03 is disabled from default RCON targets, while existing historical/Elo code and persisted data remain available for explicit future reintroduction. Elo/MMR remains paused and decoupled from backend startup.
-- 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`.
-- Historical RCON architecture is RCON-first end to end: session capture, AdminLog ingestion, parsed event storage, materialized matches/player stats and optional profile-snapshot enrichment.
-- Public-scoreboard data remains optional enrichment/link source or fallback only; it must not become the normal primary historical path while RCON coverage is available.
-- Manual RCON validation commands include `docker compose exec backend python -m app.rcon_admin_log_ingestion --minutes 1440` and `docker compose exec backend python -m app.rcon_historical_worker capture`.

ai/orchestrator/README.md

@@ -1,22 +0,0 @@
-# Orchestrator
-
-The orchestrator is responsible for turning repository context into safe, scoped and verifiable tasks for HLL Vietnam.
-
-## What it does
-
-- Reviews repository structure and current documentation
-- Identifies the smallest useful unit of work
-- Assigns the most suitable role guidance for the task
-- Keeps tasks aligned with HLL Vietnam constraints and branding
-- Prevents uncontrolled work outside the task system
-
-## How it collaborates
-
-- Reads `ai/architecture-index.md` and `ai/repo-context.md` first
-- Uses `ai/task-template.md` to draft tasks
-- Sends execution to the appropriate role document in this folder
-- Keeps completed work traceable through `ai/tasks/` and `ai/system-metrics.md`
-
-## Current scope
-
-At this stage the orchestrator supports repository setup, documentation alignment, planning hygiene and future implementation flow. It does not define product roadmap beyond explicit project instructions.

ai/orchestrator/analyst.md

@@ -1,30 +0,0 @@
-# Analista
-
-## Mission
-
-Convert requests into concrete repository context, dependencies and risks before implementation starts.
-
-## When This Role Intervenes
-
-- When requirements need clarification through code and docs review
-- When impact analysis is needed before editing
-- When validation criteria must be derived from repository state
-
-## Review First
-
-- `ai/repo-context.md`
-- `ai/architecture-index.md`
-- `docs/decisions.md`
-- Files directly affected by the request
-
-## Restrictions
-
-- Do not implement product features from analysis alone.
-- Do not generate a backlog beyond the immediate validated need.
-- Keep analysis focused on the current request.
-
-## Collaboration With The Orchestrator
-
-- Provides the factual basis for task creation
-- Identifies the smallest safe change set
-- Documents assumptions the worker must preserve

ai/orchestrator/backend-senior.md

@@ -1,30 +0,0 @@
-# Backend Senior
-
-## Mission
-
-Guard backend readiness and future service design without introducing premature implementation.
-
-## When This Role Intervenes
-
-- When a task touches `backend/`
-- When integration points with the future backend must be documented
-- When validation needs to preserve Python readiness
-
-## Review First
-
-- `backend/README.md`
-- `backend/requirements.txt`
-- `docs/project-overview.md`
-- `docs/decisions.md`
-
-## Restrictions
-
-- Do not create functional backend services unless explicitly required by task.
-- Keep the future backend baseline in Python.
-- Avoid placeholder complexity that creates false architecture commitments.
-
-## Collaboration With The Orchestrator
-
-- Reviews backend-facing tasks for future compatibility
-- Suggests minimal preparatory structure only when justified
-- Prevents accidental drift toward non-Python backend assumptions

ai/orchestrator/component-discovery.md

@@ -1,20 +0,0 @@
-# Component Discovery
-
-## Purpose
-
-Identify the real repository areas affected by a request before any task is executed.
-
-## Repository Areas
-
-- Root docs: repository purpose and rules
-- `docs/`: scope, roadmap and decisions
-- `frontend/`: current live product surface
-- `backend/`: future Python backend foundation
-- `ai/`: orchestration and task workflow
-- `scripts/`: local platform automation
-
-## Rules
-
-- Read the smallest relevant set of files first.
-- Prefer extending existing documents and scripts instead of duplicating them.
-- Do not assume framework layers that do not exist in this repository.

ai/orchestrator/database-architect.md

@@ -1,30 +0,0 @@
-# Arquitecto de Base de Datos
-
-## Mission
-
-Protect long-term data modeling decisions while the repository is still in foundation stage.
-
-## When This Role Intervenes
-
-- When a task discusses future persistence
-- When backend planning introduces data structure assumptions
-- When architecture documents mention storage or schema strategy
-
-## Review First
-
-- `docs/project-overview.md`
-- `docs/roadmap.md`
-- `docs/decisions.md`
-- `backend/README.md`
-
-## Restrictions
-
-- Do not introduce concrete database implementations in this phase.
-- Do not force schema decisions without a real product task.
-- Keep guidance abstract and aligned with the future Python backend.
-
-## Collaboration With The Orchestrator
-
-- Reviews planning assumptions for data persistence
-- Helps avoid premature database commitments
-- Documents open questions instead of inventing structures

ai/orchestrator/di-analysis.md

@@ -1,11 +0,0 @@
-# Dependency Analysis
-
-## Purpose
-
-Analyze dependencies and execution assumptions before changing scripts, automation or future backend design notes.
-
-## Rules
-
-- Identify whether the task affects frontend-only, documentation-only or platform-only areas.
-- Avoid importing template assumptions from unrelated stacks.
-- When in doubt, preserve the current lightweight structure and document the dependency instead of implementing it.

ai/orchestrator/feature-planner.md

@@ -1,20 +0,0 @@
-# Feature Planner
-
-## Purpose
-
-Turn explicit repository requests into implementation-ready tasks without expanding product scope.
-
-## Workflow
-
-1. Read `AGENTS.md`.
-2. Read `ai/repo-context.md`.
-3. Read `ai/architecture-index.md`.
-4. Inspect only the files directly related to the request.
-5. Create the smallest useful task set in `ai/tasks/pending`.
-
-## Rules
-
-- Use `ai/task-template.md`.
-- Keep tasks small, focused and verifiable.
-- Do not invent product work beyond the request.
-- Keep HLL Vietnam branding and stack constraints intact.

ai/orchestrator/frontend-senior.md

@@ -1,30 +0,0 @@
-# Frontend Senior
-
-## Mission
-
-Maintain and evolve the frontend foundation with minimal, high-signal changes that preserve local-browser compatibility.
-
-## When This Role Intervenes
-
-- When a task touches `frontend/`
-- When landing integration must remain stable after platform changes
-- When markup, styles or script loading need review
-
-## Review First
-
-- `frontend/index.html`
-- `frontend/assets/css/styles.css`
-- `frontend/assets/js/main.js`
-- `docs/decisions.md`
-
-## Restrictions
-
-- Do not introduce heavy frontend frameworks in this phase.
-- Do not redesign the landing unless the task explicitly requires it.
-- Preserve the HLL Vietnam military and tactical tone.
-
-## Collaboration With The Orchestrator
-
-- Confirms whether a task really needs product-facing frontend edits
-- Keeps frontend changes scoped and reversible
-- Reports any integration effect on direct browser usage

ai/orchestrator/graphic-designer.md

@@ -1,30 +0,0 @@
-# Disenador Grafico
-
-## Mission
-
-Protect the visual identity of HLL Vietnam so that future assets, layouts and presentations remain coherent with the intended military and Vietnam-inspired branding.
-
-## When This Role Intervenes
-
-- When a task affects visual assets or art direction
-- When design documentation needs alignment
-- When branding consistency is at risk
-
-## Review First
-
-- `frontend/index.html`
-- `frontend/assets/css/styles.css`
-- `docs/project-overview.md`
-- `docs/decisions.md`
-
-## Restrictions
-
-- Do not introduce off-brand visuals or generic styles.
-- Do not add asset-heavy redesign work unless explicitly requested.
-- Preserve a sober tactical tone.
-
-## Collaboration With The Orchestrator
-
-- Validates visual consistency before design-oriented tasks are executed
-- Helps frame asset and branding work into scoped tasks
-- Keeps platform-generated work aligned with project identity

ai/orchestrator/planning-memory.md

@@ -1,12 +0,0 @@
-# Planning Memory
-
-## Purpose
-
-Store short planning lessons that help future tasks stay aligned with the repository.
-
-## Current Notes
-
-- HLL Vietnam is in foundation stage.
-- Product work must not be invented from generic platform templates.
-- Backend assumptions must remain Python-oriented.
-- Frontend remains static and lightweight until explicitly expanded.

ai/orchestrator/pm.md

@@ -1,30 +0,0 @@
-# PM
-
-## Mission
-
-Translate stakeholder intent into the smallest useful task scope without changing project goals on your own.
-
-## When This Role Intervenes
-
-- When a request needs scope framing
-- When work must be split into smaller tasks
-- When priorities or sequencing need clarification
-
-## Review First
-
-- `README.md`
-- `docs/project-overview.md`
-- `docs/roadmap.md`
-- `AGENTS.md`
-
-## Restrictions
-
-- Do not invent new product features without instruction.
-- Do not expand scope beyond what the request justifies.
-- Do not bypass the task system.
-
-## Collaboration With The Orchestrator
-
-- Helps the orchestrator define task boundaries
-- Suggests execution order
-- Flags scope creep early

ai/orchestrator/python-architect.md

@@ -1,30 +0,0 @@
-# Arquitecto Python
-
-## Mission
-
-Ensure all backend-oriented planning remains coherent with a future Python implementation.
-
-## When This Role Intervenes
-
-- When backend architecture is discussed
-- When automation or support scripts reference backend assumptions
-- When tasks might accidentally introduce a conflicting stack
-
-## Review First
-
-- `AGENTS.md`
-- `docs/decisions.md`
-- `backend/README.md`
-- `ai/repo-context.md`
-
-## Restrictions
-
-- Do not add Python services, frameworks or runtime code unless explicitly requested.
-- Do not accept template defaults that assume .NET or another backend stack.
-- Keep platform docs aligned with Python as the intended backend.
-
-## Collaboration With The Orchestrator
-
-- Reviews tasks for backend stack consistency
-- Rewrites generic template assumptions into Python-compatible guidance
-- Flags any drift away from the intended backend baseline

ai/orchestrator/repo-reviewer.md

@@ -1,12 +0,0 @@
-# Repository Reviewer
-
-## Purpose
-
-Review repository health and identify only the most relevant technical follow-ups.
-
-## Rules
-
-- Start from `ai/architecture-index.md` and `ai/repo-context.md`.
-- Prefer documentation, consistency and workflow issues over speculative product work.
-- Do not create a large backlog by default.
-- If needed, create only minimal technical readiness tasks.

ai/orchestrator/ui-expert.md

@@ -1,30 +0,0 @@
-# Experto en Interfaz
-
-## Mission
-
-Safeguard usability, clarity and responsive behavior of the HLL Vietnam frontend without introducing unnecessary complexity.
-
-## When This Role Intervenes
-
-- When a task changes user-facing flows or layout
-- When responsiveness or readability must be reviewed
-- When an integration could degrade the landing experience
-
-## Review First
-
-- `frontend/index.html`
-- `frontend/assets/css/styles.css`
-- `frontend/assets/js/main.js`
-- `docs/project-overview.md`
-
-## Restrictions
-
-- Do not add new interface flows without task scope.
-- Do not sacrifice simplicity for novelty.
-- Keep interactions lightweight and compatible with the current static frontend approach.
-
-## Collaboration With The Orchestrator
-
-- Reviews impact on usability before execution
-- Recommends minimal UI-safe changes
-- Helps keep frontend tasks grounded in real interface needs

ai/prompts/plan-feature.md

@@ -1,26 +0,0 @@
-# Plan Feature Prompt
-
-Use this prompt when the orchestrator needs to transform a repository request into implementation-ready tasks.
-
-## Prompt
-
-Analyze the HLL Vietnam repository before proposing any implementation work.
-
-Required behavior:
-
-1. Read `AGENTS.md`.
-2. Read `ai/repo-context.md`.
-3. Read `ai/architecture-index.md`.
-4. Review only the files directly related to the request.
-5. Produce a small, safe task breakdown.
-6. Do not invent product features outside the request.
-7. Keep branding, frontend stack and planned Python backend consistent with the repository rules.
-
-Task output rules:
-
-- Use `ai/task-template.md`.
-- Keep tasks small and verifiable.
-- Prefer one task when the work is very small.
-- Add clear `Files to Read First`.
-- Add clear `Expected Files to Modify`.
-- Include explicit validation steps.

ai/repo-context.md

@@ -1,94 +0,0 @@
-# Repository Context
-
-## Project Overview
-
-HLL Vietnam is a community website repository for a Spanish-speaking Discord community centered on the future game HLL Vietnam.
-
-The current implementation is intentionally small:
-
-- a static landing page in `frontend/`
-- a reserved Python backend space in `backend/`
-- documentation in `docs/`
-- an AI task orchestration layer in `ai/`
-
-This repository is in foundation stage. The objective is to grow in a controlled way without losing clarity or overwriting project identity with generic template content.
-
-## Current Product State
-
-- Frontend: static HTML, CSS and vanilla JavaScript
-- Backend: not implemented yet, but planned in Python
-- AI Platform: integrated to coordinate planning and task execution
-- Product goal in current phase: maintain a clean landing and repository structure
-- Default deployment: `backend` + `frontend`; historical workers are advanced/manual only.
-- Live and historical defaults are RCON-first, with public-scoreboard kept only as historical fallback.
-- Comunidad Hispana #03 is not part of default RCON targets. Historical/Elo code and persisted data are preserved, while Elo/MMR remains paused and decoupled from backend startup.
-- RCON historical data flow is session capture plus AdminLog ingestion, parsed event storage, materialized matches/player stats and optional player profile snapshot enrichment.
-- Public scoreboard may enrich links or fill unsupported historical gaps, but it is not the primary historical source when RCON coverage exists.
-
-## Repository Areas
-
-### Root documentation
-
-- `README.md`
-- `AGENTS.md`
-
-These files define the repository purpose and operating rules.
-
-### Docs
-
-- `docs/project-overview.md`
-- `docs/roadmap.md`
-- `docs/decisions.md`
-
-These files describe scope, phased evolution and technical decisions.
-
-### Frontend
-
-- `frontend/index.html`
-- `frontend/assets/css/styles.css`
-- `frontend/assets/js/main.js`
-
-This is the live product surface in the current phase. Keep changes conservative unless a task explicitly targets the landing.
-
-### Backend
-
-- `backend/README.md`
-- `backend/requirements.txt`
-- `backend/app/__init__.py`
-
-This area is a reserved foundation for the future Python backend. Do not add functional services unless explicitly requested by task.
-
-### AI Platform
-
-- `ai/task-template.md`
-- `ai-platform.json`
-- `ai/repo-context.md`
-- `ai/architecture-index.md`
-- `ai/system-metrics.md`
-- `ai/reports/`
-- `ai/prompts/`
-- `ai/orchestrator/`
-- `ai/tasks/`
-
-This area supports planning, orchestration and execution discipline.
-
-## Working Rules For Agents
-
-- Always work from tasks, except for repository inspection or explicitly requested platform integration.
-- Prefer small, focused, reviewable changes.
-- Preserve the military and Vietnam-inspired visual tone.
-- Avoid introducing new technologies without clear reason.
-- Treat Python as the planned backend baseline.
-
-## AI Workflow
-
-`Request -> Orchestrator review -> Scoped task -> Execution -> Validation -> Documentation -> Commit`
-
-Tasks move through:
-
-- `ai/tasks/pending`
-- `ai/tasks/in-progress`
-- `ai/tasks/review`
-- `ai/tasks/blocked`
-- `ai/tasks/obsolete`
-- `ai/tasks/done`

ai/reports/.gitkeep

@@ -1 +0,0 @@
-

ai/system-metrics.md

@@ -1,25 +0,0 @@
-# System Metrics
-
-This file tracks lightweight execution history for the HLL Vietnam AI development workflow.
-
-## Metrics
-
-- Total task cycles executed
-- Successful task cycles
-- Failed task cycles
-- Average cycle duration
-- Notes about skipped validation steps
-
-## Task History
-
-Date | Task | Duration | Result | Notes
-2026-03-19 | TASK-001-platform-readiness-check | n/a | success | README y roadmap alineados con la integración actual de AI Platform; scripts clave presentes; no hay tests de integración configurados para este alcance.
-2026-03-19T13:59:33 | worker-cycle | 641.24 sec | success | codex-runner
-2026-05-19T08:39:12 | worker-cycle | 663.71 sec | success | codex-runner
-2026-05-19T17:20:44 | worker-cycle | 2240.22 sec | success | codex-runner
-2026-05-21T14:43:44 | worker-cycle | 5580.9 sec | success | codex-runner
-2026-05-21T15:17:18 | worker-cycle | 688.86 sec | success | codex-runner
-2026-05-21T18:59:27 | worker-cycle | 527.54 sec | success | codex-runner
-2026-06-08T18:58:19 | worker-cycle | 3951.99 sec | success | codex-runner
-2026-06-08T19:02:50 | worker-cycle | 16.57 sec | success | codex-runner
-2026-06-08T19:24:20 | worker-cycle | 1278.68 sec | failed(-1) | codex-runner

ai/task-template.md

@@ -1,86 +0,0 @@
----
-id: TASK-XXX
-title: Short task title
-status: pending
-type: platform | frontend | backend | documentation | research
-team: PM | Analista | Backend Senior | Frontend Senior | Arquitecto de Base de Datos | Arquitecto Python | Disenador grafico | Experto en interfaz
-supporting_teams: []
-roadmap_item: foundation
-priority: medium
----
-
-# TASK-XXX - Short task title
-
-## Goal
-
-Describe the smallest useful objective for this task.
-
-## Context
-
-Explain where the change happens in HLL Vietnam and why it is needed now.
-
-Preserve the current product identity: Spanish-speaking HLL Vietnam community, military/Vietnam/tactical/sober visual direction and controlled repository evolution.
-
-## Steps
-
-1. Inspect the listed files first.
-2. Apply only the scoped change.
-3. Validate the result and document relevant findings.
-
-## Files to Read First
-
-List 3 to 6 files that must be reviewed before changing anything.
-
-Examples for this repository:
-
-- `AGENTS.md`
-- `ai/repo-context.md`
-- `ai/architecture-index.md`
-- `frontend/index.html`
-- `frontend/assets/css/styles.css`
-- `backend/README.md`
-
-Rules:
-
-- Read these files before implementation.
-- Keep the list small and directly relevant.
-- Prefer existing docs and code that already define the area being changed.
-
-## Expected Files to Modify
-
-List the files that should change during the task.
-
-Rules:
-
-- Prefer modifying only these files.
-- If additional files become necessary, explain why in the task outcome or commit message.
-- Do not modify unrelated files.
-
-## Constraints
-
-- Keep the change minimal.
-- Preserve HLL Vietnam project identity.
-- Do not introduce unnecessary frameworks or dependencies.
-- Do not implement backend functionality unless the task explicitly requires it.
-- Do not expand Elo/MMR, historical workers or RCON server #03 handling unless the task explicitly requires it.
-- Do not overwrite repository-specific context with generic platform template text.
-
-## Validation
-
-Before completing the task ensure:
-
-- scoped checks pass
-- no unrelated files were modified
-- documentation remains consistent with the repository state
-- `git diff --name-only` matches the expected scope
-- integration tests are run when relevant and configured
-
-## Outcome
-
-Document the validation performed, notable decisions, and any follow-up task that should be created instead of expanding this task.
-
-## Change Budget
-
-- Prefer fewer than 5 modified files.
-- Prefer changes under 200 lines when feasible.
-- Split the work into follow-up tasks if limits are exceeded.

ai/tasks/blocked/.gitkeep

@@ -1 +0,0 @@
-

ai/tasks/done/.gitkeep

@@ -1 +0,0 @@
-

ai/tasks/done/TASK-001-platform-readiness-check.md

@@ -1,75 +0,0 @@
-# TASK-001-platform-readiness-check
-
-## Goal
-Validar que la integración de AI Development Platform en el repositorio HLL Vietnam está completa, coherente y lista para ejecutar tasks de forma segura con Codex.
-
-## Context
-El repositorio ya tiene una estructura base de producto y se ha integrado la capa operativa inspirada en ai-dev-platform-template. Antes de generar tasks funcionales del producto, hay que verificar que el flujo por tasks, documentación, scripts y estructura están realmente alineados y no contienen inconsistencias.
-
-## Steps
-1. Revisar la estructura de carpetas del repositorio.
-2. Verificar que existen y son coherentes:
-   - AGENTS.md
-   - ai/task-template.md
-   - ai/repo-context.md
-   - ai/architecture-index.md
-   - ai/system-metrics.md
-   - ai/prompts/plan-feature.md
-   - ai/orchestrator/*
-   - ai/tasks/pending
-   - ai/tasks/in-progress
-   - ai/tasks/done
-   - scripts/codex-runner.ps1
-   - scripts/run-integration-tests.ps1
-3. Confirmar que AGENTS.md refleja el flujo correcto:
-   - el orquestador analiza código y redacta tasks
-   - Codex no actúa fuera de tasks salvo mantenimiento o inspección explícita
-   - backend previsto en Python
-   - frontend actual en HTML/CSS/JS
-4. Revisar que la documentación de contexto no contradice el proyecto HLL Vietnam.
-5. Revisar que la task actual y la plantilla de task usan una estructura coherente con el template.
-6. Si detectas incoherencias pequeñas, corrígelas.
-7. Dejar un breve resumen en ai/system-metrics.md o en la documentación correspondiente si el flujo del repo ya lo contempla.
-
-## Files to Read First
-- AGENTS.md
-- README.md
-- docs/project-overview.md
-- docs/decisions.md
-- ai/task-template.md
-- ai/repo-context.md
-- ai/architecture-index.md
-- ai/orchestrator/README.md
-- scripts/codex-runner.ps1
-- scripts/run-integration-tests.ps1
-
-## Expected Files to Modify
-- Solo los estrictamente necesarios si se detectan inconsistencias menores.
-- No modificar archivos de producto salvo documentación mínima si es imprescindible.
-
-## Constraints
-- No implementar features del producto.
-- No tocar la landing salvo que haya una inconsistencia documental o estructural.
-- No añadir dependencias nuevas.
-- No hacer cambios destructivos.
-- Mantener el cambio pequeño y verificable.
-
-## Validation
-- La estructura AI Platform existe y es navegable.
-- AGENTS.md refleja correctamente el flujo de trabajo del proyecto.
-- No hay referencias obsoletas a .NET como arquitectura del producto.
-- Los scripts clave existen.
-- La plantilla de task es usable para futuras tasks.
-- El repo queda listo para que el siguiente paso sea crear una task funcional real.
-
-## Change Budget
-- Preferir menos de 8 archivos modificados.
-- Preferir menos de 250 líneas cambiadas.
-
-## Outcome
-- Verificada la existencia y coherencia de `AGENTS.md`, `ai/task-template.md`, `ai/repo-context.md`, `ai/architecture-index.md`, `ai/system-metrics.md`, `ai/prompts/plan-feature.md`, `ai/orchestrator/*`, `ai/tasks/*`, `scripts/codex-runner.ps1` y `scripts/run-integration-tests.ps1`.
-- Confirmado que `AGENTS.md` refleja correctamente el flujo por tasks, el alcance de Codex y la dirección técnica actual: frontend en HTML/CSS/JS y backend futuro en Python.
-- Corregidas dos incoherencias documentales menores:
-  - `README.md` ya no presenta la plataforma AI como integración futura.
-  - `docs/roadmap.md` ahora trata la orquestación como capacidad existente que debe evolucionar, no incorporarse desde cero.
-- Validación manual completada. El script `scripts/run-integration-tests.ps1` existe, pero actualmente solo documenta que no hay tests de integración configurados para este alcance.

ai/tasks/done/TASK-002-logo-asset-integration.md

@@ -1,61 +0,0 @@
-# TASK-002-logo-asset-integration
-
-## Goal
-Integrar correctamente el logo real del proyecto HLL Vietnam en la landing actual, asegurando que el frontend use un asset local estable y coherente con la identidad visual del proyecto.
-
-## Context
-La landing inicial ya existe y actualmente está preparada para mostrar un logo local en `frontend/assets/img/logo.png`. Antes de hacer mejoras visuales adicionales, hay que consolidar la integración del logo real para que el proyecto tenga una base visual correcta, mantenible y consistente.
-
-## Steps
-1. Revisar la estructura actual del frontend.
-2. Confirmar que existe la ruta esperada para el logo:
-   - `frontend/assets/img/logo.png`
-3. Si el logo real aún no está en esa ruta, dejar la integración preparada de forma segura sin romper la página.
-4. Revisar `frontend/index.html` para asegurar que:
-   - usa la ruta local correcta del logo
-   - el `alt` del logo es descriptivo y coherente
-   - no hay rutas temporales, absolutas o inconsistentes
-5. Revisar `frontend/assets/css/styles.css` para asegurar que:
-   - el bloque visual del logo tiene un tamaño adecuado
-   - mantiene buena presentación en escritorio y móvil
-   - no deforma la imagen
-6. Corregir cualquier inconsistencia menor relacionada con la carga o presentación del logo.
-7. Mantener la landing simple: logo, tráiler y botón de Discord.
-
-## Files to Read First
-- frontend/index.html
-- frontend/assets/css/styles.css
-- docs/project-overview.md
-- ai/repo-context.md
-- AGENTS.md
-
-## Expected Files to Modify
-- frontend/index.html
-- frontend/assets/css/styles.css
-- opcionalmente `frontend/assets/img/logo.png` si el flujo de la task contempla dejar el asset correctamente ubicado
-
-## Constraints
-- No rediseñar toda la landing.
-- No añadir nuevas secciones.
-- No introducir frameworks ni dependencias nuevas.
-- No tocar backend.
-- No hacer cambios destructivos.
-- Mantener la estética militar sobria ya definida.
-
-## Validation
-- La landing referencia el logo local mediante una ruta estable.
-- El logo se muestra correctamente sin deformaciones.
-- El HTML sigue funcionando al abrirse directamente en navegador.
-- La presentación del logo es correcta tanto en móvil como en escritorio.
-- No se rompe el tráiler ni el botón de Discord.
-
-## Change Budget
-- Preferir menos de 4 archivos modificados.
-- Preferir menos de 120 líneas cambiadas.
-
-## Outcome
-- Confirmada la existencia del asset local `frontend/assets/img/logo.png`; no fue necesario reemplazarlo ni moverlo.
-- `frontend/index.html` mantiene una ruta local estable (`./assets/img/logo.png`) y ahora usa un `alt` más descriptivo junto con dimensiones explícitas para reducir saltos de layout.
-- `frontend/assets/css/styles.css` ya no fuerza un contenedor cuadrado para el logo: la imagen conserva su proporción con `max-width` y `max-height`, con ajustes específicos para escritorio y móvil.
-- Validación completada mediante revisión del marcado, verificación de la ruta local del logo y revisión de `git diff --name-only`.
-- No hay tests de integración configurados para este alcance; la comprobación aplicable fue manual sobre HTML/CSS y compatibilidad con apertura directa en navegador.

ai/tasks/done/TASK-003-landing-minimal-polish.md

@@ -1,67 +0,0 @@
-# TASK-003-landing-minimal-polish
-
-## Goal
-Mejorar visualmente la landing actual de HLL Vietnam con un pulido minimo y controlado, reforzando la identidad militar y la claridad visual sin cambiar el alcance funcional de la pagina.
-
-## Context
-La landing ya tiene los tres elementos principales del alcance actual: logo local, boton de Discord y trailer embebido. Tras integrar correctamente el asset del logo, el siguiente paso es mejorar la presentacion general para que la pagina tenga una apariencia mas solida, mas limpia y mas coherente con la tematica del proyecto, sin anadir nuevas secciones ni complejidad innecesaria.
-
-## Steps
-1. Revisar la estructura actual de `frontend/index.html`.
-2. Revisar los estilos actuales en `frontend/assets/css/styles.css`.
-3. Mejorar la jerarquia visual del bloque principal:
-   - logo
-   - titulo principal
-   - subtitulo, si existe
-   - boton de Discord
-   - bloque del trailer
-4. Ajustar espaciados, tamanos, anchuras y alineaciones para mejorar legibilidad.
-5. Reforzar la identidad visual militar sobria:
-   - paleta oscura
-   - acentos controlados
-   - mejor contraste
-   - sensacion tactica/cinematica sin recargar
-6. Mejorar el contenedor del video para que se vea mas integrado en la composicion general.
-7. Verificar que la landing siga funcionando correctamente en escritorio y movil.
-8. Mantener el alcance estricto actual, sin anadir nuevas funcionalidades ni secciones.
-
-## Files to Read First
-- frontend/index.html
-- frontend/assets/css/styles.css
-- docs/project-overview.md
-- ai/repo-context.md
-- AGENTS.md
-
-## Expected Files to Modify
-- frontend/index.html
-- frontend/assets/css/styles.css
-
-## Constraints
-- No anadir nuevas secciones de contenido.
-- No tocar backend.
-- No introducir frameworks ni librerias nuevas.
-- No modificar la ruta del logo.
-- No cambiar el enlace de Discord.
-- No cambiar el trailer.
-- No hacer cambios destructivos.
-- Mantener el HTML funcional abriendose directamente en navegador.
-
-## Validation
-- La landing se ve mas solida y ordenada visualmente.
-- Se mantiene el enfoque minimo: logo, identidad, Discord y trailer.
-- El logo sigue cargando desde `./assets/img/logo.png`.
-- El boton de Discord sigue visible y destacado.
-- El trailer sigue funcionando correctamente.
-- La presentacion sigue siendo responsive.
-- No se anaden elementos fuera del alcance actual.
-
-## Change Budget
-- Preferir menos de 3 archivos modificados.
-- Preferir menos de 180 lineas cambiadas.
-
-## Outcome
-- `frontend/index.html` mantiene el contenido original de la landing y solo anade hooks de estilo para reforzar la jerarquia visual del bloque principal.
-- `frontend/assets/css/styles.css` mejora composicion, contraste, espaciados y tratamiento del bloque de video con una direccion mas sobria y tactica, sin introducir nuevas secciones ni funcionalidades.
-- Se mantuvieron sin cambios la ruta del logo (`./assets/img/logo.png`), el enlace de Discord y el `iframe` del trailer.
-- Validacion completada mediante revision del HTML/CSS resultante y `git diff --name-only`, confirmando que el alcance quedo limitado a los archivos esperados.
-- No hay tests de integracion configurados para este alcance; la validacion aplicable fue manual sobre compatibilidad de HTML/CSS para apertura directa en navegador y comportamiento responsive esperado.

ai/tasks/done/TASK-004-python-backend-bootstrap.md

@@ -1,69 +0,0 @@
-# TASK-004-python-backend-bootstrap
-
-## Goal
-Preparar una base minima y ordenada de backend en Python para el proyecto HLL Vietnam, dejando la estructura lista para crecer sin implementar todavia logica de negocio real ni integraciones externas.
-
-## Context
-El proyecto ya dispone de una landing minima funcional y de la capa operativa AI Platform integrada. El siguiente paso tecnico logico es dejar preparado el backend principal del proyecto, que estara basado en Python. En esta fase no se busca desarrollar funcionalidades reales, sino establecer una base limpia, mantenible y coherente con la futura evolucion del sistema.
-
-## Steps
-1. Revisar la estructura actual de la carpeta `backend/`.
-2. Preparar una base minima de aplicacion Python dentro de `backend/app/`.
-3. Crear o ajustar un punto de entrada claro para la aplicacion, por ejemplo un archivo principal como:
-   - `backend/app/main.py`
-4. Definir una estructura minima coherente para crecimiento posterior.
-5. Anadir un endpoint o mecanismo minimo de verificacion de estado, por ejemplo:
-   - `/health`
-   o equivalente segun la solucion elegida.
-6. Actualizar `backend/README.md` para explicar:
-   - proposito de la carpeta backend
-   - stack elegido en esta fase
-   - como arrancar localmente la base minima si ya aplica
-7. Ajustar `backend/requirements.txt` con las dependencias minimas reales, si fueran necesarias.
-8. Mantener el alcance estricto: solo bootstrap tecnico del backend.
-
-## Files to Read First
-- README.md
-- AGENTS.md
-- docs/project-overview.md
-- docs/roadmap.md
-- docs/decisions.md
-- ai/repo-context.md
-- ai/architecture-index.md
-- backend/README.md
-- backend/requirements.txt
-- backend/app/__init__.py
-
-## Expected Files to Modify
-- backend/README.md
-- backend/requirements.txt
-- backend/app/__init__.py
-- backend/app/main.py
-
-## Constraints
-- No implementar logica de Discord.
-- No implementar logica de servidores de juego.
-- No anadir base de datos todavia.
-- No introducir complejidad innecesaria.
-- No tocar frontend salvo documentacion cruzada minima si fuera imprescindible.
-- No hacer cambios destructivos.
-- Mantener la solucion simple, clara y preparada para crecer.
-
-## Validation
-- Existe una estructura backend mas solida que la inicial.
-- Existe un punto de entrada claro para la aplicacion Python.
-- Existe una verificacion minima de estado o equivalente.
-- La documentacion del backend refleja correctamente el nuevo estado.
-- No se han anadido funcionalidades fuera de alcance.
-- El backend queda listo para que una siguiente task defina contratos API o primeras rutas reales.
-
-## Change Budget
-- Preferir menos de 6 archivos modificados o creados.
-- Preferir menos de 220 lineas cambiadas.
-
-## Outcome
-- Bootstrap backend implementado con Python estandar, sin frameworks ni dependencias externas.
-- Punto de entrada creado en `backend/app/main.py`.
-- Health check minimo disponible en `GET /health`.
-- `backend/README.md` actualizado con estructura, alcance y forma de arranque local.
-- `backend/requirements.txt` mantenido sin dependencias externas para evitar compromisos prematuros de arquitectura.

ai/tasks/done/TASK-005-frontend-backend-contract.md

@@ -1,86 +0,0 @@
-# TASK-005-frontend-backend-contract
-
-## Goal
-Definir el contrato inicial entre frontend y backend para el proyecto HLL Vietnam, estableciendo endpoints, formatos de respuesta y convenciones mínimas sin implementar todavía integraciones reales con Discord, servidores de juego o base de datos.
-
-## Context
-El proyecto ya dispone de una landing mínima funcional y de un backend Python bootstrap con verificación básica de estado. Antes de añadir lógica real, es importante fijar un contrato claro entre frontend y backend para evitar improvisación posterior y permitir que futuras tasks implementen endpoints y consumo de datos de forma consistente.
-
-## Steps
-1. Revisar la estructura actual del frontend y del backend.
-2. Revisar el estado actual del backend bootstrap y el endpoint de salud existente.
-3. Definir el conjunto mínimo de endpoints previstos a corto plazo, aunque algunos queden documentados como futuros. Incluir al menos:
-   - `GET /health`
-   - `GET /api/community`
-   - `GET /api/trailer`
-   - `GET /api/discord`
-   - `GET /api/servers`
-4. Para cada endpoint, documentar:
-   - propósito
-   - método HTTP
-   - ruta
-   - formato de respuesta
-   - ejemplo JSON
-   - estado actual: implementado, previsto o placeholder
-5. Definir convenciones básicas de respuesta:
-   - nombres de campos
-   - estructura JSON
-   - uso de `status`
-   - tratamiento mínimo de errores
-6. Documentar cómo debería consumir el frontend estos endpoints más adelante, sin implementarlo todavía.
-7. Añadir o actualizar documentación técnica para que el contrato quede claro dentro del repositorio.
-8. Si detectas incoherencias pequeñas entre documentación y bootstrap actual, corrígelas sin salirte del alcance.
-
-## Files to Read First
-- README.md
-- AGENTS.md
-- docs/project-overview.md
-- docs/roadmap.md
-- docs/decisions.md
-- ai/repo-context.md
-- ai/architecture-index.md
-- backend/README.md
-- backend/app/__init__.py
-- backend/app/main.py
-- frontend/index.html
-- frontend/assets/js/main.js
-
-## Expected Files to Modify
-- docs/project-overview.md
-- docs/decisions.md
-- backend/README.md
-- ai/architecture-index.md
-- opcionalmente un nuevo documento técnico si encaja mejor, por ejemplo:
-  - `docs/frontend-backend-contract.md`
-
-## Constraints
-- No implementar todavía endpoints reales adicionales.
-- No integrar Discord real.
-- No integrar servidores de juego reales.
-- No introducir base de datos.
-- No cambiar el comportamiento visible del frontend.
-- No añadir frameworks ni dependencias nuevas.
-- No hacer cambios destructivos.
-- Mantener la solución clara, pequeña y útil para futuras tasks.
-
-## Validation
-- Existe documentación clara del contrato inicial frontend-backend.
-- `GET /health` queda reflejado correctamente como endpoint actual.
-- Los endpoints futuros quedan documentados con ejemplos coherentes.
-- El contrato usa convenciones consistentes de respuesta JSON.
-- El repositorio queda preparado para que siguientes tasks implementen endpoints reales de forma ordenada.
-
-## Change Budget
-- Preferir menos de 5 archivos modificados o creados.
-- Preferir menos de 220 líneas cambiadas.
-## Outcome
-
-- Se añadió `docs/frontend-backend-contract.md` como referencia central del contrato inicial frontend-backend.
-- Se actualizaron `docs/project-overview.md`, `docs/decisions.md` y `backend/README.md` para reflejar el contrato y el estado actual de `GET /health`.
-- No se implementaron endpoints nuevos ni se cambió el comportamiento visible del frontend.
-
-## Validation Result
-
-- Verificado con `python -c "from app.main import build_health_payload; print(build_health_payload())"` en `backend/`.
-- Resultado comprobado: `{'status': 'ok', 'service': 'hll-vietnam-backend', 'phase': 'bootstrap'}`.
-- No aplican integration tests para este alcance documental.

ai/tasks/done/TASK-006-discord-and-server-data-plan.md

@@ -1,84 +0,0 @@
-# TASK-006-discord-and-server-data-plan
-
-## Goal
-Definir la estrategia técnica inicial para obtener, modelar y exponer los futuros datos de Discord y de los servidores de juego en el proyecto HLL Vietnam, sin implementar todavía integraciones reales.
-
-## Context
-El proyecto ya dispone de una landing mínima, un backend Python bootstrap y un contrato inicial frontend-backend documentado. Antes de implementar endpoints reales o lógica de consumo en frontend, es necesario fijar un plan claro sobre qué datos se quieren mostrar, de qué fuentes podrían obtenerse, qué limitaciones existen y cuál será el orden recomendado de implementación.
-
-## Steps
-1. Revisar la documentación técnica actual del proyecto.
-2. Identificar qué información tendría sentido mostrar en la web sobre Discord. Incluir al menos posibles bloques como:
-   - enlace de invitación
-   - nombre de la comunidad
-   - estado o presencia aproximada si fuera viable
-   - información pública útil para comunidad
-3. Identificar qué información tendría sentido mostrar sobre los servidores de juego. Incluir al menos posibles bloques como:
-   - nombre del servidor
-   - estado online/offline
-   - mapa actual o rotación si fuera viable
-   - jugadores conectados
-   - capacidad máxima
-   - ping o metadatos similares si la fuente lo permite
-4. Documentar las posibles fuentes de datos para Discord, distinguiendo claramente entre:
-   - widget público
-   - API o integraciones externas
-   - bot propio
-   - datos configurados manualmente
-5. Documentar las posibles fuentes de datos para servidores de juego, distinguiendo claramente entre:
-   - consultas al servidor
-   - API externa
-   - datos mock/placeholder
-   - actualización manual
-6. Documentar riesgos, límites y restricciones:
-   - credenciales
-   - rate limits
-   - disponibilidad
-   - seguridad
-   - CORS
-   - latencia
-   - dependencia de servicios externos
-7. Proponer una estrategia por fases:
-   - fase inicial con placeholders o datos controlados
-   - fase intermedia con integración técnica limitada
-   - fase posterior con integración más real si procede
-8. Dejar claro qué NO se implementará todavía.
-9. Actualizar la documentación técnica del repositorio para que futuras tasks de backend y frontend tengan una base clara.
-
-## Files to Read First
-- README.md
-- AGENTS.md
-- docs/project-overview.md
-- docs/roadmap.md
-- docs/decisions.md
-- docs/frontend-backend-contract.md
-- ai/repo-context.md
-- ai/architecture-index.md
-- backend/README.md
-
-## Expected Files to Modify
-- docs/roadmap.md
-- docs/decisions.md
-- ai/architecture-index.md
-- opcionalmente un nuevo documento técnico si encaja mejor, por ejemplo:
-  - docs/discord-and-server-data-plan.md
-
-## Constraints
-- No implementar integraciones reales.
-- No modificar comportamiento del frontend.
-- No añadir endpoints funcionales nuevos.
-- No introducir dependencias nuevas.
-- No tocar base de datos.
-- No hacer cambios destructivos.
-- Mantener el resultado claro, útil y centrado en planificación técnica.
-
-## Validation
-- Existe una estrategia documentada para los datos futuros de Discord.
-- Existe una estrategia documentada para los datos futuros de servidores.
-- Se distinguen claramente fuentes posibles, riesgos y fases.
-- Queda explícito qué se hará primero y qué se pospone.
-- La documentación sirve como base directa para siguientes tasks técnicas.
-
-## Change Budget
-- Preferir menos de 5 archivos modificados o creados.
-- Preferir menos de 240 líneas cambiadas.

ai/tasks/done/TASK-007-backend-api-skeleton.md

@@ -1,66 +0,0 @@
-# TASK-007-backend-api-skeleton
-
-## Goal
-Preparar un esqueleto inicial de API en el backend Python para HLL Vietnam, dejando rutas y estructura listas para crecimiento posterior mediante respuestas placeholder o mock, sin integrar todavía Discord ni servidores reales.
-
-## Context
-El backend ya cuenta con un bootstrap mínimo y un endpoint de salud. El contrato frontend-backend ya define un conjunto inicial de endpoints previstos. El siguiente paso técnico es convertir esa definición en una estructura API básica y mantenible, con rutas organizadas y respuestas coherentes, aunque todavía sean estáticas o placeholder.
-
-## Steps
-1. Revisar el backend actual y la documentación del contrato frontend-backend.
-2. Confirmar el punto de entrada actual del backend y su estructura.
-3. Preparar una organización mínima para rutas API futuras dentro de `backend/app/`.
-4. Implementar o estructurar las rutas placeholder mínimas para:
-   - `GET /health`
-   - `GET /api/community`
-   - `GET /api/trailer`
-   - `GET /api/discord`
-   - `GET /api/servers`
-5. Hacer que las respuestas sean coherentes con el contrato ya documentado, aunque usen datos placeholder.
-6. Mantener una estructura clara para crecimiento posterior, por ejemplo separando:
-   - punto de entrada
-   - rutas
-   - utilidades o payloads placeholder si hiciera falta
-7. Actualizar la documentación del backend para reflejar la nueva estructura y cómo ejecutar la API localmente.
-8. Mantener el alcance estricto: esqueleto funcional, no integración real.
-
-## Files to Read First
-- AGENTS.md
-- docs/frontend-backend-contract.md
-- docs/project-overview.md
-- docs/decisions.md
-- ai/repo-context.md
-- ai/architecture-index.md
-- backend/README.md
-- backend/requirements.txt
-- backend/app/__init__.py
-- backend/app/main.py
-
-## Expected Files to Modify
-- backend/app/main.py
-- backend/app/__init__.py
-- backend/README.md
-- opcionalmente archivos nuevos dentro de `backend/app/` si mejoran claridad, por ejemplo:
-  - backend/app/routes.py
-  - backend/app/payloads.py
-
-## Constraints
-- No integrar Discord real.
-- No integrar servidores reales.
-- No añadir base de datos.
-- No introducir complejidad innecesaria.
-- No tocar frontend.
-- No añadir frameworks nuevos si no son estrictamente necesarios para mantener coherencia con el bootstrap actual.
-- No hacer cambios destructivos.
-- Mantener la API simple, clara y consistente con la documentación ya existente.
-
-## Validation
-- El backend expone claramente los endpoints placeholder definidos.
-- `GET /health` sigue funcionando correctamente.
-- Los endpoints futuros definidos en el contrato existen al menos como placeholders coherentes.
-- La estructura backend queda mejor preparada para crecimiento.
-- La documentación del backend refleja el nuevo estado real.
-
-## Change Budget
-- Preferir menos de 7 archivos modificados o creados.
-- Preferir menos de 260 líneas cambiadas.

ai/tasks/done/TASK-008-frontend-data-consumption-plan.md

@@ -1,68 +0,0 @@
-# TASK-008-frontend-data-consumption-plan
-
-## Goal
-Definir cómo consumirá el frontend de HLL Vietnam los futuros endpoints del backend, dejando documentada una estrategia clara de integración de datos sin implementar todavía lógica real de consumo.
-
-## Context
-Ya existe una landing mínima y se ha definido un contrato inicial entre frontend y backend. Además, se va a preparar un esqueleto API en backend. Antes de introducir JavaScript de consumo real o secciones dinámicas, conviene dejar documentado cómo deberá organizarse la integración en frontend para mantener simplicidad, claridad y consistencia con la evolución del proyecto.
-
-## Steps
-1. Revisar el frontend actual y el contrato frontend-backend.
-2. Identificar qué bloques del frontend actual o futuro podrán depender de datos dinámicos del backend.
-3. Definir una estrategia mínima de consumo de datos adecuada al proyecto en esta fase, por ejemplo:
-   - `fetch`
-   - JavaScript simple
-   - módulos ligeros si fueran necesarios más adelante
-4. Documentar cómo deberían gestionarse:
-   - estados de carga
-   - errores
-   - ausencia de datos
-   - placeholders
-   - fallback visual
-5. Documentar qué endpoints podrían ser consumidos primero y con qué prioridad:
-   - `/health`
-   - `/api/community`
-   - `/api/trailer`
-   - `/api/discord`
-   - `/api/servers`
-6. Proponer una estrategia progresiva para pasar de landing estática a bloques dinámicos sin romper simplicidad.
-7. Añadir o actualizar documentación técnica del frontend o del proyecto con esta estrategia.
-8. Mantener el alcance documental: no implementar todavía fetch real ni renderizado dinámico.
-
-## Files to Read First
-- AGENTS.md
-- README.md
-- docs/project-overview.md
-- docs/frontend-backend-contract.md
-- docs/decisions.md
-- ai/repo-context.md
-- ai/architecture-index.md
-- frontend/index.html
-- frontend/assets/js/main.js
-- frontend/assets/css/styles.css
-
-## Expected Files to Modify
-- docs/project-overview.md
-- docs/decisions.md
-- ai/architecture-index.md
-- opcionalmente un nuevo documento técnico si encaja mejor, por ejemplo:
-  - docs/frontend-data-consumption-plan.md
-
-## Constraints
-- No implementar consumo real de API.
-- No cambiar comportamiento visible del frontend.
-- No añadir librerías nuevas.
-- No rediseñar la landing.
-- No tocar backend salvo referencias documentales mínimas si son imprescindibles.
-- No hacer cambios destructivos.
-- Mantener la solución centrada en planificación de integración.
-
-## Validation
-- Existe una estrategia documentada para el consumo de datos en frontend.
-- Quedan definidos criterios para loading, error, empty state y fallback.
-- Se identifican prioridades de consumo de endpoints.
-- El frontend queda preparado conceptualmente para evolucionar sin improvisación.
-
-## Change Budget
-- Preferir menos de 5 archivos modificados o creados.
-- Preferir menos de 220 líneas cambiadas.

ai/tasks/done/TASK-009-backend-package-hygiene-and-entrypoint-alignment.md

@@ -1,55 +0,0 @@
-# TASK-009-backend-package-hygiene-and-entrypoint-alignment
-
-## Goal
-Corregir y alinear la estructura mínima del paquete backend en Python para HLL Vietnam, asegurando que el paquete, los imports y el entrypoint real sean consistentes, legibles y mantenibles.
-
-## Context
-El backend bootstrap y el esqueleto API placeholder ya existen, pero en resúmenes recientes aparece una posible inconsistencia con el archivo de paquete Python (`init.py` frente a `__init__.py`). Antes de continuar con más ajustes o integrar consumo desde frontend, es importante dejar la base del paquete limpia y sin ambigüedades.
-
-## Steps
-1. Revisar la estructura actual de `backend/app/`.
-2. Confirmar si el archivo correcto del paquete existe como:
-   - `backend/app/__init__.py`
-3. Si existe cualquier inconsistencia de naming o packaging, corregirla.
-4. Revisar y alinear los imports internos del backend para que sean coherentes con la estructura final.
-5. Confirmar cuál es el entrypoint real del backend y dejarlo claro en la documentación.
-6. Revisar el comando de arranque documentado y adaptarlo si fuera necesario.
-7. Validar que los endpoints placeholder actuales siguen funcionando tras el ajuste.
-8. Mantener el cambio pequeño y centrado en higiene estructural, no en nuevas funcionalidades.
-
-## Files to Read First
-- AGENTS.md
-- ai/repo-context.md
-- ai/architecture-index.md
-- backend/README.md
-- backend/requirements.txt
-- backend/app/__init__.py
-- backend/app/main.py
-- backend/app/routes.py
-- backend/app/payloads.py
-
-## Expected Files to Modify
-- backend/app/__init__.py
-- backend/app/main.py
-- backend/app/routes.py
-- backend/README.md
-- opcionalmente otros archivos internos del backend si son estrictamente necesarios para alinear imports y entrypoint
-
-## Constraints
-- No añadir integraciones reales.
-- No introducir dependencias nuevas innecesarias.
-- No tocar frontend.
-- No añadir base de datos.
-- No hacer cambios destructivos fuera del alcance del paquete backend.
-- Mantener el backend simple y consistente con la fase actual.
-
-## Validation
-- Existe un archivo de paquete Python correcto en `backend/app/__init__.py`.
-- No quedan referencias ambiguas o incorrectas al package layout.
-- El entrypoint del backend está claro.
-- Los endpoints placeholder actuales siguen respondiendo.
-- La documentación del backend refleja el estado real.
-
-## Change Budget
-- Preferir menos de 5 archivos modificados.
-- Preferir menos de 160 líneas cambiadas.

ai/tasks/done/TASK-010-backend-local-dev-config-and-cors-bootstrap.md

@@ -1,55 +0,0 @@
-# TASK-010-backend-local-dev-config-and-cors-bootstrap
-
-## Goal
-Preparar la configuración mínima de desarrollo local del backend para HLL Vietnam, incluyendo parámetros básicos de ejecución y soporte controlado para consumo desde frontend local durante la fase de desarrollo.
-
-## Context
-El proyecto ya tiene frontend estático y backend placeholder. El siguiente paso para permitir un primer enlace real entre ambos es dejar clara la forma de ejecución local y, si aplica, habilitar el mínimo soporte técnico necesario para consultas desde frontend local, evitando problemas básicos de entorno o de origen cruzado en desarrollo.
-
-## Steps
-1. Revisar cómo se ejecuta actualmente el backend.
-2. Definir y documentar claramente:
-   - host por defecto
-   - puerto por defecto
-   - comando de arranque local
-3. Revisar si el frontend local necesitará consumir el backend desde distinto origen durante desarrollo.
-4. Si hace falta, añadir una solución mínima y controlada para CORS o para origen local de desarrollo, sin sobredimensionar el sistema.
-5. Mantener la configuración simple y enfocada al entorno local.
-6. Actualizar la documentación relevante para que levantar el stack local sea fácil.
-7. No introducir complejidad de producción en esta fase.
-
-## Files to Read First
-- README.md
-- AGENTS.md
-- ai/repo-context.md
-- docs/project-overview.md
-- docs/frontend-backend-contract.md
-- backend/README.md
-- backend/app/main.py
-- backend/app/routes.py
-
-## Expected Files to Modify
-- backend/README.md
-- backend/app/main.py
-- opcionalmente un archivo nuevo de configuración mínima si mejora claridad, por ejemplo:
-  - backend/app/config.py
-- opcionalmente documentación raíz si conviene reflejar arranque local combinado
-
-## Constraints
-- No integrar Discord real.
-- No integrar servidores reales.
-- No añadir base de datos.
-- No añadir frameworks nuevos salvo que sean estrictamente necesarios y coherentes con la base ya existente.
-- No tocar el comportamiento visible del frontend todavía.
-- No hacer cambios destructivos.
-- Mantener la configuración pequeña, clara y orientada a desarrollo local.
-
-## Validation
-- El backend tiene host/puerto local claramente definidos o documentados.
-- Existe una forma clara de levantarlo en local.
-- Si el frontend necesita consultar el backend desde otro origen, la solución mínima está resuelta o documentada.
-- El proyecto queda listo para un primer consumo real desde frontend en una task posterior inmediata.
-
-## Change Budget
-- Preferir menos de 5 archivos modificados o creados.
-- Preferir menos de 180 líneas cambiadas.

ai/tasks/done/TASK-011-frontend-health-and-trailer-progressive-enhancement.md

@@ -1,60 +0,0 @@
-# TASK-011-frontend-health-and-trailer-progressive-enhancement
-
-## Goal
-Realizar el primer enlace real entre frontend y backend en HLL Vietnam mediante una mejora progresiva y controlada, consultando el estado del backend y, de forma opcional, el endpoint placeholder del tráiler, sin romper la landing estática actual.
-
-## Context
-La landing actual ya funciona como página estática simple con logo, botón de Discord y tráiler embebido. El backend ya dispone de un bootstrap y de endpoints placeholder. El siguiente ajuste lógico es introducir una mejora progresiva mínima desde `frontend/assets/js/main.js`, manteniendo fallback estático cuando el backend no esté disponible.
-
-## Steps
-1. Revisar el frontend actual y el plan de consumo de datos.
-2. Revisar el backend actual y el contrato frontend-backend.
-3. Preparar en `main.js` una integración mínima con el backend, manteniendo la simplicidad del proyecto.
-4. Consultar al menos:
-   - `GET /health`
-5. Evaluar si también conviene consumir:
-   - `GET /api/trailer`
-   siempre manteniendo fallback estático en el HTML.
-6. Añadir una señal visual mínima, discreta y no intrusiva para reflejar estado del backend si la integración lo justifica.
-7. Asegurar que, si el backend no está disponible, la landing sigue funcionando exactamente como página estática.
-8. No introducir todavía integración real de Discord ni servidores.
-9. Mantener intacta la identidad visual general de la landing.
-
-## Files to Read First
-- AGENTS.md
-- ai/repo-context.md
-- docs/frontend-backend-contract.md
-- docs/frontend-data-consumption-plan.md
-- frontend/index.html
-- frontend/assets/js/main.js
-- frontend/assets/css/styles.css
-- backend/app/main.py
-- backend/app/routes.py
-- backend/app/payloads.py
-
-## Expected Files to Modify
-- frontend/index.html
-- frontend/assets/js/main.js
-- frontend/assets/css/styles.css
-- opcionalmente documentación mínima si fuera necesario reflejar el comportamiento progresivo
-
-## Constraints
-- No rediseñar la landing completa.
-- No añadir nuevas secciones grandes.
-- No integrar Discord real.
-- No integrar servidores reales.
-- No añadir librerías nuevas.
-- No romper el funcionamiento estático actual.
-- No hacer cambios destructivos.
-- Mantener la mejora contenida y reversible.
-
-## Validation
-- La landing sigue funcionando aunque el backend no esté disponible.
-- El frontend puede consultar `/health` correctamente cuando el backend está levantado.
-- El comportamiento visual añadido es discreto y coherente.
-- El tráiler y el botón de Discord siguen funcionando.
-- La solución sienta la base para consumos reales futuros sin introducir complejidad excesiva.
-
-## Change Budget
-- Preferir menos de 4 archivos modificados.
-- Preferir menos de 200 líneas cambiadas.

ai/tasks/done/TASK-012-current-hll-servers-source-plan.md

@@ -1,72 +0,0 @@
-# TASK-012-current-hll-servers-source-plan
-
-## Goal
-Definir la estrategia técnica y de producto para mostrar en la web de HLL Vietnam un bloque provisional de servidores actuales de Hell Let Loose, diferenciándolos claramente del futuro contexto Vietnam y sin implementar todavía integración real definitiva.
-
-## Context
-A día de hoy el foco temático del proyecto es HLL Vietnam, pero todavía no existen servidores reales de ese entorno para consumirlos como fuente del producto. Como solución provisional y útil para la comunidad, se quiere mostrar información de servidores actuales de Hell Let Loose, dejando claro que se trata de servidores del juego actual y no de HLL Vietnam. Antes de construir integración backend o UI final, hay que documentar fuente, campos, límites y estrategia de sustitución futura.
-
-## Steps
-1. Revisar la documentación actual del proyecto y la estrategia de datos ya definida.
-2. Documentar el objetivo del bloque provisional de servidores actuales de HLL.
-3. Definir claramente cómo debe presentarse en producto para evitar confusión con HLL Vietnam.
-4. Identificar qué campos tiene sentido mostrar en esta fase. Incluir al menos:
-   - nombre del servidor
-   - estado online/offline
-   - jugadores actuales
-   - capacidad máxima
-   - mapa actual si está disponible
-   - región o etiqueta útil si existe
-5. Documentar las posibles fuentes de esos datos, distinguiendo entre:
-   - fuente externa pública
-   - datos controlados o placeholder
-   - integración futura más robusta
-6. Documentar riesgos y restricciones:
-   - disponibilidad de terceros
-   - CORS
-   - rate limits
-   - estabilidad del formato
-   - dependencia de scraping o fuentes no oficiales
-7. Proponer una estrategia por fases:
-   - fase 1: payload controlado/mock con forma realista
-   - fase 2: adaptador backend para fuente externa o dataset controlado
-   - fase 3: sustitución por datos más cercanos a HLL Vietnam cuando existan
-8. Dejar claro qué no se implementará todavía.
-9. Actualizar documentación técnica del repositorio para que siguientes tasks tengan base clara.
-
-## Files to Read First
-- README.md
-- AGENTS.md
-- docs/project-overview.md
-- docs/roadmap.md
-- docs/decisions.md
-- docs/frontend-backend-contract.md
-- docs/discord-and-server-data-plan.md
-- ai/repo-context.md
-- ai/architecture-index.md
-- backend/README.md
-
-## Expected Files to Modify
-- docs/roadmap.md
-- docs/decisions.md
-- ai/architecture-index.md
-- opcionalmente un nuevo documento técnico si encaja mejor, por ejemplo:
-  - docs/current-hll-servers-source-plan.md
-
-## Constraints
-- No implementar integración real todavía.
-- No modificar comportamiento visible del frontend.
-- No añadir dependencias nuevas.
-- No tocar base de datos.
-- No hacer cambios destructivos.
-- Mantener el resultado centrado en planificación técnica y de producto.
-
-## Validation
-- Existe una estrategia documentada para mostrar servidores actuales de Hell Let Loose como contenido provisional.
-- Queda claramente diferenciada la identidad de HLL actual frente a HLL Vietnam.
-- Se documentan campos, fuentes, riesgos y fases.
-- La documentación sirve como base directa para una task backend y una task frontend posteriores.
-
-## Change Budget
-- Preferir menos de 5 archivos modificados o creados.
-- Preferir menos de 220 líneas cambiadas.

ai/tasks/done/TASK-013-backend-current-hll-servers-placeholder-adapter.md

@@ -1,57 +0,0 @@
-# TASK-013-backend-current-hll-servers-placeholder-adapter
-
-## Goal
-Preparar en el backend Python un adaptador placeholder limpio y consistente para exponer al frontend una lista provisional de servidores actuales de Hell Let Loose, sin integrar todavía una fuente externa real.
-
-## Context
-El backend ya dispone de un esqueleto API y de endpoints placeholder. Se ha decidido que la web podrá mostrar, de forma provisional, servidores actuales de Hell Let Loose mientras no existan datos reales de HLL Vietnam. Antes de conectar fuentes externas, conviene preparar un adaptador backend limpio que devuelva datos controlados con una estructura estable y preparada para sustitución futura.
-
-## Steps
-1. Revisar el backend actual, especialmente el endpoint relacionado con servidores y los payloads placeholder existentes.
-2. Revisar la documentación del contrato frontend-backend y el plan de servidores actuales.
-3. Definir una estructura clara y estable para el payload de servidores actuales de HLL.
-4. Ajustar el backend para que `GET /api/servers` devuelva una respuesta coherente con ese modelo provisional.
-5. Asegurar que el payload distinga claramente que se trata de servidores actuales de Hell Let Loose y no de HLL Vietnam, si esa distinción encaja en el modelo.
-6. Mantener la implementación desacoplada para que más adelante pueda sustituirse la fuente sin romper al frontend.
-7. Actualizar la documentación backend si el comportamiento real del endpoint cambia respecto a lo documentado.
-8. Mantener el alcance estricto: adaptador placeholder estable, no integración real.
-
-## Files to Read First
-- AGENTS.md
-- docs/frontend-backend-contract.md
-- docs/discord-and-server-data-plan.md
-- docs/current-hll-servers-source-plan.md
-- ai/repo-context.md
-- ai/architecture-index.md
-- backend/README.md
-- backend/app/__init__.py
-- backend/app/main.py
-- backend/app/routes.py
-- backend/app/payloads.py
-- backend/app/config.py
-
-## Expected Files to Modify
-- backend/app/routes.py
-- backend/app/payloads.py
-- backend/app/main.py
-- backend/README.md
-- opcionalmente documentación contractual o técnica si necesita alineación menor
-
-## Constraints
-- No integrar todavía una fuente externa real.
-- No añadir scraping.
-- No añadir base de datos.
-- No tocar frontend en esta task.
-- No introducir complejidad innecesaria.
-- No hacer cambios destructivos.
-- Mantener la API simple, estable y preparada para evolución posterior.
-
-## Validation
-- `GET /api/servers` devuelve un payload placeholder más consistente y útil.
-- La respuesta está preparada para consumo frontend.
-- La estructura deja claro que el contenido actual es provisional y basado en servidores actuales de HLL.
-- La documentación backend refleja el estado real del endpoint si cambió.
-
-## Change Budget
-- Preferir menos de 5 archivos modificados.
-- Preferir menos de 180 líneas cambiadas.

ai/tasks/done/TASK-014-landing-current-hll-servers-panel.md

@@ -1,61 +0,0 @@
-# TASK-014-landing-current-hll-servers-panel
-
-## Goal
-Añadir a la landing de HLL Vietnam un panel visual de servidores actuales de Hell Let Loose, alimentado por el backend placeholder, dejando claro que se trata de contenido provisional mientras no existan datos reales de HLL Vietnam.
-
-## Context
-La landing ya dispone de una mejora progresiva frontend-backend y el backend puede exponer endpoints placeholder. El proyecto necesita empezar a mostrar información más útil y dinámica, pero sin fingir que ya existen servidores de HLL Vietnam. Esta task debe introducir un bloque visual controlado que muestre servidores actuales de HLL como referencia provisional para la comunidad.
-
-## Steps
-1. Revisar la landing actual, los estilos y la mejora progresiva ya implementada en frontend.
-2. Revisar el payload real o previsto de `GET /api/servers`.
-3. Añadir un bloque visual nuevo en la landing para mostrar servidores actuales de Hell Let Loose.
-4. Hacer que el frontend consuma `GET /api/servers` de forma progresiva, manteniendo fallback seguro si el backend no está disponible.
-5. Mostrar de forma clara y ordenada, como mínimo:
-   - nombre del servidor
-   - estado
-   - jugadores
-   - capacidad máxima
-   - mapa si está disponible
-6. Añadir una etiqueta o texto breve que deje claro que son servidores actuales de Hell Let Loose usados como referencia provisional.
-7. Mantener coherencia visual con la identidad militar sobria del proyecto.
-8. Asegurar que la landing siga funcionando si el backend no responde o si no hay datos.
-9. No tocar todavía integración real de Discord ni fuentes externas reales.
-
-## Files to Read First
-- AGENTS.md
-- ai/repo-context.md
-- docs/frontend-backend-contract.md
-- docs/frontend-data-consumption-plan.md
-- docs/current-hll-servers-source-plan.md
-- frontend/index.html
-- frontend/assets/js/main.js
-- frontend/assets/css/styles.css
-- backend/app/routes.py
-- backend/app/payloads.py
-
-## Expected Files to Modify
-- frontend/index.html
-- frontend/assets/js/main.js
-- frontend/assets/css/styles.css
-- opcionalmente documentación mínima si fuera necesario reflejar el nuevo bloque
-
-## Constraints
-- No rediseñar completamente la landing.
-- No añadir librerías nuevas.
-- No romper el fallback estático actual.
-- No presentar esos servidores como si fueran de HLL Vietnam.
-- No integrar fuentes externas reales directamente desde frontend.
-- No hacer cambios destructivos.
-- Mantener la mejora acotada, clara y coherente con la fase actual.
-
-## Validation
-- La landing muestra un panel de servidores actuales de HLL de forma clara.
-- El panel obtiene datos desde `GET /api/servers` cuando el backend está disponible.
-- Si el backend no está disponible, la landing sigue funcionando sin romperse.
-- La UI deja claro que se trata de contenido provisional.
-- La integración visual es coherente con el resto de la página.
-
-## Change Budget
-- Preferir menos de 4 archivos modificados.
-- Preferir menos de 220 líneas cambiadas.

ai/tasks/done/TASK-015-landing-visual-system-pass.md

@@ -1,66 +0,0 @@
-# TASK-015-landing-visual-system-pass
-
-## Goal
-Realizar una pasada de sistema visual sobre la landing de HLL Vietnam para reforzar identidad, consistencia, contraste y jerarquia general, manteniendo el alcance actual del producto y sin cambiar la arquitectura funcional.
-
-## Context
-La landing ya cuenta con logo, trailer, CTA de Discord, estado de backend y panel provisional de servidores actuales de Hell Let Loose. La base funcional existe, pero ahora hace falta una pasada centrada unicamente en calidad visual para que la web tenga una presentacion mas solida, coherente y atractiva dentro del tono militar/tactico del proyecto.
-
-## Steps
-1. Revisar la composicion visual global de la landing actual.
-2. Revisar la paleta actual, contraste, espaciados, tipografias, contenedores y ritmo vertical.
-3. Refinar el sistema visual general sin redisenar por completo la pagina.
-4. Mejorar:
-   - jerarquia tipografica
-   - espaciado entre bloques
-   - consistencia entre tarjetas y paneles
-   - contraste entre fondo, texto y elementos destacados
-   - sensacion visual militar sobria y cinematografica
-5. Mantener una estetica oscura, tactica y limpia, evitando recargar la pagina.
-6. Asegurar que todos los bloques principales compartan un lenguaje visual coherente.
-7. Validar que el resultado siga funcionando bien en escritorio y movil.
-8. No cambiar el alcance funcional del producto.
-
-## Files to Read First
-- AGENTS.md
-- ai/repo-context.md
-- docs/project-overview.md
-- frontend/index.html
-- frontend/assets/css/styles.css
-- frontend/assets/js/main.js
-
-## Expected Files to Modify
-- frontend/index.html
-- frontend/assets/css/styles.css
-
-## Constraints
-- No anadir nuevas funcionalidades.
-- No cambiar endpoints ni logica backend.
-- No introducir librerias nuevas.
-- No cambiar el flujo funcional de la landing.
-- No reescribir toda la estructura HTML salvo ajustes razonables para mejorar composicion.
-- No hacer cambios destructivos.
-- Mantener el diseno dentro del tono HLL Vietnam.
-
-## Validation
-- La landing tiene una apariencia mas coherente y profesional.
-- La jerarquia visual es mas clara.
-- El contraste y la legibilidad mejoran.
-- La identidad militar/tactica queda reforzada.
-- No se rompe ninguna funcionalidad existente.
-- La landing sigue viendose correctamente en movil y escritorio.
-
-## Change Budget
-- Preferir menos de 3 archivos modificados.
-- Preferir menos de 220 lineas cambiadas.
-
-## Outcome
-- Se reforzo el sistema visual general de la landing sin cambiar su alcance funcional.
-- Se ajusto la jerarquia visual entre hero, panel de trailer y panel de servidores para que compartan mejor lenguaje visual.
-- Se mejoraron contraste, ritmo vertical, bordes, sombras y consistencia de contenedores dentro del tono militar sobrio del proyecto.
-
-## Validation Notes
-- `git diff --name-only -- frontend/index.html frontend/assets/css/styles.css` devuelve solo los archivos esperados por la task.
-- Se reviso el CSS para mantener compatibilidad responsive en escritorio y movil mediante los breakpoints existentes.
-- No se cambiaron endpoints, logica backend ni comportamiento funcional de la landing.
-- No hay pruebas automaticas configuradas para este ajuste visual; la validacion disponible en esta task es revision de alcance y consistencia del marcado y CSS.

ai/tasks/done/TASK-016-hero-logo-and-trailer-cinematic-polish.md

@@ -1,73 +0,0 @@
-# TASK-016-hero-logo-and-trailer-cinematic-polish
-
-## Goal
-Mejorar visualmente el bloque principal de la landing de HLL Vietnam, con foco en hero, logo y trailer, para darle una presencia mas cinematografica, mas inmersiva y mas propia de una comunidad tactica.
-
-## Context
-El usuario quiere priorizar el ajuste visual. El hero actual ya funciona, pero debe ganar impacto sin perder simplicidad. El logo debe sentirse mas protagonista, el bloque del trailer debe integrarse mejor en la composicion y el conjunto debe transmitir mejor el tono del proyecto.
-
-## Steps
-1. Revisar la composicion actual del hero.
-2. Revisar el tratamiento visual del logo:
-   - tamano
-   - posicion
-   - marco
-   - sombra
-   - integracion con el fondo
-3. Revisar el tratamiento visual del trailer:
-   - contenedor
-   - marco
-   - separacion respecto al resto
-   - equilibrio con el CTA y el titulo
-4. Mejorar la presencia del bloque principal sin anadir secciones nuevas.
-5. Reforzar:
-   - impacto inicial
-   - sensacion de identidad
-   - claridad del CTA principal
-   - integracion visual entre logo, titulo y video
-6. Mantener el diseno sobrio, sin caer en efectos exagerados.
-7. Validar que la composicion siga siendo responsive y estable.
-
-## Files to Read First
-- AGENTS.md
-- ai/repo-context.md
-- frontend/index.html
-- frontend/assets/css/styles.css
-- frontend/assets/js/main.js
-
-## Expected Files to Modify
-- frontend/index.html
-- frontend/assets/css/styles.css
-
-## Constraints
-- No cambiar la ruta del logo.
-- No cambiar el enlace de Discord.
-- No cambiar el enlace del trailer.
-- No anadir nuevas funcionalidades.
-- No romper el fallback actual.
-- No usar librerias nuevas.
-- No hacer cambios destructivos.
-- Mantener la landing simple.
-
-## Validation
-- El hero tiene mas presencia visual.
-- El logo se percibe mejor integrado y mas protagonista.
-- El trailer se siente mejor enmarcado dentro del diseno.
-- El CTA sigue siendo claro y visible.
-- El resultado mantiene coherencia con el tono militar/tactico del proyecto.
-- La composicion funciona en desktop y mobile.
-
-## Change Budget
-- Preferir menos de 2 archivos modificados.
-- Preferir menos de 180 lineas cambiadas.
-
-## Outcome
-- Se reorganizo el bloque principal para agrupar mejor estado backend y CTA sin cambiar su funcionamiento.
-- Se reforzo el tratamiento visual del logo con un marco mas trabajado, sombras mas controladas y una mejor integracion con el fondo del hero.
-- Se ajusto el panel de trailer para que se sienta mas cinematografico y mejor conectado con la identidad visual del hero.
-
-## Validation Notes
-- `git diff --name-only -- frontend/index.html frontend/assets/css/styles.css` devuelve solo los archivos esperados por la task.
-- Se confirmo que no se cambiaron la ruta del logo, el enlace de Discord ni la URL del trailer.
-- La task se mantuvo en cambios de composicion y estilo; no se altero el fallback ni la logica existente.
-- No hay pruebas automaticas especificas para esta composicion; la validacion disponible es revision estructural de HTML/CSS y del alcance del diff.

ai/tasks/done/TASK-017-server-panel-visual-polish-and-responsive-pass.md

@@ -1,69 +0,0 @@
-# TASK-017-server-panel-visual-polish-and-responsive-pass
-
-## Goal
-Pulir visualmente el panel de servidores actuales de Hell Let Loose y mejorar su comportamiento responsive para que se integre mejor con el resto de la landing y se vea claro, ordenado y fiable.
-
-## Context
-El panel de servidores ya existe y consume datos del backend placeholder con fallback estatico. Ahora hace falta una pasada especifica de UI para que las tarjetas o elementos del panel tengan una presentacion mas clara y mas profesional, sin tocar todavia estrategia de copy ni fuentes reales de datos.
-
-## Steps
-1. Revisar el marcado actual del panel de servidores en la landing.
-2. Revisar como se renderizan los datos desde frontend.
-3. Mejorar visualmente:
-   - tarjetas o filas de servidor
-   - jerarquia de nombre, estado, jugadores y mapa
-   - badges o indicadores de estado
-   - separacion entre items
-   - integracion con el resto de la landing
-4. Mejorar el comportamiento responsive del panel:
-   - anchuras
-   - apilado
-   - legibilidad en movil
-   - consistencia de espaciados
-5. Mantener claro que se trata de un bloque provisional sin tocar todavia el copy estrategico en profundidad.
-6. Respetar el fallback actual si el backend no responde.
-7. No cambiar el alcance funcional del panel.
-
-## Files to Read First
-- AGENTS.md
-- ai/repo-context.md
-- frontend/index.html
-- frontend/assets/css/styles.css
-- frontend/assets/js/main.js
-- backend/app/payloads.py
-
-## Expected Files to Modify
-- frontend/index.html
-- frontend/assets/css/styles.css
-- frontend/assets/js/main.js
-
-## Constraints
-- No cambiar el contrato del backend.
-- No tocar payloads backend.
-- No anadir librerias nuevas.
-- No romper el fallback estatico.
-- No presentar estos servidores como si fueran de HLL Vietnam.
-- No hacer cambios destructivos.
-- Mantener el ajuste centrado en UI y responsive.
-
-## Validation
-- El panel de servidores se ve mas limpio y claro.
-- La lectura de estado, jugadores y mapa mejora.
-- El panel responde bien en movil y escritorio.
-- El fallback sigue funcionando.
-- La integracion visual con la landing es mejor que antes.
-
-## Change Budget
-- Preferir menos de 3 archivos modificados.
-- Preferir menos de 200 lineas cambiadas.
-
-## Outcome
-- Se mejoro la jerarquia visual de cada servidor con identidad, estado mas legible y mejor separacion entre bloques de datos.
-- Se anadio un indicador visual de ocupacion basado en los datos ya disponibles sin cambiar el contrato del backend.
-- Se alineo el markup estatico de `index.html` con el render dinamico de `main.js` para mantener el mismo acabado cuando el backend esta disponible o no.
-
-## Validation Notes
-- `git diff --name-only -- frontend/index.html frontend/assets/css/styles.css frontend/assets/js/main.js` devuelve solo los archivos esperados por la task.
-- `node --check frontend\\assets\\js\\main.js` se ejecuto correctamente.
-- No se modifico `backend/app/payloads.py` ni el contrato del backend.
-- El fallback estatico se conserva porque el HTML base y el render dinamico usan la misma estructura visual del panel.

ai/tasks/done/TASK-018-current-hll-data-ingestion-plan.md

@@ -1,74 +0,0 @@
-# TASK-018-current-hll-data-ingestion-plan
-
-## Goal
-Definir la estrategia técnica de ingesta de datos para Hell Let Loose actual, usándolo como banco de pruebas del proyecto HLL Vietnam, con foco en servidores, snapshots e históricos básicos sin implementar todavía la ingesta real completa.
-
-## Context
-La landing ya muestra servidores actuales de HLL como contenido provisional y el backend ya dispone de una base API placeholder. El siguiente paso lógico es fijar cómo se obtendrán y normalizarán datos reales o semirrealistas de HLL actual para validar la arquitectura que más adelante podrá reutilizarse con HLL Vietnam.
-
-## Steps
-1. Revisar la documentación actual del proyecto relacionada con servidores, backend y evolución de datos.
-2. Definir qué tipos de datos se quieren ingerir inicialmente desde HLL actual. Incluir al menos:
-   - listado de servidores
-   - estado online/offline
-   - jugadores actuales
-   - capacidad máxima
-   - mapa actual si está disponible
-   - timestamp de captura
-3. Definir el concepto de snapshot de servidor y cómo se usará para construir histórico.
-4. Documentar las posibles fuentes técnicas de ingesta para HLL actual, distinguiendo entre:
-   - datos controlados/mock
-   - fuente externa pública
-   - consulta directa de servidor o capa intermedia
-5. Documentar riesgos y límites:
-   - disponibilidad de terceros
-   - cambios de formato
-   - rate limits
-   - latencia
-   - CORS
-   - fiabilidad de datos
-   - dependencia de scraping o APIs no oficiales
-6. Proponer la arquitectura de ingesta por fases:
-   - fase 1: payload controlado y estructura estable
-   - fase 2: colector de snapshots con fuente real o casi real
-   - fase 3: explotación histórica y estadísticas básicas
-7. Dejar claro qué no se implementará todavía.
-8. Actualizar la documentación técnica del repositorio para servir de base a las siguientes tasks de base de datos y colector.
-
-## Files to Read First
-- README.md
-- AGENTS.md
-- docs/project-overview.md
-- docs/roadmap.md
-- docs/decisions.md
-- docs/discord-and-server-data-plan.md
-- docs/current-hll-servers-source-plan.md
-- docs/frontend-backend-contract.md
-- ai/repo-context.md
-- ai/architecture-index.md
-- backend/README.md
-
-## Expected Files to Modify
-- docs/roadmap.md
-- docs/decisions.md
-- ai/architecture-index.md
-- opcionalmente un nuevo documento técnico si encaja mejor, por ejemplo:
-  - docs/current-hll-data-ingestion-plan.md
-
-## Constraints
-- No implementar todavía ingesta real.
-- No modificar comportamiento visible del frontend.
-- No añadir base de datos funcional en esta task.
-- No añadir dependencias nuevas.
-- No hacer cambios destructivos.
-- Mantener el resultado centrado en planificación técnica reutilizable para futuro HLL Vietnam.
-
-## Validation
-- Existe una estrategia documentada de ingesta para HLL actual como banco de pruebas.
-- Quedan definidos snapshots, fuentes posibles, riesgos y fases.
-- La documentación deja claro cómo se conectará este trabajo con almacenamiento e históricos.
-- La base sirve para una siguiente task de esquema de base de datos.
-
-## Change Budget
-- Preferir menos de 5 archivos modificados o creados.
-- Preferir menos de 240 líneas cambiadas.

ai/tasks/done/TASK-018-hero-layout-rebalance.md

@@ -1,57 +0,0 @@
-# TASK-018-hero-layout-rebalance
-
-## Goal
-Reequilibrar la composición visual del hero de la landing de HLL Vietnam para darle más impacto, reducir sensación de vacío vertical y mejorar la relación entre logo, titular, subtítulo y CTA principal.
-
-## Context
-La landing ya tiene una base visual sólida, pero el hero actual presenta varios puntos de mejora: demasiado espacio vertical, un titular muy dominante partido en varias líneas, un logo con menos protagonismo del deseado y una composición general menos potente que el resto de la página. Esta task debe centrarse únicamente en recomponer el bloque principal para que se perciba como una cabecera premium, más compacta y más cinematográfica, sin cambiar el alcance funcional actual.
-
-## Steps
-1. Revisar la composición actual del hero en la landing.
-2. Evaluar el equilibrio visual entre:
-   - logo
-   - eyebrow o etiqueta superior
-   - título principal
-   - subtítulo o texto descriptivo
-   - chip de estado backend si aplica
-   - CTA principal
-3. Reducir la sensación de vacío vertical y mejorar el ritmo del bloque.
-4. Ajustar el protagonismo del logo para que se sienta más integrado y relevante.
-5. Ajustar el titular para que mantenga fuerza, pero no rompa la composición ni monopolice toda la jerarquía visual.
-6. Reordenar o afinar espaciados, anchuras máximas y alineaciones para que el conjunto se perciba más compacto y más intencional.
-7. Mantener el hero claro, centrado en comunidad, branding y CTA.
-8. Validar que la composición siga funcionando bien en móvil y escritorio.
-9. No alterar enlaces, rutas ni comportamiento funcional existente.
-
-## Files to Read First
-- AGENTS.md
-- ai/repo-context.md
-- frontend/index.html
-- frontend/assets/css/styles.css
-- frontend/assets/js/main.js
-
-## Expected Files to Modify
-- frontend/index.html
-- frontend/assets/css/styles.css
-
-## Constraints
-- No cambiar la ruta del logo.
-- No cambiar el enlace del Discord.
-- No cambiar el enlace del tráiler.
-- No añadir nuevas secciones.
-- No introducir librerías nuevas.
-- No romper el fallback actual.
-- No hacer cambios destructivos.
-- Mantener la landing simple y coherente con el tono HLL Vietnam.
-
-## Validation
-- El hero se siente más compacto y más fuerte visualmente.
-- El logo tiene mejor presencia relativa.
-- El titular sigue siendo potente pero está mejor equilibrado.
-- El CTA sigue siendo claro y visible.
-- La cabecera transmite más sensación de portada principal.
-- La composición sigue siendo responsive y estable.
-
-## Change Budget
-- Preferir menos de 2 archivos modificados.
-- Preferir menos de 170 líneas cambiadas.

ai/tasks/done/TASK-019-atmospheric-depth-pass.md

@@ -1,56 +0,0 @@
-# TASK-019-atmospheric-depth-pass
-
-## Goal
-Aumentar la profundidad visual y la atmósfera general de la landing de HLL Vietnam mediante un refinamiento controlado de fondo, overlays, iluminación y separación de planos, sin recargar la interfaz ni romper su sobriedad.
-
-## Context
-La paleta actual funciona y la base visual está bien encaminada, pero el fondo y el marco general aún se perciben algo planos. Hace falta una pasada de atmósfera para reforzar el tono Vietnam/táctico, mejorar la profundidad percibida y dar más cohesión al conjunto, especialmente alrededor del hero y de las secciones principales.
-
-## Steps
-1. Revisar el tratamiento actual del fondo y los overlays.
-2. Evaluar cómo se perciben:
-   - profundidad
-   - viñeteado
-   - textura ambiental
-   - degradados
-   - separación entre hero y secciones
-3. Refinar el sistema de fondo para aportar más atmósfera sin saturar.
-4. Aplicar mejoras controladas en:
-   - overlays
-   - sombras de entorno
-   - iluminación indirecta
-   - separación de bloques
-   - sensación cinematográfica
-5. Mantener una estética oscura, militar y limpia.
-6. Evitar efectos exagerados, brillos excesivos o ruido visual.
-7. Validar que el resultado no perjudica legibilidad ni rendimiento aparente.
-8. Mantener intacto el comportamiento funcional de la landing.
-
-## Files to Read First
-- AGENTS.md
-- ai/repo-context.md
-- frontend/index.html
-- frontend/assets/css/styles.css
-
-## Expected Files to Modify
-- frontend/assets/css/styles.css
-- opcionalmente `frontend/index.html` si hiciera falta una envolvente mínima o ajuste estructural pequeño para soportar mejor la profundidad visual
-
-## Constraints
-- No cambiar contenido funcional.
-- No añadir imágenes nuevas ni dependencias nuevas salvo que sea estrictamente innecesario.
-- No rediseñar completamente la página.
-- No tocar backend.
-- No hacer cambios destructivos.
-- Mantener el tono sobrio y cinematográfico.
-
-## Validation
-- La página transmite mayor profundidad visual.
-- El fondo se siente menos plano.
-- Hero y secciones se perciben mejor separados y más cohesionados.
-- La atmósfera Vietnam/táctica queda reforzada.
-- La legibilidad y claridad general se mantienen o mejoran.
-
-## Change Budget
-- Preferir menos de 2 archivos modificados.
-- Preferir menos de 160 líneas cambiadas.

ai/tasks/done/TASK-019-stats-database-schema-foundation.md

@@ -1,65 +0,0 @@
-# TASK-019-stats-database-schema-foundation
-
-## Goal
-Diseñar y dejar preparada la base del esquema de almacenamiento para snapshots y estadísticas iniciales de servidores de HLL actual, con una modelización genérica que pueda reutilizarse en el futuro para HLL Vietnam.
-
-## Context
-El proyecto necesita pasar de payloads placeholder a una arquitectura capaz de almacenar históricos. Antes de implementar colectores reales, es necesario definir un esquema de datos claro, neutro y extensible para snapshots de servidores y primeras métricas agregadas.
-
-## Steps
-1. Revisar la documentación técnica actual sobre backend, contratos y plan de ingesta.
-2. Definir las entidades mínimas necesarias para la primera fase de persistencia. Incluir al menos:
-   - game o source context si aplica
-   - servers
-   - server_snapshots
-   - posibles tablas de agregación inicial o vistas documentadas para estadísticas
-3. Asegurar que el naming sea genérico y reutilizable, evitando acoplar el modelo a Vietnam.
-4. Definir para cada entidad:
-   - propósito
-   - campos principales
-   - claves
-   - relaciones
-   - timestamps
-5. Documentar qué datos deben persistirse por snapshot y cuáles pueden derivarse después.
-6. Si el backend ya usa o prevé una tecnología concreta para persistencia, reflejarlo con claridad. Si aún no, documentar una base neutra y coherente.
-7. Añadir o actualizar documentación técnica del repositorio para dejar claro el modelo inicial de almacenamiento.
-8. Mantener el alcance en diseño y preparación, no en implementación completa de persistencia productiva.
-
-## Files to Read First
-- AGENTS.md
-- docs/project-overview.md
-- docs/roadmap.md
-- docs/decisions.md
-- docs/frontend-backend-contract.md
-- docs/current-hll-data-ingestion-plan.md
-- ai/repo-context.md
-- ai/architecture-index.md
-- backend/README.md
-- backend/app/config.py
-- backend/app/main.py
-
-## Expected Files to Modify
-- docs/decisions.md
-- ai/architecture-index.md
-- backend/README.md
-- opcionalmente un nuevo documento técnico si encaja mejor, por ejemplo:
-  - docs/stats-database-schema-foundation.md
-- opcionalmente archivos base de estructura si el repositorio ya está preparado para ello, pero sin implementar una base de datos completa
-
-## Constraints
-- No implementar todavía la base de datos completa.
-- No añadir migraciones productivas si la decisión técnica aún no está consolidada.
-- No tocar frontend.
-- No añadir integraciones reales de servidor.
-- No hacer cambios destructivos.
-- Mantener el modelo simple, genérico y preparado para crecer.
-
-## Validation
-- Existe un esquema de almacenamiento inicial claro para snapshots y estadísticas básicas.
-- El naming es reutilizable para HLL actual y futuro HLL Vietnam.
-- La documentación deja claro qué se persistirá primero y por qué.
-- El resultado sirve como base directa para una siguiente task de colector de snapshots.
-
-## Change Budget
-- Preferir menos de 5 archivos modificados o creados.
-- Preferir menos de 220 líneas cambiadas.

ai/tasks/done/TASK-020-component-surface-polish.md

@@ -1,58 +0,0 @@
-# TASK-020-component-surface-polish
-
-## Goal
-Pulir visualmente superficies y componentes de la landing de HLL Vietnam para mejorar calidad percibida, consistencia y acabado en tarjetas, chips, badges, contenedores y detalles de UI.
-
-## Context
-La landing ya tiene una estructura visual bastante competente, pero aún puede ganar acabado en microdetalles de interfaz. El panel de servidores, las tarjetas, los chips de estado y los contenedores principales necesitan una pasada de consistencia visual para que el conjunto se sienta más refinado y más uniforme.
-
-## Steps
-1. Revisar los componentes visuales actuales de la landing.
-2. Evaluar consistencia en:
-   - radios
-   - bordes
-   - sombras
-   - chips
-   - badges de estado
-   - tarjetas
-   - barras de ocupación
-   - encabezados de panel
-3. Refinar esos elementos para que compartan un lenguaje visual más sólido y coherente.
-4. Mejorar calidad percibida sin añadir complejidad innecesaria.
-5. Asegurar que el panel de servidores y los componentes de apoyo se lean mejor tanto en estado estático como hidratado por JS.
-6. Mantener clara la jerarquía entre componentes primarios y secundarios.
-7. Validar responsive y consistencia entre escritorio y móvil.
-8. No tocar el contrato del backend ni el contenido funcional de los payloads.
-
-## Files to Read First
-- AGENTS.md
-- ai/repo-context.md
-- frontend/index.html
-- frontend/assets/css/styles.css
-- frontend/assets/js/main.js
-- backend/app/payloads.py
-
-## Expected Files to Modify
-- frontend/index.html
-- frontend/assets/css/styles.css
-- frontend/assets/js/main.js
-
-## Constraints
-- No cambiar endpoints.
-- No cambiar payloads backend.
-- No añadir librerías nuevas.
-- No romper el fallback estático.
-- No rediseñar completamente la landing.
-- No hacer cambios destructivos.
-- Mantener el ajuste centrado en UI y acabado visual.
-
-## Validation
-- Las superficies y componentes se ven más coherentes y mejor acabados.
-- Chips, badges y tarjetas tienen una presentación más limpia y consistente.
-- El panel de servidores gana claridad y calidad visual.
-- La landing mantiene su funcionamiento actual.
-- La mejora se aprecia en desktop y mobile.
-
-## Change Budget
-- Preferir menos de 3 archivos modificados.
-- Preferir menos de 190 líneas cambiadas.

ai/tasks/done/TASK-020-server-snapshot-collector-bootstrap.md

@@ -1,61 +0,0 @@
-# TASK-020-server-snapshot-collector-bootstrap
-
-## Goal
-Preparar un bootstrap técnico mínimo para un colector de snapshots de servidores en el backend Python, dejando la estructura lista para capturar y normalizar datos de HLL actual sin implementar todavía una ingesta completa de producción.
-
-## Context
-Tras definir la estrategia de ingesta y el esquema base de almacenamiento, el siguiente paso es dejar preparada la estructura mínima de un colector en backend. Esta task no debe resolver toda la persistencia ni depender de una fuente definitiva, pero sí debe sentar la base para un flujo futuro de captura periódica.
-
-## Steps
-1. Revisar la documentación de ingesta y esquema de almacenamiento.
-2. Revisar la estructura actual del backend Python.
-3. Crear una estructura mínima y clara para un colector o servicio de snapshots dentro de `backend/app/`.
-4. Definir interfaces o funciones base para:
-   - obtener datos crudos de una fuente
-   - normalizar esos datos
-   - producir un snapshot consistente
-5. Si encaja con la fase actual, permitir una ejecución manual o de desarrollo del colector usando datos controlados.
-6. Mantener la implementación desacoplada para que la fuente real pueda sustituirse más adelante sin romper el resto del backend.
-7. Actualizar la documentación backend para explicar el papel del colector y cómo encaja con futuras estadísticas.
-8. Mantener el alcance estricto: bootstrap técnico del colector, no pipeline completo de producción.
-
-## Files to Read First
-- AGENTS.md
-- ai/repo-context.md
-- ai/architecture-index.md
-- docs/current-hll-data-ingestion-plan.md
-- docs/stats-database-schema-foundation.md
-- backend/README.md
-- backend/app/__init__.py
-- backend/app/config.py
-- backend/app/main.py
-- backend/app/routes.py
-- backend/app/payloads.py
-
-## Expected Files to Modify
-- backend/README.md
-- backend/app/__init__.py
-- opcionalmente archivos nuevos dentro de `backend/app/` si mejoran claridad, por ejemplo:
-  - backend/app/collector.py
-  - backend/app/normalizers.py
-  - backend/app/snapshots.py
-- opcionalmente documentación técnica relacionada si requiere alineación menor
-
-## Constraints
-- No implementar todavía una ingesta real completa.
-- No depender de scraping productivo.
-- No introducir una base de datos completa en esta task.
-- No tocar frontend.
-- No añadir complejidad innecesaria.
-- No hacer cambios destructivos.
-- Mantener la estructura clara y pequeña.
-
-## Validation
-- El backend contiene una base mínima para un colector de snapshots.
-- La estructura separa captura, normalización y snapshot de forma razonable para la fase actual.
-- La documentación backend refleja el nuevo estado.
-- El resultado prepara el terreno para una siguiente task de persistencia real o ejecución periódica.
-
-## Change Budget
-- Preferir menos de 6 archivos modificados o creados.
-- Preferir menos de 240 líneas cambiadas.

ai/tasks/done/TASK-021-server-status-periodic-query-and-display.md

@@ -1,96 +0,0 @@
-# TASK-021-server-status-periodic-query-and-display
-
-## Goal
-Implementar una base funcional para consultar periódicamente el estado de los servidores y mostrar esos datos en la página, realizando snapshots de datos cada 2 minutos, sin usar capturas de imagen ni elementos manuales equivalentes.
-
-## Context
-Queda descartada cualquier idea de “captura manual” o de imagen estática para representar el estado de los servidores. Lo que se necesita es mostrar en la web la situación actual de los servidores mediante consultas de datos reales o semirrealistas desde backend. En esta fase, la web debe evolucionar hacia un modelo donde el backend consulta periódicamente la información de servidores, conserva el último snapshot útil y el frontend lo muestra de forma clara.
-
-## Steps
-1. Revisar el endpoint actual `GET /api/servers` y su implementación placeholder.
-2. Revisar cómo se muestra actualmente el bloque de servidores en la landing.
-3. Diseñar e implementar una base de consulta periódica de datos de servidores con una frecuencia objetivo de 2 minutos.
-4. Hacer que el backend obtenga y conserve snapshots de datos con los campos necesarios para la UI. Incluir al menos:
-   - nombre del servidor
-   - estado online/offline
-   - jugadores actuales
-   - capacidad máxima
-   - mapa actual si está disponible
-   - región o etiqueta útil si existe
-   - timestamp real del último snapshot de datos
-5. Dejar claro en la implementación y en la UI que se trata de datos de estado de servidores, no de capturas de imagen.
-6. Hacer que `GET /api/servers` devuelva el último snapshot útil con una estructura estable y preparada para frontend.
-7. Ajustar el frontend para mostrar esos datos de forma clara en la landing.
-8. Si el backend no puede obtener datos nuevos temporalmente, mantener el último snapshot válido o un fallback coherente sin romper la página.
-9. Mostrar en la UI una referencia honesta del momento de actualización basada en datos reales del snapshot, no en texto ficticio.
-10. Mantener el alcance razonable: consultas periódicas y presentación de datos, sin abrir todavía automatizaciones más complejas de observabilidad o infraestructura.
-
-## Files to Read First
-- AGENTS.md
-- ai/repo-context.md
-- ai/architecture-index.md
-- docs/frontend-backend-contract.md
-- docs/discord-and-server-data-plan.md
-- docs/current-hll-servers-source-plan.md
-- backend/README.md
-- backend/app/__init__.py
-- backend/app/main.py
-- backend/app/routes.py
-- backend/app/payloads.py
-- backend/app/config.py
-- frontend/index.html
-- frontend/assets/js/main.js
-- frontend/assets/css/styles.css
-
-## Expected Files to Modify
-- backend/app/main.py
-- backend/app/routes.py
-- backend/app/payloads.py
-- backend/app/config.py
-- opcionalmente uno o más archivos nuevos de servicio dentro de `backend/app/`, por ejemplo:
-  - backend/app/server_status_service.py
-  - backend/app/server_queries.py
-- frontend/index.html
-- frontend/assets/js/main.js
-- frontend/assets/css/styles.css
-- backend/README.md
-- opcionalmente documentación técnica si fuera necesario alinear el comportamiento real
-
-## Constraints
-- No usar capturas de imagen para representar el estado de servidores.
-- No introducir texto temporal ficticio.
-- No consultar fuentes externas directamente desde frontend.
-- Mantener la arquitectura frontend → backend → fuente de datos.
-- No romper el fallback actual si no hay datos disponibles.
-- No hacer cambios destructivos.
-- Mantener la solución clara, trazable y coherente con la fase del proyecto.
-
-## Validation
-- Existe una base de consulta periódica con objetivo de refresco cada 2 minutos.
-- `GET /api/servers` devuelve un snapshot de datos de servidores con timestamp real del snapshot.
-- La landing muestra esos datos en lugar de una “captura” manual o ficticia.
-- Si falla la actualización, la web no se rompe.
-- La UI muestra de forma honesta la actualización real del estado de servidores.
-- No se introducen capturas de imagen como solución del problema.
-
-## Change Budget
-- Preferir menos de 8 archivos modificados o creados.
-- Preferir menos de 320 líneas cambiadas.
-
-## Outcome
-- `backend/app/payloads.py` hace que `GET /api/servers` devuelva un snapshot coherente preparado para frontend: prioriza el ultimo snapshot A2S real persistido cuando existe y, si no existe ninguno, responde un respaldo controlado con `last_snapshot_at`.
-- `backend/app/config.py` alinea la frecuencia objetivo de refresco local a `120` segundos.
-- `frontend/assets/js/main.js` deja de depender de una segunda llamada a `/api/servers/latest` para el bloque principal y pinta directamente el snapshot devuelto por `/api/servers`, mostrando un estado honesto con timestamp real del snapshot.
-- `frontend/index.html` ajusta el polling por defecto a `120000` ms y aclara que el bloque muestra snapshots de estado consultados desde backend.
-- `backend/README.md` documenta el nuevo comportamiento de `/api/servers` y el intervalo de `120` segundos.
-
-## Validation Result
-- Validado con `python -m py_compile backend/app/config.py backend/app/payloads.py backend/app/routes.py backend/app/main.py`.
-- Validado con `node --check frontend/assets/js/main.js`.
-- Validado con `python -m app.collector --source controlled`, que persistio un snapshot controlado en `backend/data/hll_vietnam_dev.sqlite3`.
-- Validado inspeccionando `build_servers_payload()` desde Python para confirmar que `/api/servers` devuelve `last_snapshot_at` e `items` listos para frontend.
-- Revisado en diff: la task queda limitada a `backend/README.md`, `backend/app/config.py`, `backend/app/payloads.py`, `frontend/assets/js/main.js`, `frontend/index.html`, este archivo de task y la actualizacion de `backend/data/hll_vietnam_dev.sqlite3` causada por la validacion persistente.
-
-## Decision Notes
-- Se reutilizo la infraestructura de snapshots ya existente en lugar de introducir otro scheduler o un segundo endpoint principal para el estado visible en landing.
-- `/api/servers` devuelve un unico conjunto coherente de items para evitar mezclar timestamps de fallback con tarjetas reales A2S en la UI.

ai/tasks/done/TASK-021-snapshot-persistence-bootstrap.md

@@ -1,73 +0,0 @@
-# TASK-021-snapshot-persistence-bootstrap
-
-## Goal
-Preparar una persistencia local minima para snapshots de servidores en el backend Python, de forma que los datos recogidos durante las pruebas con HLL actual puedan guardarse y reutilizarse para consultas historicas posteriores.
-
-## Context
-El proyecto ya dispone de plan de ingesta, modelo logico de almacenamiento y bootstrap de colector. El siguiente paso es dejar de depender exclusivamente de estructuras temporales o payloads controlados y empezar a guardar snapshots de forma persistente para validar el circuito real de estadisticas.
-
-## Steps
-1. Revisar la documentacion actual de ingesta, esquema logico y colector.
-2. Definir una estrategia de persistencia local minima adecuada para esta fase de pruebas.
-3. Implementar una capa pequena de persistencia alineada con las entidades ya definidas logicamente:
-   - game_sources
-   - servers
-   - server_snapshots
-4. Mantener la implementacion simple, reutilizable y desacoplada de una base de datos de produccion futura.
-5. Hacer que el colector pueda guardar snapshots reales o controlados en esa persistencia local.
-6. Documentar como inicializar y usar esta persistencia en desarrollo.
-7. No introducir todavia consultas historicas complejas ni visualizacion en frontend.
-8. Mantener el alcance centrado en almacenamiento basico funcional.
-
-## Files to Read First
-- AGENTS.md
-- ai/repo-context.md
-- ai/architecture-index.md
-- docs/current-hll-data-ingestion-plan.md
-- docs/stats-database-schema-foundation.md
-- backend/README.md
-- backend/app/__init__.py
-- backend/app/config.py
-- backend/app/collector.py
-- backend/app/normalizers.py
-- backend/app/snapshots.py
-
-## Expected Files to Modify
-- backend/README.md
-- backend/app/__init__.py
-- backend/app/config.py
-- backend/app/collector.py
-- backend/app/snapshots.py
-- opcionalmente archivos nuevos dentro de backend/app/ si mejoran la separacion de persistencia, por ejemplo:
-  - backend/app/storage.py
-  - backend/app/repository.py
-
-## Constraints
-- No implementar todavia integraciones reales complejas de terceros.
-- No tocar frontend.
-- No anadir una infraestructura de produccion sobredimensionada.
-- No hacer cambios destructivos.
-- Mantener la persistencia simple y util para desarrollo local.
-
-## Validation
-- El backend puede guardar snapshots de servidores en una persistencia local real.
-- La persistencia sigue el modelo logico documentado.
-- La documentacion explica como usar esta base minima en local.
-- El resultado prepara el terreno para consultas historicas inmediatas.
-
-## Change Budget
-- Preferir menos de 7 archivos modificados o creados.
-- Preferir menos de 260 lineas cambiadas.
-
-## Outcome
-- Se anadio `backend/app/storage.py` con una persistencia SQLite minima basada en libreria estandar.
-- El colector puede persistir snapshots controlados en `game_sources`, `servers` y `server_snapshots`.
-- La configuracion local expone `HLL_BACKEND_STORAGE_PATH` para cambiar la ruta del archivo SQLite sin fijar una decision de produccion.
-- `backend/README.md` documenta la inicializacion y uso de la persistencia local.
-
-## Validation Result
-- Ejecutado: `python -m app.collector`
-- Resultado: lote de 3 snapshots persistido correctamente en SQLite local de desarrollo.
-
-## Decision Notes
-- Se eligio SQLite porque cubre persistencia local real con dependencias cero y mantiene abierta la migracion futura a otra tecnologia de almacenamiento.

ai/tasks/done/TASK-022-historical-server-query-api.md

@@ -1,77 +0,0 @@
-# TASK-022-historical-server-query-api
-
-## Goal
-Exponer desde el backend una primera API de consulta historica para snapshots de servidores, permitiendo recuperar el ultimo estado conocido y una evolucion basica a partir de la persistencia local ya preparada.
-
-## Context
-Una vez que los snapshots puedan guardarse, el siguiente paso es poder consultarlos de forma estructurada. Esta task debe convertir la persistencia inicial en una API util para comprobar que el flujo de estadisticas ya funciona extremo a extremo.
-
-## Steps
-1. Revisar la capa de persistencia de snapshots y el backend actual.
-2. Definir endpoints minimos de consulta historica, por ejemplo:
-   - `GET /api/servers/latest`
-   - `GET /api/servers/history`
-   - `GET /api/servers/{id}/history`
-3. Alinear el formato de respuesta con las convenciones del backend existente.
-4. Hacer que las respuestas devuelvan como minimo:
-   - timestamps
-   - ultimo estado conocido
-   - jugadores
-   - capacidad
-   - mapa si esta disponible
-   - contexto o fuente si aplica
-5. Mantener la implementacion simple y enfocada a validacion tecnica.
-6. Actualizar la documentacion del backend y del contrato si fuera necesario.
-7. No introducir todavia analitica avanzada ni agregaciones pesadas.
-
-## Files to Read First
-- AGENTS.md
-- ai/repo-context.md
-- ai/architecture-index.md
-- docs/frontend-backend-contract.md
-- docs/current-hll-data-ingestion-plan.md
-- docs/stats-database-schema-foundation.md
-- backend/README.md
-- backend/app/main.py
-- backend/app/routes.py
-- backend/app/payloads.py
-- backend/app/collector.py
-- backend/app/snapshots.py
-- archivos de persistencia creados en la task anterior
-
-## Expected Files to Modify
-- backend/app/main.py
-- backend/app/routes.py
-- backend/app/payloads.py
-- backend/README.md
-- opcionalmente documentacion tecnica contractual si requiere alineacion menor
-
-## Constraints
-- No tocar frontend en esta task.
-- No anadir visualizacion nueva.
-- No introducir complejidad innecesaria.
-- No hacer cambios destructivos.
-- Mantener la API clara, estable y centrada en historico basico.
-
-## Validation
-- Existen endpoints historicos minimos funcionales.
-- El backend puede devolver ultimo snapshot y una historia basica de snapshots.
-- La documentacion refleja correctamente el nuevo estado.
-- El resultado prepara el terreno para una primera visualizacion en frontend.
-
-## Change Budget
-- Preferir menos de 6 archivos modificados o creados.
-- Preferir menos de 240 lineas cambiadas.
-
-## Outcome
-- Se anadieron lecturas minimas desde SQLite para ultimo snapshot por servidor, historial agregado e historial por servidor.
-- `backend/app/routes.py` resuelve `GET /api/servers/latest`, `GET /api/servers/history` y `GET /api/servers/{id}/history`.
-- `backend/app/payloads.py` mantiene el formato JSON del backend y devuelve errores controlados para parametros invalidos.
-- `backend/README.md` y `docs/frontend-backend-contract.md` documentan los nuevos endpoints.
-
-## Validation Result
-- Ejecutado: `python -c "from app.collector import collect_server_snapshots; from app.routes import resolve_get_payload; collect_server_snapshots(persist=True); ..."`
-- Resultado: los tres endpoints historicos devolvieron datos persistidos y `limit=999` respondio con `status: "error"`.
-
-## Decision Notes
-- Se mantuvo la API sobre la persistencia SQLite local ya existente, evitando una capa analitica separada hasta que el frontend necesite algo mas que consultas historicas basicas.

ai/tasks/done/TASK-022-real-time-server-snapshot-refresh.md

@@ -1,102 +0,0 @@
-# TASK-022-real-time-server-snapshot-refresh
-
-## Goal
-Hacer que `GET /api/servers` devuelva datos realmente actuales de los 2 servidores de la comunidad, refrescando el snapshot cuando el último estado persistido esté vencido respecto al objetivo de 120 segundos.
-
-## Context
-La implementación actual ya tiene snapshots persistidos y polling desde frontend, pero el backend está sirviendo datos antiguos desde almacenamiento local (`local-snapshot-storage`) incluso cuando el snapshot tiene varias horas de antigüedad. Eso rompe el objetivo de mostrar la situación actual de los servidores. El frontend no debe depender de un snapshot viejo si el backend puede consultar el estado real de los servidores en ese momento.
-
-## Steps
-1. Revisar la implementación actual de:
-   - `GET /api/servers`
-   - carga de snapshots persistidos
-   - lógica de refresco objetivo a 120 s
-   - consulta real A2S o equivalente que ya exista en el backend
-2. Identificar por qué el backend está devolviendo snapshots antiguos sin forzar actualización.
-3. Ajustar la lógica para que:
-   - si el snapshot actual tiene menos de 120 s, pueda reutilizarse
-   - si el snapshot actual supera 120 s, el backend intente una consulta real inmediata de los 2 servidores antes de responder
-4. Si la consulta real tiene éxito:
-   - persistir el nuevo snapshot
-   - devolver ese snapshot fresco al frontend
-5. Si la consulta real falla:
-   - devolver el último snapshot válido disponible
-   - marcar claramente en el payload que el dato es stale o desactualizado
-6. Asegurar que el payload de `/api/servers` incluya campos claros para frontend, como por ejemplo:
-   - `last_snapshot_at`
-   - indicador de stale/fresh
-   - edad del snapshot en segundos o minutos
-   - origen real del dato devuelto
-7. Ajustar el frontend solo si hace falta para que:
-   - no presente como “actual” un snapshot viejo
-   - pueda mostrar una nota honesta si el dato está desactualizado
-8. Mantener el alcance centrado en datos actuales de los 2 servidores reales de la comunidad.
-9. No reintroducir servidores ficticios o de referencia ajenos a la comunidad.
-10. Al completar la implementación, dejar el repositorio en estado consistente y preparado para integración.
-11. Hacer commit de los cambios realizados y hacer push al repositorio remoto siguiendo el workflow del proyecto, siempre que el entorno tenga permisos y configuración git disponibles.
-
-## Files to Read First
-- AGENTS.md
-- ai/repo-context.md
-- ai/architecture-index.md
-- docs/frontend-backend-contract.md
-- docs/current-hll-servers-source-plan.md
-- backend/README.md
-- backend/app/__init__.py
-- backend/app/main.py
-- backend/app/routes.py
-- backend/app/payloads.py
-- backend/app/config.py
-- cualquier servicio o módulo de collector/query ya existente en `backend/app/`
-- frontend/index.html
-- frontend/assets/js/main.js
-- frontend/assets/css/styles.css
-
-## Expected Files to Modify
-- backend/app/routes.py
-- backend/app/payloads.py
-- backend/app/config.py
-- backend/app/main.py
-- opcionalmente uno o más archivos de servicio existentes del backend si ahí vive la lógica de snapshots o de consulta real
-- frontend/assets/js/main.js
-- opcionalmente frontend/index.html y frontend/assets/css/styles.css si hace falta ajustar el estado visual stale/fresh
-- backend/README.md si el comportamiento operativo cambia
-
-## Constraints
-- No reintroducir servidores ficticios.
-- No usar datos viejos como si fueran datos actuales.
-- No consultar fuentes externas directamente desde frontend.
-- Mantener la arquitectura frontend → backend → consulta real/persistencia.
-- No romper el fallback si la consulta real falla.
-- No hacer cambios destructivos.
-- Mantener la solución centrada en los 2 servidores reales de la comunidad.
-- Si el entorno no permite push, dejar el commit local realizado e informar claramente de ello en el resumen final.
-
-## Validation
-- Si el snapshot persistido tiene más de 120 s, `/api/servers` intenta refrescarlo antes de responder.
-- Si la consulta real tiene éxito, el frontend recibe datos actuales de los 2 servidores reales.
-- Si la consulta real falla, el backend devuelve el último snapshot válido con una indicación clara de dato stale.
-- La UI no presenta como actual un snapshot antiguo.
-- No aparecen servidores ajenos a la comunidad.
-- Los cambios quedan committeados y se hace push al remoto si el entorno lo permite.
-
-## Change Budget
-- Preferir menos de 8 archivos modificados o creados.
-- Preferir menos de 320 líneas cambiadas.
-## Outcome
-- `backend/app/payloads.py` deja de servir `/api/servers` como simple lectura del ultimo snapshot persistido: ahora reutiliza cache solo si sigue dentro del objetivo de `120` segundos y, si no, intenta un refresco A2S inmediato antes de responder.
-- El payload principal de `/api/servers` ahora expone `last_snapshot_at`, `snapshot_age_seconds`, `snapshot_age_minutes`, `max_snapshot_age_seconds`, `is_stale`, `freshness`, `source`, `refresh_attempted`, `refresh_status` y `refresh_errors`.
-- Si el refresco real falla, backend devuelve el ultimo snapshot valido con marca clara de dato stale; si no existe snapshot valido, responde `items: []` en vez de reintroducir servidores ficticios o de referencia.
-- `frontend/assets/js/main.js` usa la metadata de frescura del backend para no presentar un snapshot viejo como si fuera actual y muestra una nota honesta cuando el dato esta desactualizado.
-- `backend/README.md` y `docs/frontend-backend-contract.md` quedan alineados con el comportamiento real del endpoint.
-
-## Validation Result
-- Validado con `python -m py_compile backend/app/config.py backend/app/payloads.py backend/app/routes.py backend/app/main.py`.
-- Validado con `node --check frontend/assets/js/main.js`.
-- Validado con una comprobacion local desde Python que cubre tres rutas de `build_servers_payload()`: refresco real exitoso, fallo de refresco con fallback stale al ultimo snapshot valido y ausencia total de snapshot valido.
-- Validado ejecutando `build_servers_payload()` contra el entorno actual: el backend devolvio `source: "real-time-a2s-refresh"`, `freshness: "fresh"` e `item_count: 2`.
-- Revisado en `git diff --name-only`: el alcance queda limitado a la task, documentacion del contrato/backend, frontend del panel de servidores y backend de payload/config, ademas de archivos ya presentes en el worktree (`ai/worker.lock` y `backend/data/hll_vietnam_dev.sqlite3`).
-
-## Decision Notes
-- `/api/servers` se mantiene como endpoint principal para la landing y pasa a tratar la persistencia local como cache, no como fuente autoritativa cuando el snapshot ya vencio.
-- Se elimina el uso de respaldo controlado en este endpoint cuando no hay snapshot valido disponible para cumplir la restriccion de no reintroducir servidores ajenos a la comunidad.

ai/tasks/done/TASK-023-server-panel-ux-fixes-and-hero-cleanup.md

@@ -1,101 +0,0 @@
-# TASK-023-server-panel-ux-fixes-and-hero-cleanup
-
-## Goal
-Corregir la UX del bloque de servidores y limpiar elementos visuales del hero de la landing, eliminando mensajes innecesarios, arreglando el CTA roto de conexion y dejando visible una referencia honesta de actualizacion del snapshot.
-
-## Context
-La landing ya muestra datos actuales de los 2 servidores reales de la comunidad, pero todavia hay varios problemas de UX y acabado:
-- aparece un texto largo e innecesario bajo el titulo del bloque de servidores indicando que el backend no pudo refrescar y que muestra el ultimo snapshot valido
-- el boton `Conectar` no funciona correctamente y muestra errores de conexion como los observados en Steam
-- el badge superior derecho del bloque de servidores debe pasar a mostrar una referencia limpia tipo `Actualizado ...` con el momento real correspondiente
-- en el hero deben eliminarse los pills `BACKEND OPERATIVO` y `COMUNIDAD TACTICA HISPANA`
-
-La tarea debe dejar la UI mas limpia, mas honesta y sin CTAs rotos.
-
-## Steps
-1. Revisar la implementacion actual del bloque de servidores en frontend y el payload real de `/api/servers`.
-2. Eliminar del bloque de servidores el texto:
-   - `El backend no pudo refrescar ahora mismo y muestra el ultimo snapshot valido.`
-   - `Captura: ...`
-   o cualquier variante equivalente que recargue innecesariamente la UI.
-3. Mantener la referencia temporal del snapshot unicamente en el badge superior derecho del bloque, sustituyendo el texto actual por un formato limpio tipo:
-   - `Actualizado 20/3/26, 19:37`
-   o equivalente coherente con el estilo visual actual.
-4. Asegurar que el momento mostrado en ese badge viene de datos reales del snapshot/backend y no de texto ficticio.
-5. Revisar la implementacion del boton `Conectar` de cada servidor.
-6. Investigar por que el CTA actual produce el error observado y corregirlo si existe una forma fiable de conexion directa compatible con el flujo actual del proyecto.
-7. Si la conexion directa no puede garantizarse de forma robusta con el comportamiento actual del juego/cliente, no dejar un boton roto:
-   - sustituirlo por una accion segura y util
-   - priorizar una UX que siempre funcione, por ejemplo `Copiar IP`, `Copiar direccion` o una variante equivalente basada en los datos reales del servidor
-   - si se conserva una accion de conexion, debe quedar realmente funcional
-8. Mantener el comportamiento de los 2 servidores reales de la comunidad y no reintroducir servidores ficticios.
-9. En el hero, eliminar visualmente:
-   - `BACKEND OPERATIVO`
-   - `COMUNIDAD TACTICA HISPANA`
-10. Mantener intactos:
-   - logo
-   - CTA principal de Discord
-   - trailer
-   - estructura general de la landing
-11. Asegurar que los cambios funcionan tanto en la UI estatica como en la UI hidratada por JS.
-12. Al completar la implementacion:
-   - 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/frontend-backend-contract.md
-- frontend/index.html
-- frontend/assets/js/main.js
-- frontend/assets/css/styles.css
-- backend/app/payloads.py
-- backend/app/routes.py
-- backend/README.md
-
-## Expected Files to Modify
-- frontend/index.html
-- frontend/assets/js/main.js
-- frontend/assets/css/styles.css
-- opcionalmente backend/app/payloads.py si hace falta exponer mejor datos utiles para la UX del boton de servidor
-- opcionalmente backend/README.md si cambia el comportamiento esperado del CTA de servidor
-
-## Constraints
-- No volver a introducir mensajes largos y tecnicos en la UI principal del bloque de servidores.
-- No dejar CTAs rotos o engañosos.
-- No presentar datos no reales.
-- No añadir librerias nuevas.
-- No romper el polling ni la hidratacion actual del bloque.
-- No romper el fallback actual.
-- No hacer cambios destructivos.
-- Mantener la solucion clara, visualmente limpia y coherente con la landing.
-
-## Validation
-- Ya no aparece el texto largo bajo el titulo del bloque de servidores sobre fallo de refresh.
-- El badge superior derecho muestra `Actualizado ...` con el momento real correspondiente al snapshot.
-- El CTA de servidor deja de fallar:
-  - o conecta correctamente
-  - o se sustituye por una accion segura que si funciona
-- Los 2 servidores reales de la comunidad siguen siendo los unicos mostrados.
-- En el hero ya no aparecen `BACKEND OPERATIVO` ni `COMUNIDAD TACTICA HISPANA`.
-- La landing mantiene coherencia visual y funcional.
-- Los cambios quedan committeados y se hace push si el entorno lo permite.
-
-## Change Budget
-- Preferir menos de 5 archivos modificados.
-- Preferir menos de 220 lineas cambiadas.
-
-## Outcome
-- `frontend/index.html` elimina los pills del hero, retira el texto secundario bajo el bloque de servidores y alinea el fallback estatico con los 2 servidores reales de Comunidad Hispana.
-- `frontend/assets/js/main.js` deja la referencia temporal del snapshot solo en el badge superior derecho usando `last_snapshot_at` real del backend y sustituye la CTA rota `Conectar` por una accion segura de `Copiar IP`.
-- `frontend/assets/css/styles.css` adapta las tarjetas al nuevo CTA, elimina estilos ya innecesarios del layout anterior y mantiene la presentacion limpia en desktop y movil.
-
-## Validation Result
-- Validado con `node --check frontend/assets/js/main.js`.
-- Verificado con busqueda en `frontend/` que ya no queda el texto largo del snapshot fallido ni `steam://connect`.
-- Revisado con `git diff --name-only`: los cambios de esta task quedan limitados a `frontend/index.html`, `frontend/assets/js/main.js`, `frontend/assets/css/styles.css` y este archivo de task; permanecen sin tocar otros cambios locales ajenos.
-
-## Decision Notes
-- La conexion directa por `steam://connect/<host>:<game_port>` se retira de la UI porque no podia garantizarse como CTA robusta en el flujo actual; se prioriza una accion segura y util basada en los datos reales del backend.

ai/tasks/done/TASK-023-server-stats-preview-panel.md

@@ -1,68 +0,0 @@
-# TASK-023-server-stats-preview-panel
-
-## Goal
-Anadir a la web una primera visualizacion de estadisticas de servidores basada en datos persistidos, mostrando una vista previa util y controlada del historico sin convertir todavia la landing en una aplicacion compleja.
-
-## Context
-La landing ya dispone de un panel provisional de servidores y el backend va a disponer de persistencia local y consultas historicas minimas. Esta task debe conectar ambos mundos con una primera visualizacion ligera que confirme que el pipeline completo funciona.
-
-## Steps
-1. Revisar el frontend actual, el panel de servidores existente y el plan de consumo de datos.
-2. Revisar los nuevos endpoints historicos del backend.
-3. Disenar una mejora progresiva en frontend que pueda mostrar una vista previa de estadisticas sin romper la landing actual.
-4. Mostrar como minimo algunos indicadores utiles, por ejemplo:
-   - ultimo snapshot por servidor
-   - hora de ultima actualizacion
-   - evolucion basica de poblacion o actividad reciente
-5. Mantener fallback seguro si el backend o los endpoints historicos no estan disponibles.
-6. Integrar visualmente el bloque con el diseno actual sin redisenar toda la pagina.
-7. No anadir todavia dashboards complejos, graficas pesadas ni navegacion nueva.
-
-## Files to Read First
-- AGENTS.md
-- ai/repo-context.md
-- docs/frontend-data-consumption-plan.md
-- docs/frontend-backend-contract.md
-- frontend/index.html
-- frontend/assets/js/main.js
-- frontend/assets/css/styles.css
-- backend/app/routes.py
-- backend/app/payloads.py
-- documentacion de endpoints historicos creada en la task anterior
-
-## Expected Files to Modify
-- frontend/index.html
-- frontend/assets/js/main.js
-- frontend/assets/css/styles.css
-- opcionalmente documentacion minima si fuera necesario reflejar el nuevo bloque o comportamiento
-
-## Constraints
-- No redisenar completamente la landing.
-- No anadir librerias nuevas.
-- No romper el fallback actual.
-- No introducir analitica visual compleja.
-- No hacer cambios destructivos.
-- Mantener la mejora contenida, clara y alineada con la fase actual.
-
-## Validation
-- La web puede mostrar una primera vista previa de estadisticas de servidores usando datos persistidos.
-- El frontend sigue funcionando si el backend no esta disponible.
-- La mejora visual se integra con la landing actual.
-- El resultado demuestra que el flujo captura -> persistencia -> consulta -> visualizacion ya funciona.
-
-## Change Budget
-- Preferir menos de 4 archivos modificados.
-- Preferir menos de 220 lineas cambiadas.
-
-## Outcome
-- El panel de servidores ahora puede mostrar una vista previa historica con resumen, ultima actualizacion y tendencia reciente por servidor.
-- `frontend/assets/js/main.js` mantiene el bloque estatico como fallback y solo sustituye el contenido cuando los endpoints historicos responden correctamente.
-- `frontend/index.html` anade un contenedor ligero para el resumen historico.
-- `frontend/assets/css/styles.css` integra la nueva vista previa con el lenguaje visual tactico existente.
-
-## Validation Result
-- Ejecutado: `node --check frontend/assets/js/main.js`
-- Resultado: sintaxis valida en el script principal del frontend.
-
-## Decision Notes
-- Se mantuvo la mejora dentro del panel de servidores ya existente para evitar una nueva seccion o un dashboard separado en esta fase.

ai/tasks/done/TASK-024-a2s-client-bootstrap.md

@@ -1,77 +0,0 @@
-# TASK-024-a2s-client-bootstrap
-
-## Goal
-Preparar un cliente A2S mínimo en el backend Python para consultar servidores de Hell Let Loose actual mediante query pública, obteniendo metadata básica reutilizable por el colector de snapshots.
-
-## Context
-El proyecto ya dispone de colector bootstrap, persistencia local y consultas históricas mínimas. El siguiente paso es introducir una fuente real de datos en vivo. Hell Let Loose usa Steam A2S para metadata de servidor a través del query port, por lo que esta task debe preparar la base técnica para consultar servidores reales sin depender todavía de integraciones administrativas o scoreboards avanzados.
-
-## Steps
-1. Revisar el backend actual, especialmente el colector y las funciones de normalización.
-2. Revisar la documentación técnica de ingesta y el modelo de snapshots.
-3. Preparar un cliente A2S mínimo capaz de consultar al menos la información equivalente a:
-   - nombre del servidor
-   - mapa actual
-   - jugadores actuales
-   - capacidad máxima
-4. Mantener la implementación desacoplada para que futuras consultas de players o rules puedan añadirse después sin romper la base.
-5. Normalizar la salida del cliente A2S hacia el modelo interno ya usado por el proyecto.
-6. Asegurar que la implementación maneje fallos básicos de red o timeouts de forma controlada.
-7. Actualizar la documentación backend para reflejar que existe una fuente A2S real de prueba.
-8. Mantener el alcance centrado en bootstrap del cliente, no en pipeline completo.
-
-## Files to Read First
-- AGENTS.md
-- ai/repo-context.md
-- ai/architecture-index.md
-- docs/current-hll-data-ingestion-plan.md
-- docs/stats-database-schema-foundation.md
-- backend/README.md
-- backend/app/__init__.py
-- backend/app/config.py
-- backend/app/collector.py
-- backend/app/normalizers.py
-- backend/app/snapshots.py
-- backend/app/storage.py
-
-## Expected Files to Modify
-- backend/README.md
-- backend/app/__init__.py
-- backend/app/normalizers.py
-- backend/app/collector.py
-- opcionalmente archivos nuevos dentro de backend/app/ si mejoran claridad, por ejemplo:
-  - backend/app/a2s_client.py
-  - backend/app/a2s_protocol.py
-
-## Constraints
-- No implementar todavía scraping de terceros.
-- No tocar frontend.
-- No añadir base de datos nueva.
-- No hacer cambios destructivos.
-- Mantener la implementación pequeña, clara y orientada a desarrollo local.
-
-## Validation
-- Existe un cliente A2S mínimo reutilizable desde el backend.
-- El cliente puede obtener metadata básica de servidor.
-- La salida se normaliza al modelo interno del proyecto.
-- La documentación backend refleja el nuevo estado.
-
-## Change Budget
-- Preferir menos de 6 archivos modificados o creados.
-- Preferir menos de 260 líneas cambiadas.
-
-## Outcome
-- Se anadio un cliente A2S minimo en `backend/app/a2s_client.py` usando solo libreria estandar para consultar `A2S_INFO`.
-- `backend/app/normalizers.py` ahora puede convertir una respuesta A2S al modelo interno de snapshots ya usado por el proyecto.
-- `backend/app/collector.py` expone `fetch_a2s_probe()` como adaptador pequeno reutilizable para la siguiente task de integracion del pipeline.
-- `backend/app/__init__.py` mantiene acceso ligero a `query_server_info()` y `fetch_a2s_probe()` sin acoplar la carga del paquete al CLI del cliente.
-- `backend/README.md` documenta el nuevo estado y una prueba manual local del cliente.
-
-## Validation Result
-- Ejecutado: `python -m compileall backend/app`
-- Resultado: compilacion correcta de los modulos del backend.
-- Ejecutado: `python -m app.a2s_client --help`
-- Resultado: CLI disponible sin warnings y con los argumentos esperados.
-
-## Decision Notes
-- Se mantuvo la implementacion en libreria estandar con UDP directo para evitar introducir dependencias antes de validar targets y configuracion en las siguientes tasks.

ai/tasks/done/TASK-024-remove-ip-ui-and-add-historic-links.md

@@ -1,95 +0,0 @@
-# TASK-024-remove-ip-ui-and-add-historic-links
-
-## Goal
-Eliminar de la landing toda referencia visible a IP o direccion de servidor y sustituir el boton actual por un boton `Historico` que lleve a la pagina de historial correcta de cada uno de los 2 servidores reales de la comunidad.
-
-## Context
-La UI actual del bloque de servidores sigue mostrando informacion relacionada con IP/direccion y un CTA heredado que ya no encaja con el comportamiento deseado. A partir de ahora no debe mostrarse nada relacionado con IP en la pagina. En su lugar, cada card de servidor debe incluir un boton `Historico` que abra la pagina de historial correspondiente al servidor real de la comunidad.
-
-Los destinos correctos son:
-- Servidor `#01 [ESP] Comunidad Hispana - discord.comunidadhll.es - Spa Onl` -> `https://scoreboard.comunidadhll.es/games`
-- Servidor `#02 [ESP] Comunidad Hispana - discord.comunidadhll.es - Spa Onl` -> `https://scoreboard.comunidadhll.es:5443/games`
-
-La solucion debe usar una asignacion estable basada en la identidad real de cada servidor de la comunidad y no depender de mostrar IP en la UI.
-
-## Steps
-1. Revisar la implementacion actual del bloque de servidores en:
-   - HTML estatico/fallback
-   - renderizado hidratado desde JS
-   - payload y campos expuestos desde backend si afectan a la UI
-2. Eliminar de la UI cualquier referencia visible a:
-   - IP
-   - direccion
-   - host:puerto
-   - textos como `Direccion`
-   - acciones tipo `Copiar IP`
-3. Sustituir el CTA actual de cada card por un boton `Historico`.
-4. Hacer que el boton `Historico` abra el destino correcto segun el servidor:
-   - servidor #01 -> `https://scoreboard.comunidadhll.es/games`
-   - servidor #02 -> `https://scoreboard.comunidadhll.es:5443/games`
-5. Asegurar que la asignacion se basa en la identidad estable del servidor de comunidad y no en una logica fragil o dependiente del orden accidental.
-6. Mantener la compatibilidad entre:
-   - fallback estatico
-   - renderizado dinamico por JS
-7. Si la UI actual necesita un campo alternativo donde antes estaba la IP, reorganizar la card para que siga viendose equilibrada sin exponer datos de red.
-8. Mantener visibles solo los 2 servidores reales de la comunidad.
-9. No reintroducir servidores ficticios ni CTAs rotos.
-10. Verificar que los enlaces abren correctamente las paginas de historico en una nueva pestana o de la forma UX mas segura/coherente con la landing.
-11. Al completar la implementacion:
-   - 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
-- frontend/index.html
-- frontend/assets/js/main.js
-- frontend/assets/css/styles.css
-- backend/app/payloads.py
-- backend/app/routes.py
-- docs/frontend-backend-contract.md
-
-## Expected Files to Modify
-- frontend/index.html
-- frontend/assets/js/main.js
-- frontend/assets/css/styles.css
-- opcionalmente backend/app/payloads.py si hace falta exponer un identificador mas limpio para mapear cada servidor a su historico
-- opcionalmente documentacion minima si cambia el comportamiento esperado del CTA del panel
-
-## Constraints
-- No mostrar IP, direccion o datos equivalentes en la UI.
-- No dejar botones rotos.
-- No cambiar los 2 servidores reales de la comunidad.
-- No anadir librerias nuevas.
-- No romper el polling ni la hidratacion actual.
-- No romper el fallback estatico.
-- No hacer cambios destructivos.
-- Mantener la solucion visualmente coherente con la landing.
-
-## Validation
-- Ya no aparece ningun dato de IP/direccion en la UI del bloque de servidores.
-- El boton `Copiar IP` desaparece por completo.
-- Cada servidor muestra un boton `Historico`.
-- El boton del servidor #01 abre `https://scoreboard.comunidadhll.es/games`.
-- El boton del servidor #02 abre `https://scoreboard.comunidadhll.es:5443/games`.
-- La asignacion es estable tanto en fallback estatico como en renderizado dinamico.
-- Los cambios quedan committeados y se hace push si el entorno lo permite.
-
-## Change Budget
-- Preferir menos de 5 archivos modificados.
-- Preferir menos de 200 lineas cambiadas.
-
-## Outcome
-- `frontend/index.html` elimina la IP visible del fallback estatico y sustituye el CTA por enlaces `Historico` hacia el scoreboard correcto de cada servidor real.
-- `frontend/assets/js/main.js` deja de renderizar direccion o acciones de copiado y asigna cada enlace de historico mediante `external_server_id` estable.
-- `frontend/assets/css/styles.css` adapta el estilo del CTA para mantener la tarjeta equilibrada sin exponer datos de red.
-
-## Validation Result
-- Validado con `node --check frontend/assets/js/main.js`.
-- Verificado con `rg` que ya no quedan en `frontend/` textos o atributos de `Copiar IP`, `Direccion`, `data-copy-address`, `server-copy-button` ni las IPs de los servidores.
-- Revisado con `git diff --name-only`: el cambio de esta task queda acotado a `frontend/index.html`, `frontend/assets/js/main.js`, `frontend/assets/css/styles.css` y este archivo de task.
-
-## Decision Notes
-- La asignacion del enlace `Historico` en renderizado dinamico se resuelve unicamente con `external_server_id` para evitar dependencia del orden accidental o de datos de red expuestos en UI.

ai/tasks/done/TASK-025-a2s-source-configuration-and-target-registry.md

@@ -1,67 +0,0 @@
-# TASK-025-a2s-source-configuration-and-target-registry
-
-## Goal
-Definir y preparar una configuración limpia para registrar servidores objetivo de prueba consultables por A2S, de forma que el backend pueda trabajar con una lista controlada de targets sin acoplarse a valores hardcodeados.
-
-## Context
-Una vez que exista un cliente A2S mínimo, el proyecto necesita una manera clara de declarar qué servidores de HLL actual se usarán como fuentes de prueba. Esta task debe dejar preparada una configuración o registro simple de targets A2S, reutilizable por el colector y fácil de adaptar en desarrollo.
-
-## Steps
-1. Revisar la configuración actual del backend.
-2. Definir una forma clara de registrar targets A2S de prueba, incluyendo al menos:
-   - nombre amigable
-   - host o IP
-   - query port
-   - contexto o etiqueta de fuente
-3. Mantener el diseño desacoplado del resto del backend y fácil de ampliar.
-4. Permitir que el colector lea esa configuración sin depender de valores hardcodeados dentro de la lógica principal.
-5. Documentar cómo añadir, quitar o modificar servidores de prueba en entorno local.
-6. Mantener el alcance en configuración y registro de targets, no en analítica avanzada.
-
-## Files to Read First
-- AGENTS.md
-- ai/repo-context.md
-- docs/current-hll-data-ingestion-plan.md
-- backend/README.md
-- backend/app/config.py
-- backend/app/collector.py
-- backend/app/storage.py
-- backend/app/a2s_client.py si ya existe por la task anterior
-
-## Expected Files to Modify
-- backend/README.md
-- backend/app/config.py
-- backend/app/collector.py
-- opcionalmente archivos nuevos dentro de backend/app/ si mejoran claridad, por ejemplo:
-  - backend/app/server_targets.py
-
-## Constraints
-- No tocar frontend.
-- No introducir infraestructura compleja.
-- No añadir dependencias innecesarias.
-- No hacer cambios destructivos.
-- Mantener la configuración simple y orientada a pruebas.
-
-## Validation
-- El backend dispone de una lista configurable de targets A2S.
-- El colector puede leer esos targets sin depender de constantes dispersas.
-- La documentación deja claro cómo configurar servidores de prueba.
-
-## Change Budget
-- Preferir menos de 5 archivos modificados o creados.
-- Preferir menos de 180 líneas cambiadas.
-
-## Outcome
-- Se anadio `backend/app/server_targets.py` con un registro pequeno de targets A2S y una carga desacoplada en forma de dataclass.
-- `backend/app/config.py` ahora soporta `HLL_BACKEND_A2S_TARGETS` para sobrescribir la lista con un array JSON en desarrollo local.
-- `backend/app/collector.py` puede resolver los targets configurados mediante `fetch_configured_a2s_probes()` sin depender de valores hardcodeados en su logica principal.
-- `backend/README.md` documenta la ubicacion del registro y como anadir, quitar o modificar targets de prueba.
-
-## Validation Result
-- Ejecutado: `python -m compileall backend/app`
-- Resultado: compilacion correcta de los modulos del backend.
-- Ejecutado: `python -c "from app.server_targets import load_a2s_targets; print(load_a2s_targets())"`
-- Resultado: el registro carga el target por defecto con la estructura esperada.
-
-## Decision Notes
-- Se eligio JSON en variable de entorno para mantener el override simple, local y sin introducir un nuevo formato de configuracion ni dependencias externas.

ai/tasks/done/TASK-025-repo-hygiene-and-dev-artifacts-cleanup.md

@@ -1,87 +0,0 @@
-# TASK-025-repo-hygiene-and-dev-artifacts-cleanup
-
-## Goal
-Dejar el repositorio HLL Vietnam en un estado mas limpio y consistente eliminando o regularizando artefactos locales de desarrollo, ficheros de lock y residuos de workflow que no deberian quedar como ruido permanente en el worktree.
-
-## Context
-Despues de varias tasks ejecutadas por el workflow, siguen apareciendo residuos locales o inconsistencias de higiene del repositorio, entre ellos:
-- `ai/worker.lock`
-- `backend/data/hll_vietnam_dev.sqlite3`
-- `ai/tasks/done/TASK-021-server-status-periodic-query-and-display.md` como untracked o no regularizado
-- posibles cambios locales en `backend/app/config.py`
-
-Estos elementos no forman parte directa del valor de producto visible, pero si afectan a la salud del repositorio, al flujo del worker y a la claridad del estado git. Hace falta una pasada de limpieza controlada para dejar reglas claras sobre que debe versionarse y que debe considerarse artefacto local de desarrollo.
-
-## Steps
-1. Revisar el estado actual del repositorio y confirmar que archivos siguen quedando como ruido local o inconsistencias.
-2. Analizar especificamente:
-   - `ai/worker.lock`
-   - `backend/data/hll_vietnam_dev.sqlite3`
-   - `ai/tasks/done/TASK-021-server-status-periodic-query-and-display.md`
-   - `backend/app/config.py`
-3. Determinar para cada uno de ellos si debe:
-   - versionarse
-   - ignorarse
-   - regenerarse localmente
-   - moverse o regularizarse
-4. Ajustar `.gitignore` u otros mecanismos de higiene si hace falta.
-5. Asegurar que los artefactos locales de desarrollo no sigan ensuciando el worktree innecesariamente.
-6. Regularizar el estado de la task `TASK-021` si quedo fuera del flujo esperado.
-7. Documentar de forma minima, si hace falta, el tratamiento esperado de snapshots persistidos, locks locales y otros artefactos de runtime.
-8. No tocar logica funcional de producto salvo que sea estrictamente necesario para dejar el repo coherente.
-9. Al completar la implementacion:
-   - dejar el repositorio consistente
-   - hacer commit
-   - hacer push al remoto si el entorno lo permite
-
-## Files to Read First
-- AGENTS.md
-- .gitignore
-- ai/README.md
-- ai/orchestrator/README.md
-- backend/README.md
-- backend/app/config.py
-- cualquier documentacion existente sobre snapshots o runtime local
-- salida actual de `git status`
-
-## Expected Files to Modify
-- .gitignore
-- backend/README.md
-- opcionalmente ai/README.md o documentacion minima si hace falta aclarar el tratamiento de artefactos locales
-- opcionalmente regularizacion de archivos en `ai/tasks/done/`
-- opcionalmente eliminacion o exclusion de artefactos locales no deseados
-
-## Constraints
-- No romper el workflow actual del proyecto.
-- No eliminar informacion util sin justificarlo.
-- No tocar frontend salvo que fuera completamente imprescindible.
-- No introducir cambios funcionales de producto.
-- No hacer cambios destructivos fuera del objetivo de higiene del repo.
-- Mantener el resultado claro, pequeno y seguro.
-
-## Validation
-- El worktree queda sensiblemente mas limpio.
-- Los artefactos de desarrollo local quedan tratados de forma explicita.
-- `ai/worker.lock` no queda como ruido permanente si no debe versionarse.
-- El tratamiento de `backend/data/hll_vietnam_dev.sqlite3` queda resuelto.
-- `TASK-021` queda regularizada si estaba fuera del flujo.
-- Los cambios quedan committeados y se hace push al remoto si el entorno lo permite.
-
-## Change Budget
-- Preferir menos de 6 archivos modificados.
-- Preferir menos de 180 lineas cambiadas.
-
-## Outcome
-- `.gitignore` pasa a tratar `ai/worker.lock` y `backend/data/*.sqlite3` como artefactos locales de runtime en lugar de ruido permanente versionado.
-- `backend/data/.gitkeep` mantiene el directorio de datos en el repositorio sin forzar que la base SQLite de desarrollo quede commiteada.
-- `ai/tasks/done/TASK-021-server-status-periodic-query-and-display.md` queda regularizada dentro del historial versionado de tasks completadas.
-- El cambio pendiente de `backend/app/config.py` queda absorbido como parte de la regularizacion de `TASK-021`, en lugar de seguir apareciendo como residuo suelto.
-
-## Validation Result
-- Revisado `git status --short` para confirmar que el ruido original del worktree quedaba centrado en `ai/worker.lock`, `backend/data/hll_vietnam_dev.sqlite3`, `backend/app/config.py` y la task `TASK-021`.
-- Revisadas las referencias de runtime en `scripts/codex-runner.ps1`, `backend/app/config.py` y `backend/README.md` para confirmar que el lock y la SQLite son artefactos regenerables de desarrollo local.
-- Validacion final prevista: `git diff --name-only` debe reflejar solo la higiene de ignores, la regularizacion de archivos versionados y la task cerrada.
-
-## Decision Notes
-- `ai/worker.lock` se trata como lock efimero del runner local y no aporta valor historico en git.
-- `backend/data/hll_vietnam_dev.sqlite3` se mantiene como persistencia local regenerable; el contrato util esta en codigo y documentacion, no en una base SQLite concreta del worktree.

ai/tasks/done/TASK-026-a2s-backed-snapshot-collection.md

@@ -1,74 +0,0 @@
-# TASK-026-a2s-backed-snapshot-collection
-
-## Goal
-Hacer que el colector de snapshots del backend pueda capturar datos reales desde servidores HLL consultables por A2S y persistir esos snapshots en la base local ya preparada.
-
-## Context
-El proyecto ya tiene persistencia local, consultas históricas mínimas y un bootstrap de colector. Tras introducir un cliente A2S y una configuración de targets, el siguiente paso es cerrar el primer flujo real de captura y persistencia sobre servidores actuales de HLL.
-
-## Steps
-1. Revisar el colector actual, la persistencia local y el cliente A2S.
-2. Integrar el cliente A2S dentro del flujo de colecta de snapshots.
-3. Hacer que el colector capture datos desde los targets configurados y los normalice al modelo interno.
-4. Persistir los snapshots reales usando la capa de almacenamiento ya existente.
-5. Manejar de forma controlada los casos de timeout, servidor inaccesible o respuesta inválida.
-6. Mantener la posibilidad de usar datos controlados o fallback de desarrollo si la fuente real no responde.
-7. Actualizar la documentación backend para explicar el flujo de captura real en esta fase.
-8. Mantener el alcance centrado en captura y persistencia, no en nuevas visualizaciones.
-
-## Files to Read First
-- AGENTS.md
-- ai/repo-context.md
-- ai/architecture-index.md
-- docs/current-hll-data-ingestion-plan.md
-- docs/stats-database-schema-foundation.md
-- backend/README.md
-- backend/app/__init__.py
-- backend/app/config.py
-- backend/app/collector.py
-- backend/app/normalizers.py
-- backend/app/snapshots.py
-- backend/app/storage.py
-- backend/app/a2s_client.py
-- backend/app/server_targets.py si existe
-
-## Expected Files to Modify
-- backend/README.md
-- backend/app/collector.py
-- backend/app/normalizers.py
-- backend/app/storage.py
-- opcionalmente archivos auxiliares nuevos si son estrictamente necesarios para mantener claridad
-
-## Constraints
-- No tocar frontend en esta task.
-- No introducir todavía estadísticas complejas.
-- No añadir scraping de terceros.
-- No hacer cambios destructivos.
-- Mantener el pipeline claro, comprobable y pequeño.
-
-## Validation
-- El colector puede capturar snapshots reales desde al menos un target A2S configurado.
-- Los snapshots se persisten en la base local actual.
-- Los errores de consulta quedan manejados de forma razonable.
-- La documentación backend refleja cómo ejecutar esta captura en local.
-
-## Change Budget
-- Preferir menos de 6 archivos modificados o creados.
-- Preferir menos de 240 líneas cambiadas.
-
-## Outcome
-- `backend/app/collector.py` ahora puede ejecutar captura en modo `a2s`, `controlled` o `auto`, persistiendo snapshots reales cuando las consultas A2S tienen exito.
-- El colector registra errores por target sin abortar todo el lote y usa fallback controlado cuando no obtiene respuestas reales y el fallback esta habilitado.
-- `backend/app/storage.py` persiste `source_name` por snapshot para conservar la procedencia efectiva de cada captura.
-- `backend/README.md` documenta como ejecutar captura real, captura controlada y captura automatica con fallback en local.
-
-## Validation Result
-- Ejecutado: `python -m compileall backend/app`
-- Resultado: compilacion correcta de los modulos del backend.
-- Ejecutado: validacion con `collect_server_snapshots(source_mode="a2s", persist=True, probe_target=stub_probe)` sobre SQLite temporal.
-- Resultado: flujo A2S simulado persistio 1 snapshot y `list_snapshot_history()` devolvio 1 registro.
-- Ejecutado: validacion con `collect_server_snapshots(source_mode="auto", timeout=0.1, persist=True)` usando el target local por defecto.
-- Resultado: el colector registro 1 error de consulta, activo fallback controlado y persistio 3 snapshots de desarrollo.
-
-## Decision Notes
-- Se mantuvo un fallback explicito de desarrollo para no romper el flujo local mientras los targets A2S reales siguen siendo configurables y potencialmente inestables.

ai/tasks/done/TASK-026-landing-final-qa-pass.md

@@ -1,97 +0,0 @@
-# TASK-026-landing-final-qa-pass
-
-## Goal
-Realizar una pasada final de QA funcional y visual sobre la landing actual de HLL Vietnam para detectar y corregir pequenos defectos de presentacion, consistencia o comportamiento antes de pasar a una nueva linea de trabajo mas analitica e historica.
-
-## Context
-La landing ya dispone de:
-- hero estable
-- CTA principal a Discord
-- trailer
-- panel de servidores con 2 servidores reales de la comunidad
-- snapshots actuales con polling backend
-- boton `Historico` funcional por servidor
-
-Antes de entrar en la siguiente fase del proyecto (estadisticas e historico), conviene hacer una revision final de calidad sobre la version actual para corregir detalles pequenos de UX, responsive, textos, alineacion visual y funcionamiento de enlaces.
-
-## Steps
-1. Revisar la landing completa en su estado actual.
-2. Validar el comportamiento y acabado de:
-   - hero
-   - CTA principal de Discord
-   - trailer
-   - panel de servidores
-   - badges de actualizacion
-   - botones `Historico`
-3. Revisar posibles problemas pequenos como:
-   - textos cortados o saltos raros
-   - alineaciones inconsistentes
-   - spacing irregular
-   - badges o chips descompensados
-   - estados visuales poco claros
-   - fallback estatico vs UI hidratada con diferencias no deseadas
-4. Revisar que los 2 botones `Historico` apunten correctamente a:
-   - `https://scoreboard.comunidadhll.es/games`
-   - `https://scoreboard.comunidadhll.es:5443/games`
-5. Revisar que el badge de actualizacion use datos reales y no texto ficticio.
-6. Revisar el comportamiento responsive basico de la landing.
-7. Corregir unicamente defectos pequenos o medianos detectados en esta pasada.
-8. No abrir redisenos grandes ni nuevos bloques funcionales.
-9. Al completar la implementacion:
-   - dejar el repositorio consistente
-   - hacer commit
-   - hacer push al remoto si el entorno lo permite
-
-## Files to Read First
-- AGENTS.md
-- frontend/index.html
-- frontend/assets/css/styles.css
-- frontend/assets/js/main.js
-- backend/app/payloads.py
-- backend/app/routes.py
-- docs/frontend-backend-contract.md
-- ai/repo-context.md
-
-## Expected Files to Modify
-- frontend/index.html
-- frontend/assets/css/styles.css
-- frontend/assets/js/main.js
-- opcionalmente documentacion minima si se detecta que algun comportamiento visible necesita quedar reflejado
-
-## Constraints
-- No redisenar la landing completa.
-- No cambiar la arquitectura backend actual.
-- No introducir nuevas features grandes.
-- No anadir librerias nuevas.
-- No romper polling, snapshot o hidratacion actual.
-- No hacer cambios destructivos.
-- Mantener el trabajo centrado en QA final y correcciones concretas.
-
-## Validation
-- La landing queda mas consistente y pulida.
-- No hay defects visibles relevantes en el flujo principal.
-- Los 2 servidores correctos siguen mostrandose.
-- Los enlaces de `Historico` funcionan correctamente.
-- El badge de actualizacion sigue reflejando un dato real.
-- Los cambios quedan committeados y se hace push si el entorno lo permite.
-
-## Change Budget
-- Preferir menos de 4 archivos modificados.
-- Preferir menos de 180 lineas cambiadas.
-
-## Outcome
-- `frontend/index.html` alinea el polling visible de la landing con el backend a `120000` ms y aclara que el panel usa snapshots consultados desde backend.
-- `frontend/assets/js/main.js` deja de insertar una segunda rejilla dentro de `#servers-list`, con lo que el fallback estatico y la UI hidratada comparten la misma estructura visual.
-- El badge de actualizacion distingue snapshot fresco frente a snapshot stale usando el dato real `last_snapshot_at` y el flag `is_stale`.
-- Se mantiene la ruta correcta de ambos botones `Historico` hacia los dos scoreboards de la comunidad.
-- `frontend/assets/css/styles.css` corrige un detalle menor de consistencia en el bloque del CTA secundario de tarjetas.
-
-## Validation Result
-- Validado con `node --check frontend/assets/js/main.js`.
-- Verificadas en codigo las URLs `https://scoreboard.comunidadhll.es/games` y `https://scoreboard.comunidadhll.es:5443/games` tanto en el fallback HTML como en el mapeo dinamico de `SERVER_HISTORY_URLS`.
-- Verificado en fuente que `data-server-refresh-ms="120000"` queda alineado con el intervalo por defecto documentado para snapshots.
-- Revisado `git diff --name-only`: el alcance queda limitado a `frontend/index.html`, `frontend/assets/js/main.js`, `frontend/assets/css/styles.css` y este archivo de task.
-
-## Decision Notes
-- La pasada de QA se limita a consistencia visual y semantica del estado visible; no abre nuevas features ni cambia el contrato backend.
-- Para evitar otra divergencia entre fallback y estado hidratado, el contenedor `#servers-list` se mantiene como rejilla unica y la hidratacion solo reemplaza sus tarjetas internas.

ai/tasks/done/TASK-027-a2s-history-visibility-polish.md

@@ -1,61 +0,0 @@
-# TASK-027-a2s-history-visibility-polish
-
-## Goal
-Ajustar la capa de visualización actual para que la web pueda distinguir de forma clara cuándo muestra datos históricos procedentes de snapshots A2S reales frente a placeholders o fallbacks estáticos.
-
-## Context
-Una vez que la captura A2S real esté operativa, conviene hacer visible en frontend la procedencia efectiva de los datos sin convertir la landing en un dashboard complejo. Esta task debe mejorar la claridad del bloque actual de servidores y estadísticas sin rediseñarlo completamente.
-
-## Steps
-1. Revisar el frontend actual y el bloque de estadísticas/servidores existente.
-2. Revisar el formato real de los endpoints históricos tras la integración A2S.
-3. Añadir una mejora visual o de estado que permita reflejar claramente si los datos mostrados son:
-   - snapshots reales recientes
-   - datos persistidos antiguos
-   - fallback estático
-4. Mantener la mejora discreta y coherente con la landing actual.
-5. No convertir la página en una aplicación compleja ni añadir navegación nueva.
-6. Preservar el fallback si el backend no está disponible.
-
-## Files to Read First
-- AGENTS.md
-- ai/repo-context.md
-- docs/frontend-data-consumption-plan.md
-- frontend/index.html
-- frontend/assets/js/main.js
-- frontend/assets/css/styles.css
-- backend/app/routes.py
-- backend/app/payloads.py
-
-## Expected Files to Modify
-- frontend/index.html
-- frontend/assets/js/main.js
-- frontend/assets/css/styles.css
-
-## Constraints
-- No rediseñar toda la landing.
-- No añadir librerías nuevas.
-- No tocar backend salvo referencias documentales mínimas si hicieran falta.
-- No hacer cambios destructivos.
-- Mantener la mejora contenida y alineada con la fase actual.
-
-## Validation
-- La web distingue visualmente entre datos reales A2S, históricos persistidos y fallback estático cuando aplique.
-- La integración visual sigue siendo coherente con la landing.
-- El frontend sigue funcionando si el backend no responde.
-
-## Change Budget
-- Preferir menos de 4 archivos modificados.
-- Preferir menos de 180 líneas cambiadas.
-
-## Outcome
-- `frontend/index.html` incorpora un bloque pequeno de procedencia para explicar si el panel muestra fallback estatico, historico persistido o snapshots A2S recientes.
-- `frontend/assets/js/main.js` clasifica el estado visible segun la procedencia y la antiguedad de los snapshots historicos sin romper el fallback actual.
-- `frontend/assets/css/styles.css` integra esos estados con una presentacion tactica discreta dentro del panel existente de servidores.
-
-## Validation Result
-- Ejecutado: `node --check frontend/assets/js/main.js`
-- Resultado: sintaxis valida en el script principal del frontend.
-
-## Decision Notes
-- La distincion entre `snapshots A2S recientes` y `historico persistido` se resuelve de forma ligera usando `source_name` y la antiguedad de `captured_at`, evitando cambios de contrato backend en esta fase.

ai/tasks/done/TASK-027-historical-crcon-source-discovery.md

@@ -1,125 +0,0 @@
-# TASK-027-historical-crcon-source-discovery
-
-## Goal
-Descubrir y documentar la fuente historica real mas estable para los 2 servidores de la comunidad, basada en CRCON/scoreboard, dejando claro como obtener datos historicos reutilizables para futuras estadisticas semanales y evitando depender de una implementacion previa ya descartada.
-
-## Context
-El proyecto ya tiene resuelta la parte de estado actual de servidores mediante A2S para la landing. La siguiente fase es historico y estadisticas agregadas, por ejemplo "jugadores con mas kills de la ultima semana por servidor".
-
-Se parte de dos hechos importantes:
-1. El historico NO debe construirse con A2S como fuente principal, porque A2S sirve para estado actual y no para historico retroactivo de partidas.
-2. Cualquier intento previo de historico semanal basado directamente en la pagina de la comunidad debe considerarse deshecho, invalido o no reutilizable como base de arquitectura para esta nueva fase.
-
-Ademas, el analisis tecnico previo apunta a que la fuente correcta para historico debe venir de la capa CRCON/scoreboard publico de los servidores de la comunidad, o de la fuente estructurada que alimenta dicho scoreboard.
-
-## Goal Detail
-Esta task NO debe implementar todavia la ingesta historica final ni endpoints de rankings. Su mision es descubrir con precision de donde salen los datos historicos, como se accede a ellos y cual es la estrategia tecnica mas estable para las siguientes tasks.
-
-## Steps
-1. Revisar el estado actual del proyecto para confirmar que la parte historica previa basada directamente en la pagina comunitaria no debe tomarse como base valida.
-2. Analizar las dos fuentes reales de historico asociadas a los servidores de la comunidad:
-   - `https://scoreboard.comunidadhll.es/games`
-   - `https://scoreboard.comunidadhll.es:5443/games`
-3. Investigar como cargan los datos esas paginas:
-   - peticiones XHR/fetch
-   - posibles endpoints JSON
-   - paginacion
-   - URLs de detalle de partida
-   - identificadores de match
-   - identificadores o claves de jugador
-   - filtros o parametros relevantes
-4. Determinar si la fuente utilizable mas estable es:
-   - una API/JSON expuesta por el scoreboard
-   - una estructura HTML parseable
-   - otra capa accesible derivada de CRCON
-5. Documentar que datos historicos parecen estar realmente disponibles y estables. Incluir al menos:
-   - servidor
-   - partida
-   - fecha/hora
-   - mapa
-   - jugador
-   - kills
-   - otras metricas relevantes si aparecen
-6. Documentar riesgos y limites:
-   - cambios de HTML
-   - dependencia de endpoints privados o fragiles
-   - ausencia de ids estables
-   - paginacion o limites de historico
-   - datos historicos posiblemente incompletos
-7. Proponer la estrategia recomendada para las siguientes fases, distinguiendo claramente entre:
-   - fuente historica ideal
-   - plan operativo inicial realista
-   - fallback si no existe API estructurada
-8. Dejar explicito que NO debe hacerse:
-   - no basar la arquitectura historica en A2S
-   - no asumir como valida una implementacion previa ya revertida
-   - no disenar todavia la UI historica
-9. Actualizar la documentacion tecnica del repositorio con el resultado del discovery.
-10. Al completar la implementacion:
-   - 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/decisions.md
-- docs/current-hll-servers-source-plan.md
-- docs/frontend-backend-contract.md
-- backend/README.md
-- cualquier documentacion o codigo existente relacionado con historico, scoreboard o CRCON
-- cualquier rastro de implementacion historica previa que haya quedado en el repositorio, solo para confirmar su descarte
-
-## Expected Files to Modify
-- ai/architecture-index.md
-- docs/decisions.md
-- opcionalmente backend/README.md si conviene reflejar el nuevo frente tecnico
-- un nuevo documento tecnico, por ejemplo:
-  - `docs/historical-crcon-source-discovery.md`
-
-## Constraints
-- No implementar todavia ingesta historica completa.
-- No implementar todavia endpoints de rankings.
-- No implementar todavia UI historica.
-- No basar la arquitectura historica en A2S.
-- No dar por buena ninguna implementacion historica previa que ya haya sido revertida o descartada.
-- No hacer cambios destructivos.
-- Mantener el trabajo centrado en discovery tecnico y documentacion solida.
-
-## Validation
-- Existe documentacion clara sobre la fuente historica real de los 2 servidores.
-- Queda claro si la fuente reutilizable es JSON/API, HTML parseable u otra capa.
-- Quedan identificados los datos historicos realmente disponibles.
-- Quedan documentados riesgos, limites y estrategia recomendada.
-- No se ha implementado todavia ingesta o UI prematura.
-- Los cambios quedan committeados y se hace push si el entorno lo permite.
-
-## Change Budget
-- Preferir menos de 5 archivos modificados o creados.
-- Preferir menos de 220 lineas cambiadas.
-
-## Outcome
-- Se documento que ambas URLs de scoreboard sirven una SPA y que la fuente historica reutilizable real es JSON bajo `baseURL: "/api"`.
-- Se verificaron y documentaron los endpoints historicos observados:
-  - `GET /api/get_public_info`
-  - `GET /api/get_scoreboard_maps?page={page}&limit={limit}`
-  - `GET /api/get_map_scoreboard?map_id={map_id}`
-- Se confirmo que `get_scoreboard_maps` aporta listado paginado de partidas y que `get_map_scoreboard` aporta detalle de partida con `player_stats` y metricas como `kills`, `deaths`, `teamkills`, `kills_per_minute`, `weapons`, `team.side` y `level`.
-- Se dejo documentado que el HTML de `/games` no debe ser la base tecnica de ingesta y que A2S sigue limitado al estado actual.
-- Se dejo constancia de que un intento previo de historico semanal no es base valida porque `backend/app/payloads.py` referencia `.historical_storage` pero ese modulo ya no existe.
-- Se actualizo `docs/decisions.md` y `ai/architecture-index.md` para alinear la arquitectura con esta discovery.
-
-## Validation Result
-- Ejecutado fuera del sandbox: inspeccion directa de `https://scoreboard.comunidadhll.es/games` y `https://scoreboard.comunidadhll.es:5443/games`.
-- Resultado: ambas rutas devuelven la misma SPA shell con bundle `index-DvMfaBhO.js`.
-- Ejecutado fuera del sandbox: extraccion del bundle frontend.
-- Resultado: el helper HTTP usa `axios.create({ baseURL: "/api" })`.
-- Ejecutado fuera del sandbox: `GET /api/get_public_info`, `GET /api/get_scoreboard_maps?page=1&limit=5` y `GET /api/get_map_scoreboard?map_id=...` en ambos scoreboards.
-- Resultado: se confirmaron identificacion por servidor, paginacion, ids de partida y metricas historicas por jugador.
-- Ejecutado localmente: revision de `backend/app/payloads.py` y busqueda de restos historicos con `rg`.
-- Resultado: se detecto un rastro previo no reutilizable de `weekly_top_kills` apoyado en un modulo ausente.
-
-## Decision Notes
-- La siguiente fase debe ingerir primero el listado de partidas por scoreboard y despues el detalle por `map_id`, manteniendo separados los dos origenes de la comunidad.
-- El plan operativo inicial debe persistir partidos y estadisticas por jugador en backend propio para calcular agregados semanales sin consultar el scoreboard en cada request.

ai/tasks/done/TASK-027-map-name-normalization-and-full-display.md

@@ -1,75 +0,0 @@
-# TASK-027-map-name-normalization-and-full-display
-
-## Goal
-Corregir la visualización del nombre de mapa en el panel actual de servidores para que se muestre correctamente, normalizado y completo, sin cortes ni etiquetas degradadas.
-
-## Context
-La landing ya muestra el estado actual de los 2 servidores reales de la comunidad, pero el campo de mapa presenta defectos visibles: nombres incompletos, abreviados de forma incorrecta o mal normalizados. Antes de avanzar con histórico y estadísticas, hay que dejar correcto este dato básico del estado actual.
-
-## Steps
-1. Revisar el origen actual del nombre de mapa en backend y frontend.
-2. Identificar si el problema viene de:
-   - dato crudo del query A2S
-   - normalización backend
-   - truncado o layout frontend
-3. Corregir la cadena de transformación para que el nombre del mapa mostrado sea correcto y completo.
-4. Aplicar una normalización coherente si el dato crudo usa nombres internos o variantes técnicas.
-5. Asegurar que el frontend no corte el nombre de mapa de forma incorrecta.
-6. Ajustar el layout si hace falta para que el mapa pueda verse entero dentro de la card.
-7. Mantener los 2 servidores reales de la comunidad y no alterar el resto del flujo.
-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
-- frontend/index.html
-- frontend/assets/css/styles.css
-- frontend/assets/js/main.js
-- backend/app/payloads.py
-- backend/app/routes.py
-- cualquier módulo de normalización o consulta de servidor existente
-- docs/frontend-backend-contract.md
-
-## Expected Files to Modify
-- backend/app/payloads.py
-- frontend/assets/js/main.js
-- frontend/assets/css/styles.css
-- opcionalmente frontend/index.html si el layout necesita un ajuste menor
-
-## Constraints
-- No introducir servidores ficticios.
-- No romper polling ni snapshot actual.
-- No añadir librerías nuevas.
-- No hacer cambios destructivos.
-- Mantener el trabajo centrado en exactitud del dato y presentación correcta del mapa.
-
-## Validation
-- El nombre del mapa se muestra correctamente.
-- El nombre del mapa se muestra completo.
-- No aparecen abreviaturas degradadas o cortes visuales incorrectos.
-- La landing mantiene su funcionamiento actual.
-- Los cambios quedan committeados y se hace push si el entorno lo permite.
-
-## Change Budget
-- Preferir menos de 4 archivos modificados.
-- Preferir menos de 160 líneas cambiadas.
-
-## Outcome
-- `backend/app/normalizers.py` incorpora una normalización pequeña de nombres de mapa para convertir alias técnicos o abreviados estables de HLL en nombres legibles para la landing.
-- `backend/app/payloads.py` reaplica esa normalización al leer snapshots persistidos, de modo que también se corrigen datos ya capturados como `StMarie` o `DEV_Q`.
-- `frontend/assets/js/main.js` marca el valor del quickfact de mapa con una clase dedicada.
-- `frontend/assets/css/styles.css` ajusta el wrapping del nombre de mapa para evitar cortes visuales degradados dentro de la card.
-
-## Validation Result
-- Ejecutado desde `backend/`: `python -` importando `build_servers_payload()`.
-- Resultado: `comunidad-hispana-01 => Developer Test Map` y `comunidad-hispana-02 => Sainte-Marie-du-Mont` en el payload devuelto por `/api/servers`.
-- Ejecutado desde raíz: `node --check frontend/assets/js/main.js`.
-- Resultado: validación de sintaxis correcta para el script frontend.
-- Revisado `git diff --name-only`.
-- Resultado: el alcance queda limitado a `backend/app/normalizers.py`, `backend/app/payloads.py`, `frontend/assets/js/main.js` y `frontend/assets/css/styles.css`.
-
-## Decision Notes
-- La corrección principal se aplica en backend para mantener un único punto de verdad entre snapshots nuevos y persistidos.
-- El ajuste visual en frontend se limita al campo de mapa para no alterar el layout general de la landing.

ai/tasks/done/TASK-028-historical-domain-model-and-storage-schema.md

@@ -1,102 +0,0 @@
-# TASK-028-historical-domain-model-and-storage-schema
-
-## Goal
-Definir e implementar la base de modelo de dominio y almacenamiento para estadísticas históricas de los 2 servidores reales de la comunidad, preparada para ingerir datos desde la capa JSON pública del scoreboard CRCON y para soportar rankings semanales posteriores.
-
-## Context
-La fase de discovery ya confirmó que la fuente histórica correcta para estos servidores no es A2S ni el HTML de `/games`, sino la capa JSON pública del scoreboard CRCON. El siguiente paso técnico es crear una base sólida de dominio y persistencia propia para poder ingerir datos históricos, deduplicarlos y consultarlos más adelante desde nuestra propia API.
-
-Esta task NO debe crear todavía páginas históricas en frontend ni depender de URLs públicas de la comunidad como solución de producto. La capa histórica debe vivir en backend, con persistencia propia y preparada para exponer endpoints internos del proyecto en fases posteriores.
-
-## Steps
-1. Revisar la documentación de discovery histórica ya creada y confirmar qué datos están disponibles desde la capa JSON pública del scoreboard CRCON.
-2. Definir el modelo de dominio histórico mínimo necesario. Incluir al menos:
-   - servidor
-   - partida
-   - mapa
-   - jugador
-   - estadísticas de jugador por partida
-   - ejecución de ingesta histórica
-3. Diseñar el esquema de almacenamiento local inicial para esa información.
-4. Definir claves e identidad estables para evitar duplicados. Incluir expresamente:
-   - identificación de partida
-   - identificación de servidor
-   - identificación de jugador
-   - estrategia de idempotencia
-5. Incluir campos suficientes para soportar futuras consultas como:
-   - top kills de la última semana por servidor
-   - partidas recientes por servidor
-   - mapas jugados
-6. Implementar la base de almacenamiento/esquema local de forma coherente con el backend actual del proyecto.
-7. Mantener clara la separación entre:
-   - estado actual vía A2S
-   - histórico persistido vía CRCON scoreboard JSON
-8. Documentar la estructura creada y cómo se usará en las siguientes tasks.
-9. No implementar todavía:
-   - UI histórica
-   - páginas nuevas basadas en la URL de la comunidad
-   - redirecciones o vistas que repliquen la web de la comunidad
-   - rankings finales expuestos al frontend
-10. 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/decisions.md
-- docs/historical-crcon-source-discovery.md
-- backend/README.md
-- backend/app/config.py
-- backend/app/routes.py
-- backend/app/payloads.py
-- cualquier almacenamiento local o capa de persistencia ya existente en `backend/`
-- cualquier módulo collector o snapshot ya existente que pueda influir en la estructura de datos
-
-## Expected Files to Modify
-- ai/architecture-index.md
-- docs/decisions.md
-- backend/README.md
-- uno o más archivos nuevos de backend para almacenamiento histórico, por ejemplo:
-  - backend/app/historical_models.py
-  - backend/app/historical_storage.py
-  - backend/app/historical_schema.py
-- opcionalmente un documento nuevo, por ejemplo:
-  - docs/historical-domain-model.md
-
-## Constraints
-- No basar esta capa histórica en A2S.
-- No crear páginas frontend nuevas usando la URL de la comunidad.
-- No incrustar ni replicar directamente páginas de `scoreboard.comunidadhll.es`.
-- No implementar todavía ingesta completa ni UI histórica.
-- No romper el flujo actual de estado en tiempo real.
-- No introducir complejidad innecesaria.
-- No hacer cambios destructivos.
-- Mantener el trabajo centrado en dominio, persistencia e idempotencia.
-
-## Validation
-- Existe un modelo de dominio histórico claro para los 2 servidores.
-- Existe una base de almacenamiento/esquema local coherente con ese modelo.
-- La estructura permite futuras consultas como top kills semanales por servidor.
-- Queda clara la separación entre live status y histórico persistido.
-- No se han creado páginas frontend nuevas ni soluciones basadas en URLs de la comunidad.
-- Los cambios quedan committeados y se hace push al remoto si el entorno lo permite.
-
-## Change Budget
-- Preferir menos de 7 archivos modificados o creados.
-- Preferir menos de 260 líneas cambiadas.
-## Outcome
-- Se añadio `backend/app/historical_models.py` como capa minima de dominio para servidor, mapa, partida, jugador, estadisticas por partida y ejecucion de ingesta.
-- Se implemento `backend/app/historical_storage.py` con tablas `historical_*` separadas del flujo live A2S, claves estables e `UPSERT` idempotente para partidas, jugadores y estadisticas por jugador.
-- Se documento el modelo e identidad estable en `docs/historical-domain-model.md`, y se alinearon `docs/decisions.md`, `ai/architecture-index.md` y `backend/README.md`.
-- La inicializacion de storage incluye migracion segura desde una version legacy ya existente en la base SQLite local, preservando los datos previos en la nueva estructura.
-
-## Validation Result
-- Validado con `python -m compileall app` desde `backend/`.
-- Validado con una comprobacion local de `initialize_historical_storage()`, `list_historical_servers()` y `list_recent_historical_matches(limit=3)`.
-- Revisado `git diff --name-only` para confirmar que el cambio quedo centrado en `ai/`, `docs/`, `backend/` y archivos de task.
-
-## Decision Notes
-- El historico CRCON comparte el mismo SQLite local de desarrollo que los snapshots A2S para no introducir infraestructura prematura, pero queda estrictamente separado por tablas `historical_*`.

ai/tasks/done/TASK-028-real-a2s-target-onboarding.md

@@ -1,72 +0,0 @@
-# TASK-028-real-a2s-target-onboarding
-
-## Goal
-Dar de alta el primer target A2S real verificado del proyecto, correspondiente a Comunidad Hispana #01, integrandolo en la configuracion del backend de forma clara, mantenible y documentada.
-
-## Context
-El backend ya dispone de cliente A2S, registro configurable de targets y colector integrado con persistencia. Ademas, ya se ha identificado un target real consultable por A2S:
-- Comunidad Hispana #01
-- Host/IP: 152.114.195.174
-- Query Port: 7778
-- Game Port: 7777
-
-El objetivo de esta task es incorporar ese target real a la configuracion del proyecto sin asumir otros servidores aun no verificados.
-
-## Steps
-1. Revisar la configuracion actual de targets A2S del backend.
-2. Anadir el target real verificado de Comunidad Hispana #01 usando:
-   - nombre amigable claro
-   - host/IP: `152.114.195.174`
-   - query port: `7778`
-   - etiqueta o contexto de fuente coherente con el proyecto
-3. Asegurar que la configuracion no dependa de valores hardcodeados dispersos fuera del registro o capa configurada.
-4. Mantener separada la nocion de query port y game port para evitar confusiones.
-5. Reflejar en la documentacion del backend como esta registrado este primer target real.
-6. Dejar claro en documentacion que Comunidad Hispana #02 no debe anadirse aun sin confirmar su query port real.
-7. Mantener el cambio pequeno y estrictamente centrado en onboarding de target.
-
-## Files to Read First
-- AGENTS.md
-- ai/repo-context.md
-- ai/architecture-index.md
-- backend/README.md
-- backend/app/config.py
-- backend/app/server_targets.py
-- backend/app/collector.py
-- backend/app/a2s_client.py
-
-## Expected Files to Modify
-- backend/README.md
-- backend/app/config.py
-- backend/app/server_targets.py
-- opcionalmente backend/app/collector.py si necesita alineacion menor para consumir el target de forma limpia
-
-## Constraints
-- No tocar frontend.
-- No introducir nuevos targets no verificados.
-- No asumir datos de Comunidad Hispana #02.
-- No anadir scraping.
-- No hacer cambios destructivos.
-- Mantener la configuracion simple y clara.
-
-## Validation
-- El backend contiene el target real de Comunidad Hispana #01 correctamente registrado.
-- El query port configurado es `7778`.
-- La documentacion deja claro como esta definido este target.
-- No se han introducido targets inciertos o ambiguos.
-
-## Change Budget
-- Preferir menos de 4 archivos modificados.
-- Preferir menos de 140 lineas cambiadas.
-
-## Outcome
-- `backend/app/server_targets.py` registra por defecto solo `Comunidad Hispana #01` con `host` real, `query_port` verificado y `game_port` separado como dato opcional de referencia.
-- `backend/app/config.py` centraliza el `source_name` por defecto para evitar valores dispersos en el registro A2S.
-- `backend/README.md` documenta el target real incorporado y deja explicito que Comunidad Hispana #02 no debe anadirse hasta confirmar su `query_port`.
-
-## Validation Result
-- Ejecutado desde `backend/`: `python -` importando `load_a2s_targets()`.
-- Resultado: el registro carga `Comunidad Hispana #01` con `host=152.114.195.174`, `query_port=7778`, `game_port=7777` y `source_name=community-hispana-a2s`.
-
-## Decision Notes
-- Se mantiene `game_port` fuera de la logica de consulta A2S y solo como metadato opcional del target para evitar confundirlo con `query_port`.

ai/tasks/done/TASK-029-historical-crcon-ingestion-bootstrap.md

@@ -1,97 +0,0 @@
-# TASK-029-historical-crcon-ingestion-bootstrap
-
-## Goal
-Implementar una ingesta histórica inicial desde la capa JSON pública del scoreboard CRCON para los 2 servidores reales de la comunidad, persistiendo datos estructurados e idempotentes en el almacenamiento histórico propio del proyecto.
-
-## Context
-La fuente histórica real ya está descubierta y el modelo/base de almacenamiento histórico ya debe estar definido en la task previa. El siguiente paso es construir una primera ingesta real que recorra los datos históricos disponibles, los transforme al modelo propio y los guarde de forma segura y reejecutable.
-
-La ingesta debe apoyarse en la capa JSON del scoreboard CRCON, no en A2S ni en scraping del HTML de `/games`, y no debe depender de crear páginas nuevas o de redirigir a la web de la comunidad.
-
-## Steps
-1. Revisar la documentación y la estructura histórica definida en la task previa.
-2. Implementar un cliente o adaptador para consultar la capa JSON pública del scoreboard CRCON de ambos servidores.
-3. Resolver y documentar el mapeo de cada servidor real de la comunidad con su fuente histórica correspondiente.
-4. Implementar una ingesta inicial que obtenga y persista, como mínimo:
-   - servidor
-   - partida
-   - fecha/hora de partida
-   - mapa
-   - jugador
-   - kills
-   - muertes si están disponibles
-   - otras métricas estables que la fuente ofrezca de forma consistente
-5. Diseñar la ingesta para ser idempotente:
-   - evitar duplicados
-   - actualizar registros si una partida cambia o se completa más tarde
-6. Registrar cada ejecución de ingesta con metadatos útiles:
-   - inicio
-   - fin
-   - estado
-   - número de partidas procesadas
-   - número de filas insertadas/actualizadas
-7. Documentar cómo lanzar la ingesta manualmente en local.
-8. Mantener intacto el flujo actual de estado en tiempo real.
-9. No implementar todavía endpoints finales de ranking ni UI histórica.
-10. 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/historical-crcon-source-discovery.md
-- docs/historical-domain-model.md
-- backend/README.md
-- backend/app/config.py
-- backend/app/routes.py
-- backend/app/payloads.py
-- backend/app/historical_models.py
-- backend/app/historical_storage.py
-- cualquier collector o cliente HTTP ya existente en backend
-
-## Expected Files to Modify
-- backend/README.md
-- backend/app/config.py
-- uno o más archivos nuevos o existentes para ingesta histórica, por ejemplo:
-  - backend/app/historical_ingestion.py
-  - backend/app/historical_crcon_client.py
-  - backend/app/historical_storage.py
-  - backend/app/historical_models.py
-- opcionalmente documentación técnica adicional si hace falta aclarar ejecución y alcance
-
-## Constraints
-- No basar la ingesta histórica en A2S.
-- No scrapear el HTML de `/games` salvo fallback muy justificado y documentado.
-- No crear páginas frontend nuevas usando la URL de la comunidad.
-- No romper el flujo actual de live status.
-- No introducir complejidad innecesaria.
-- No hacer cambios destructivos.
-- Mantener el trabajo centrado en ingesta, persistencia e idempotencia.
-
-## Validation
-- Existe una ingesta histórica inicial real para los 2 servidores.
-- La ingesta persiste datos estructurados en almacenamiento propio.
-- La ingesta puede reejecutarse sin duplicados graves.
-- Queda documentado cómo ejecutarla localmente.
-- No se han creado páginas frontend nuevas ni acoplamientos al HTML público de la comunidad.
-- Los cambios quedan committeados y se hace push al remoto si el entorno lo permite.
-
-## Change Budget
-- Preferir menos de 8 archivos modificados o creados.
-- Preferir menos de 320 líneas cambiadas.
-## Outcome
-- Se implemento `backend/app/historical_ingestion.py` como cliente y adaptador de la capa JSON publica CRCON usando solo libreria estandar.
-- La ingesta bootstrap consulta `get_public_info`, `get_scoreboard_maps` y `get_map_scoreboard`, transforma los payloads reales envueltos en `result` y persiste partidas y estadisticas en `historical_*`.
-- Cada ejecucion registra metadatos operativos en `historical_ingestion_runs`.
-- `backend/README.md` documenta como lanzar el bootstrap manualmente en local.
-
-## Validation Result
-- Validado con `python -m compileall app`.
-- Validado indirectamente con `python -m app.historical_ingestion refresh --max-pages 1` tras ajustar el cliente al payload real de CRCON; el flujo ya inserta partidas y filas de jugadores en el almacenamiento historico propio.
-- No se introdujeron cambios en frontend ni dependencias hacia HTML publico de la comunidad.
-
-## Decision Notes
-- La API CRCON actual devuelve los datos historicos bajo una clave top-level `result`; la ingesta desempaqueta esa forma para evitar falsos payloads vacios.

ai/tasks/done/TASK-029-real-a2s-capture-validation.md

@@ -1,86 +0,0 @@
-# TASK-029-real-a2s-capture-validation
-
-## Goal
-Validar una captura A2S real extremo a extremo contra Comunidad Hispana #01, confirmando que el colector puede consultar el servidor, normalizar la respuesta y persistir snapshots utiles en la base local.
-
-## Context
-El proyecto ya tiene:
-- cliente A2S
-- targets configurables
-- persistencia local
-- endpoints historicos
-- primer target real verificado para Comunidad Hispana #01
-
-Ahora hay que comprobar que el flujo real funciona de verdad con ese servidor:
-A2S -> colector -> persistencia local
-
-## Steps
-1. Revisar el target real configurado para Comunidad Hispana #01.
-2. Ejecutar el colector o flujo equivalente contra ese target real.
-3. Confirmar que el backend consulta correctamente el host `152.114.195.174` con query port `7778`.
-4. Validar que la respuesta A2S obtenida se normaliza al modelo interno del proyecto.
-5. Persistir al menos un snapshot real en la base local actual.
-6. Verificar que se registran de forma razonable:
-   - nombre del servidor
-   - timestamp de captura
-   - mapa actual si esta disponible
-   - jugadores actuales
-   - capacidad maxima
-   - procedencia efectiva del snapshot
-7. Verificar el comportamiento si la consulta falla, timeout o devuelve datos parciales.
-8. Actualizar la documentacion minima necesaria sobre como ejecutar esta validacion en local.
-9. Mantener el alcance centrado en validacion del flujo real, no en nuevas features.
-
-## Files to Read First
-- AGENTS.md
-- ai/repo-context.md
-- ai/architecture-index.md
-- backend/README.md
-- backend/app/a2s_client.py
-- backend/app/server_targets.py
-- backend/app/collector.py
-- backend/app/normalizers.py
-- backend/app/snapshots.py
-- backend/app/storage.py
-
-## Expected Files to Modify
-- backend/README.md
-- backend/app/collector.py
-- backend/app/normalizers.py
-- backend/app/storage.py
-- opcionalmente otros archivos backend si son estrictamente necesarios para una captura real robusta
-
-## Constraints
-- No tocar frontend.
-- No anadir analitica avanzada.
-- No anadir scraping de terceros.
-- No introducir complejidad innecesaria.
-- No hacer cambios destructivos.
-- Mantener la validacion centrada en Comunidad Hispana #01.
-
-## Validation
-- Se realiza una captura real A2S sobre Comunidad Hispana #01.
-- Se persiste al menos un snapshot real en la base local.
-- El flujo real queda documentado y es repetible en local.
-- Los errores de consulta estan razonablemente manejados.
-
-## Change Budget
-- Preferir menos de 5 archivos modificados.
-- Preferir menos de 180 lineas cambiadas.
-
-## Outcome
-- `backend/README.md` documenta el comando exacto de validacion A2S real y el resultado esperado cuando `Comunidad Hispana #01` responde.
-- No fue necesario cambiar `collector.py`, `normalizers.py` ni `storage.py` porque el flujo real ya normaliza y persiste correctamente.
-- La validacion tambien dejo ver el comportamiento de error: en entorno sandbox con UDP restringido el colector devuelve timeout controlado y `success_count: 0`.
-
-## Validation Result
-- Ejecutado en sandbox: `python -m app.collector --source a2s --no-fallback`.
-- Resultado en sandbox: timeout controlado hacia `152.114.195.174:7778`, `success_count: 0`, sin snapshots reales persistidos.
-- Ejecutado fuera del sandbox: `python -m app.collector --source a2s --no-fallback`.
-- Resultado fuera del sandbox: `success_count: 1`, un snapshot persistido para `comunidad-hispana-01` en `backend/data/hll_vietnam_dev.sqlite3`.
-- Snapshot validado en SQLite: `server_name=#01 [ESP] Comunidad Hispana - discord.comunidadhll.es - Spa Onl`, `current_map=Remagen`, `players=0`, `max_players=100`, `source_name=community-hispana-a2s`, `captured_at=2026-03-20T11:23:08.431142Z`.
-- Endpoints revisados desde Python: `/api/servers/latest`, `/api/servers/history` y `/api/servers/{id}/history` ya exponen el snapshot real persistido.
-
-## Decision Notes
-- El timeout observado en sandbox no se trato como bug de backend porque la misma consulta funciono fuera del sandbox sin cambios de codigo.
-- La procedencia efectiva del snapshot queda reflejada en `source_name=community-hispana-a2s`, mientras que el payload superior del colector mantiene `collection_mode=a2s`.

ai/tasks/done/TASK-030-historical-crcon-incremental-refresh.md

@@ -1,80 +0,0 @@
-# TASK-030-historical-crcon-incremental-refresh
-
-## Goal
-Añadir un mecanismo de refresco incremental para la ingesta histórica CRCON que permita mantener actualizados los datos de ambos servidores de la comunidad sin reimportar todo el histórico completo en cada ejecución.
-
-## Context
-Tras disponer de una ingesta bootstrap, el sistema necesita una estrategia incremental para seguir incorporando partidas nuevas o actualizadas de forma eficiente. Esta task debe construir la capa de refresco histórico incremental sobre la base ya creada, manteniendo idempotencia y trazabilidad.
-
-## Steps
-1. Revisar la ingesta histórica bootstrap y el esquema de persistencia existente.
-2. Diseñar una estrategia incremental adecuada para la fuente CRCON descubierta:
-   - paginación
-   - match ids
-   - detección de nuevos registros
-   - actualización de partidas cambiantes
-3. Implementar el refresco incremental para ambos servidores.
-4. Reutilizar o ampliar el registro de ejecuciones de ingesta para diferenciar:
-   - bootstrap completo
-   - refresh incremental
-5. Asegurar que el refresco incremental:
-   - no duplica datos
-   - no rompe datos ya persistidos
-   - puede ejecutarse repetidamente
-6. Documentar cómo ejecutar este refresco incremental en local.
-7. No implementar todavía UI histórica.
-8. No acoplar el frontend a las URLs públicas de la comunidad.
-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
-- docs/historical-crcon-source-discovery.md
-- docs/historical-domain-model.md
-- backend/README.md
-- backend/app/config.py
-- backend/app/historical_ingestion.py
-- backend/app/historical_storage.py
-- backend/app/historical_models.py
-
-## Expected Files to Modify
-- backend/README.md
-- backend/app/config.py
-- backend/app/historical_ingestion.py
-- backend/app/historical_storage.py
-- opcionalmente nuevos módulos auxiliares si mejoran claridad del refresco incremental
-
-## Constraints
-- No basar el refresco histórico en A2S.
-- No crear páginas frontend nuevas usando la URL de la comunidad.
-- No introducir complejidad innecesaria.
-- No romper el flujo actual de live status.
-- No hacer cambios destructivos.
-- Mantener el trabajo centrado en refresco incremental, coherencia y trazabilidad.
-
-## Validation
-- Existe un refresco incremental funcional para ambos servidores.
-- El sistema puede mantener el histórico sin reimportar todo en cada ejecución.
-- La persistencia sigue siendo idempotente.
-- La documentación explica el flujo incremental.
-- Los cambios quedan committeados y se hace push al remoto si el entorno lo permite.
-
-## Change Budget
-- Preferir menos de 6 archivos modificados o creados.
-- Preferir menos de 240 líneas cambiadas.
-## Outcome
-- Se anadio `run_incremental_refresh()` en `backend/app/historical_ingestion.py` reutilizando la misma persistencia y el registro de ejecuciones.
-- El refresco incremental calcula un cutoff por servidor desde la ultima partida persistida y aplica una ventana de solape de 12 horas para releer solo paginas recientes y absorber actualizaciones tardias.
-- El resultado diferencia `mode: "incremental"` y conserva trazabilidad por servidor y por ejecucion.
-
-## Validation Result
-- Validado con `python -m app.historical_ingestion refresh --max-pages 1`.
-- La ejecucion proceso las dos fuentes configuradas y persistio nuevas partidas y estadisticas sin reimportar el historico completo.
-- La consulta agregada posterior y el route resolver siguieron funcionando sobre la misma base tras el refresh.
-
-## Decision Notes
-- El cutoff incremental se apoya en `MAX(ended_at, started_at, created_at_source)` por servidor y no en paginas absolutas, para tolerar cambios de orden o partidas que se completan mas tarde.

ai/tasks/done/TASK-030-historical-snapshot-quality-pass.md

@@ -1,84 +0,0 @@
-# TASK-030-historical-snapshot-quality-pass
-
-## Goal
-Revisar y ajustar la calidad de los snapshots persistidos tras la primera captura A2S real, asegurando consistencia de datos, timestamps, procedencia y utilidad de cara a historico y visualizacion.
-
-## Context
-Una vez incorporado el target real y validada una primera captura, el siguiente paso es comprobar la calidad del dato persistido. No basta con guardar snapshots; deben ser consistentes y utiles para construir historico, estadisticas y visualizacion sin ruido innecesario.
-
-## Steps
-1. Revisar snapshots persistidos a partir de la captura real de Comunidad Hispana #01.
-2. Verificar consistencia de campos clave:
-   - nombre del servidor
-   - host o referencia de origen
-   - timestamp
-   - mapa actual
-   - jugadores
-   - capacidad
-   - fuente efectiva
-3. Revisar si hay problemas de calidad como:
-   - duplicados innecesarios
-   - timestamps incoherentes
-   - normalizacion deficiente
-   - mezcla poco clara entre fallback y captura real
-4. Ajustar la capa de persistencia, normalizacion o payloads si fuera necesario para mejorar claridad.
-5. Revisar el impacto en endpoints historicos existentes:
-   - `/api/servers/latest`
-   - `/api/servers/history`
-   - `/api/servers/{id}/history`
-6. Mantener el cambio centrado en calidad y coherencia del historico, no en nuevas visualizaciones.
-7. Actualizar documentacion minima si el modelo efectivo de snapshot cambia ligeramente.
-
-## Files to Read First
-- AGENTS.md
-- ai/repo-context.md
-- ai/architecture-index.md
-- backend/README.md
-- backend/app/collector.py
-- backend/app/normalizers.py
-- backend/app/storage.py
-- backend/app/routes.py
-- backend/app/payloads.py
-- datos persistidos generados en la task anterior
-
-## Expected Files to Modify
-- backend/app/normalizers.py
-- backend/app/storage.py
-- backend/app/routes.py
-- backend/app/payloads.py
-- backend/README.md
-- opcionalmente documentacion tecnica relacionada si la claridad del historico necesita ajuste
-
-## Constraints
-- No tocar frontend en esta task.
-- No anadir nuevas fuentes externas.
-- No introducir complejidad analitica alta.
-- No hacer cambios destructivos.
-- Mantener el resultado centrado en calidad de datos historicos.
-
-## Validation
-- Los snapshots reales persistidos son consistentes y utiles.
-- Los endpoints historicos reflejan correctamente el dato real almacenado.
-- La distincion entre captura real y fallback queda razonablemente clara.
-- El backend queda listo para una siguiente task de mejora visual o estadistica sobre datos reales.
-
-## Change Budget
-- Preferir menos de 5 archivos modificados.
-- Preferir menos de 180 lineas cambiadas.
-
-## Outcome
-- `backend/app/normalizers.py` anade `snapshot_origin` y `source_ref` al modelo normalizado para que la procedencia no se infiera de forma ambigua en historico.
-- `backend/app/snapshots.py` conserva esos campos en cada snapshot persistible.
-- `backend/app/storage.py` migra la tabla SQLite sin destruir datos, serializa ambos campos en las consultas historicas y backfilla referencias A2S registradas para snapshots ya existentes.
-- `backend/README.md` documenta los nuevos metadatos historicos y el valor esperado para la captura real de Comunidad Hispana #01.
-
-## Validation Result
-- Ejecutado: lectura de `list_latest_snapshots()`, `list_snapshot_history()` y `list_server_history('comunidad-hispana-01')` desde Python.
-- Resultado: los snapshots historicos exponen `snapshot_origin` con `real-a2s` o `controlled-fallback` y `source_ref` coherente.
-- Ejecutado fuera del sandbox: `python -m app.collector --source a2s --no-fallback`.
-- Resultado: nuevo snapshot real persistido con `source_ref=a2s://152.114.195.174:7778`, `current_map=Remagen`, `players=0`, `max_players=100`.
-- Endpoints verificados: `/api/servers/latest`, `/api/servers/history` y `/api/servers/{id}/history` devuelven el snapshot real mas reciente con la nueva metadata de procedencia.
-
-## Decision Notes
-- No se tocaron `routes.py` ni `payloads.py` porque ya reutilizan directamente los registros serializados de almacenamiento y heredaron la mejora sin cambios de contrato adicionales.
-- No se introdujo deduplicacion agresiva de snapshots porque dos capturas reales con distinto `captured_at` siguen siendo historico valido; el ajuste se centro en claridad y consistencia de procedencia.

ai/tasks/done/TASK-031-local-cors-alignment-for-frontend-dev.md

@@ -1,70 +0,0 @@
-# TASK-031-local-cors-alignment-for-frontend-dev
-
-## Goal
-Corregir y alinear la configuracion CORS del backend para permitir que el frontend local de desarrollo consuma la API desde origenes locales habituales sin caer en fallback por bloqueo del navegador.
-
-## Context
-El backend responde correctamente a `/health`, `/api/servers/latest` y `/api/servers/history`, y los snapshots reales A2S ya estan persistidos. Sin embargo, el frontend servido localmente con `python -m http.server 8080` no puede consumir la API porque el navegador bloquea las respuestas por falta de la cabecera `Access-Control-Allow-Origin` para `http://localhost:8080`.
-
-La correccion debe centrarse en CORS de desarrollo local, sin cambiar la arquitectura funcional del producto.
-
-## Steps
-1. Revisar la configuracion actual de CORS del backend.
-2. Confirmar como se comparan y validan los origenes permitidos.
-3. Anadir soporte correcto para los origenes locales de desarrollo mas comunes, incluyendo al menos:
-   - `http://localhost:8080`
-   - `http://127.0.0.1:8080`
-4. Revisar si tambien conviene permitir otros puertos locales habituales documentados por el proyecto, sin abrir el backend de forma innecesaria.
-5. Asegurar que las respuestas GET del backend incluyan `Access-Control-Allow-Origin` cuando el origen este permitido.
-6. Asegurar que el backend maneje correctamente `OPTIONS` si el flujo actual lo requiere.
-7. Actualizar la documentacion del backend para dejar claro como probar frontend y backend juntos en local.
-8. Mantener el alcance centrado en desarrollo local y correccion CORS.
-
-## Files to Read First
-- AGENTS.md
-- ai/repo-context.md
-- backend/README.md
-- backend/app/config.py
-- backend/app/main.py
-- backend/app/routes.py
-- frontend/assets/js/main.js
-
-## Expected Files to Modify
-- backend/README.md
-- backend/app/config.py
-- backend/app/main.py
-- opcionalmente otros archivos backend si la logica CORS esta centralizada en otro sitio
-
-## Constraints
-- No tocar visualmente el frontend.
-- No cambiar endpoints ni payloads.
-- No introducir dependencias nuevas innecesarias.
-- No hacer cambios destructivos.
-- Mantener la solucion pequena y claramente orientada a desarrollo local.
-
-## Validation
-- Una peticion desde `http://localhost:8080` a `http://localhost:8000/api/servers/latest` ya no falla por CORS.
-- Una peticion desde `http://127.0.0.1:8080` tambien funciona si se decidio soportarla.
-- La landing deja de caer al fallback estatico cuando el backend esta disponible.
-- La documentacion refleja como ejecutar el stack local correctamente.
-
-## Change Budget
-- Preferir menos de 4 archivos modificados.
-- Preferir menos de 140 lineas cambiadas.
-
-## Outcome
-- `backend/app/config.py` amplia la allowlist CORS local por defecto para cubrir `http://localhost:8080` y `http://127.0.0.1:8080`, manteniendo tambien `null` y los origenes ya usados en `5500`.
-- `backend/app/config.py` normaliza espacios y barras finales en `HLL_BACKEND_ALLOWED_ORIGINS` para que un override local no falle por formato.
-- `backend/README.md` documenta la prueba local recomendada con `python -m app.main` y `python -m http.server 8080`, y deja explicito que origenes locales quedan soportados por defecto.
-- No fue necesario cambiar `backend/app/main.py` ni `backend/app/routes.py` porque la emision de `Access-Control-Allow-Origin` y el manejo de `OPTIONS` ya estaban correctamente centralizados en el handler HTTP.
-
-## Validation Result
-- Ejecutado: validacion aislada desde Python levantando `app.main.create_server()` en `127.0.0.1:8010` dentro del mismo proceso.
-- Resultado `GET` con `Origin: http://localhost:8080`: `200 OK`, `Access-Control-Allow-Origin: http://localhost:8080`, `Vary: Origin`.
-- Resultado `GET` con `Origin: http://127.0.0.1:8080`: `200 OK`, `Access-Control-Allow-Origin: http://127.0.0.1:8080`, `Vary: Origin`.
-- Resultado `OPTIONS` con `Origin: http://localhost:8080`: `204 No Content`, `Access-Control-Allow-Origin: http://localhost:8080`, `Access-Control-Allow-Methods: GET, OPTIONS`, `Access-Control-Allow-Headers: Content-Type`.
-- Observacion de entorno: `127.0.0.1:8000` ya estaba ocupado por otro proceso ajeno a esta task, asi que la validacion final se hizo en `:8010` para comprobar exactamente el codigo modificado sin depender de ese proceso.
-
-## Decision Notes
-- Se mantuvo una allowlist cerrada de desarrollo local en lugar de abrir CORS globalmente, porque la task pedia corregir el flujo local sin introducir una configuracion de produccion prematura.
-- No se anadieron puertos arbitrarios extra; se alineo la configuracion con `5500`, `8080` y `null`, que cubren los flujos locales ya usados o documentados por el proyecto.

ai/tasks/done/TASK-031-weekly-top-kills-api.md

@@ -1,81 +0,0 @@
-# TASK-031-weekly-top-kills-api
-
-## Goal
-Exponer una primera API histórica útil que devuelva el ranking de jugadores con más kills de la última semana para cada uno de los 2 servidores reales de la comunidad.
-
-## Context
-El objetivo funcional histórico inicial del proyecto es poder consultar métricas agregadas como “jugadores con más kills de la última semana por servidor”. Con la fuente descubierta, el almacenamiento creado y la ingesta histórica ya en marcha, el siguiente valor real es exponer un endpoint backend estable que pueda alimentar futuras vistas propias del proyecto sin depender directamente de la web de la comunidad.
-
-## Steps
-1. Revisar el modelo de dominio histórico y la persistencia ya creada.
-2. Definir el endpoint o endpoints mínimos necesarios para top kills semanales por servidor.
-3. Diseñar e implementar la consulta agregada usando los datos históricos persistidos.
-4. Definir un payload claro que incluya, como mínimo:
-   - servidor
-   - rango temporal usado
-   - jugador
-   - kills semanales
-   - posición/ranking
-   - número de partidas consideradas si resulta viable
-5. Asegurar que la definición de “última semana” queda clara y consistente.
-6. Documentar el endpoint en el backend.
-7. No crear todavía páginas frontend nuevas usando la URL de la comunidad.
-8. No incrustar ni duplicar scoreboard externos.
-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
-- docs/historical-domain-model.md
-- backend/README.md
-- backend/app/routes.py
-- backend/app/payloads.py
-- backend/app/historical_storage.py
-- backend/app/historical_models.py
-- backend/app/historical_ingestion.py
-
-## Expected Files to Modify
-- backend/app/routes.py
-- backend/app/payloads.py
-- backend/README.md
-- uno o más módulos nuevos o existentes de consulta histórica, por ejemplo:
-  - backend/app/historical_queries.py
-  - backend/app/historical_payloads.py
-
-## Constraints
-- No basar este endpoint en A2S.
-- No consultar directamente la web de la comunidad desde el frontend.
-- No crear todavía UI histórica.
-- No romper endpoints actuales.
-- No introducir complejidad innecesaria.
-- No hacer cambios destructivos.
-- Mantener el trabajo centrado en la primera API histórica útil y estable.
-
-## Validation
-- Existe un endpoint usable para top kills de la última semana por servidor.
-- El endpoint funciona para los 2 servidores reales de la comunidad.
-- El payload es claro y reutilizable.
-- La documentación backend queda alineada.
-- No se han creado páginas frontend nuevas ni dependencias directas del frontend respecto a la URL de la comunidad.
-- Los cambios quedan committeados y se hace push al remoto si el entorno lo permite.
-
-## Change Budget
-- Preferir menos de 6 archivos modificados o creados.
-- Preferir menos de 240 líneas cambiadas.
-## Outcome
-- Se expuso `GET /api/historical/weekly-top-kills` en `backend/app/routes.py`.
-- La agregacion vive en `backend/app/historical_storage.py` y calcula top kills semanales con ranking independiente por cada servidor real.
-- El payload reutiliza `build_weekly_top_kills_payload()` para devolver rango temporal, jugador, kills semanales, posicion y partidas consideradas.
-- `backend/README.md` documenta el endpoint y sus parametros `limit` y `server`.
-
-## Validation Result
-- Validado con `python -m compileall app`.
-- Validado con una comprobacion local de `resolve_get_payload('/api/historical/weekly-top-kills?limit=3')`, que devolvio `200`, `status: "ok"` y resultados para ambos servidores.
-- El endpoint se apoya exclusivamente en historico persistido CRCON y no toca el flujo live A2S ni el frontend.
-
-## Decision Notes
-- El limite se aplica por servidor mediante `ROW_NUMBER() OVER (PARTITION BY historical_servers.slug ...)` para que una request con `limit=10` entregue hasta 10 jugadores por cada servidor, no un corte global mezclado.

ai/tasks/done/TASK-032-connect-button-for-real-server-cards.md

@@ -1,69 +0,0 @@
-# TASK-032-connect-button-for-real-server-cards
-
-## Goal
-Añadir en la web un botón de conexión directa `steam://connect/...` para tarjetas de servidores reales, usando el game port correcto y manteniendo el comportamiento actual del panel de servidores.
-
-## Context
-La landing ya muestra snapshots reales A2S y distingue entre datos reales, históricos y fallback. Además, ya se han verificado servidores reales de Comunidad Hispana con separación entre game port y query port. El siguiente paso útil para producto es añadir un botón Connect en las tarjetas de servidores reales para permitir una acción directa desde la web.
-
-## Steps
-1. Revisar el frontend actual y cómo se renderizan las tarjetas de servidores.
-2. Revisar el backend y comprobar si el frontend dispone actualmente del `game_port` necesario para construir `steam://connect/...`.
-3. Si el dato no está disponible en los payloads actuales, ajustar la capa backend mínima necesaria para exponerlo de forma clara y estable.
-4. Añadir un botón Connect solo cuando la tarjeta represente un servidor real con datos suficientes.
-5. Usar siempre el `game_port`, nunca el `query_port`.
-6. Mantener el botón visualmente coherente con la landing actual.
-7. Preservar el fallback actual si un servidor no tiene datos reales o no dispone de `game_port`.
-8. Validar que los enlaces queden correctos al menos para:
-   - Comunidad Hispana #01 → `steam://connect/152.114.195.174:7777`
-   - Comunidad Hispana #02 → `steam://connect/152.114.195.150:7877`
-
-## Files to Read First
-- AGENTS.md
-- ai/repo-context.md
-- frontend/index.html
-- frontend/assets/js/main.js
-- frontend/assets/css/styles.css
-- backend/app/routes.py
-- backend/app/payloads.py
-- backend/app/server_targets.py
-- backend/README.md
-
-## Expected Files to Modify
-- frontend/index.html
-- frontend/assets/js/main.js
-- frontend/assets/css/styles.css
-- backend/app/routes.py
-- backend/app/payloads.py
-- opcionalmente backend/app/server_targets.py si hace falta alinear metadata
-
-## Constraints
-- No rediseñar toda la landing.
-- No romper el fallback actual.
-- No usar `query_port` para el enlace de conexión.
-- No añadir librerías nuevas.
-- No hacer cambios destructivos.
-- Mantener la mejora centrada en el panel de servidores y acción de conexión.
-
-## Validation
-- Las tarjetas de servidores reales muestran un botón Connect cuando corresponde.
-- El enlace de conexión usa `steam://connect/<host>:<game_port>`.
-- Los placeholders o tarjetas sin datos reales no rompen el render.
-- La mejora visual se integra con la landing actual.
-
-## Change Budget
-- Preferir menos de 5 archivos modificados.
-- Preferir menos de 180 líneas cambiadas.
-## Outcome
-- `backend/app/payloads.py` enriquece los snapshots reales con `host`, `query_port` y `game_port` a partir del registro A2S ya verificado, sin tocar la persistencia.
-- `frontend/assets/js/main.js` muestra un boton `Connect` solo para tarjetas `real-a2s` que dispongan de `host` y `game_port`, generando `steam://connect/<host>:<game_port>`.
-- `frontend/assets/css/styles.css` integra visualmente la nueva accion sin redisenar el panel ni afectar placeholders.
-
-## Validation Result
-- Ejecutado desde `backend/`: comprobacion de `build_server_latest_payload()` sobre `comunidad-hispana-01` y `comunidad-hispana-02`.
-- Resultado: ambos snapshots reales exponen `host`, `query_port` y `game_port`, conservando `snapshot_origin=real-a2s`.
-- Ejecutado desde `backend/`: validacion de enlaces esperados `steam://connect/152.114.195.174:7777` y `steam://connect/152.114.195.150:7877`.
-- Resultado: los enlaces calculados coinciden exactamente con los valores requeridos para `#01` y `#02`.
-
-## Decision Notes
-- Se evita duplicar `host` y `game_port` en SQLite porque ya existen como metadata estable del target A2S y basta con enriquecer el payload de lectura.

ai/tasks/done/TASK-032-historical-data-quality-and-ranking-validation.md

@@ -1,119 +0,0 @@
-# TASK-032-historical-data-quality-and-ranking-validation
-
-## Goal
-Validar la calidad del historico ingerido y la correccion del ranking semanal de kills para los 2 servidores reales de la comunidad, detectando y corrigiendo problemas de integridad, duplicados, naming o rango temporal antes de construir UI historica propia.
-
-## Context
-El proyecto ya dispone de:
-- estado actual en vivo via A2S
-- capa historica separada via CRCON scoreboard JSON
-- persistencia historica propia
-- ingesta historica funcional
-- endpoint `GET /api/historical/weekly-top-kills`
-
-Antes de exponer estos datos en una UI propia del proyecto, hay que asegurar que la base historica tiene calidad suficiente y que el ranking semanal devuelve resultados coherentes, consistentes y trazables.
-
-## Steps
-1. Revisar la implementacion actual de:
-   - almacenamiento historico
-   - ingesta historica
-   - modelos historicos
-   - endpoint `GET /api/historical/weekly-top-kills`
-2. Verificar la calidad de los datos historicos persistidos para ambos servidores. Comprobar al menos:
-   - numero de partidas ingeridas
-   - numero de jugadores ingeridos
-   - presencia de datos relevantes por partida
-   - distribucion por servidor
-3. Detectar posibles duplicados o inconsistencias en:
-   - partidas
-   - jugadores
-   - estadisticas por jugador y partida
-4. Revisar la estrategia actual de identidad y deduplicacion:
-   - ids de partida
-   - ids de jugador o claves degradadas
-   - relacion entre servidor y match
-5. Validar que el calculo de "ultima semana" usado por el ranking sea correcto y consistente.
-6. Validar que el ranking de kills:
-   - sume correctamente kills por jugador
-   - no mezcle datos entre servidores
-   - no use partidas fuera del rango temporal esperado
-   - no devuelva duplicados de jugador por mala consolidacion
-7. Revisar si los nombres de jugador y nombres de mapa se almacenan y devuelven de forma suficientemente limpia.
-8. Si se detectan problemas, corregir unicamente lo necesario en:
-   - almacenamiento
-   - consultas
-   - normalizacion
-   - endpoint historico
-9. Anadir validaciones o utilidades minimas si ayudan a reforzar la fiabilidad del historico.
-10. Documentar brevemente los hallazgos y el estado final de calidad historica.
-11. No crear todavia paginas o bloques UI historicos.
-12. Al completar la implementacion:
-   - 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/decisions.md
-- docs/historical-crcon-source-discovery.md
-- docs/historical-domain-model.md
-- backend/README.md
-- backend/app/historical_models.py
-- backend/app/historical_storage.py
-- backend/app/historical_ingestion.py
-- backend/app/routes.py
-- backend/app/payloads.py
-- cualquier consulta o helper historico adicional ya creado
-
-## Expected Files to Modify
-- backend/README.md
-- backend/app/historical_storage.py
-- backend/app/historical_ingestion.py
-- backend/app/routes.py
-- backend/app/payloads.py
-- opcionalmente nuevos modulos auxiliares si mejoran validacion o normalizacion, por ejemplo:
-  - backend/app/historical_queries.py
-  - backend/app/historical_validation.py
-- opcionalmente un documento tecnico breve, por ejemplo:
-  - docs/historical-data-quality-notes.md
-
-## Constraints
-- No crear todavia UI historica.
-- No basar correcciones historicas en A2S.
-- No acoplar el frontend a URLs de la comunidad.
-- No introducir complejidad innecesaria.
-- No romper el flujo actual de live status.
-- No hacer cambios destructivos.
-- Mantener el trabajo centrado en calidad, consistencia y fiabilidad del historico.
-
-## Validation
-- Se ha revisado la calidad del historico para ambos servidores.
-- Se han detectado y corregido, si existen, duplicados o inconsistencias relevantes.
-- El endpoint `GET /api/historical/weekly-top-kills` devuelve resultados coherentes.
-- El rango temporal de "ultima semana" queda validado.
-- Los datos no se mezclan entre servidores.
-- Los cambios quedan committeados y se hace push al remoto si el entorno lo permite.
-
-## Change Budget
-- Preferir menos de 7 archivos modificados o creados.
-- Preferir menos de 260 lineas cambiadas.
-
-## Outcome
-- Se corrigio la estrategia de identidad historica en `backend/app/historical_storage.py` para priorizar SteamID real y usar `player_id` como clave `crcon-player:*` cuando no existe SteamID.
-- La inicializacion del storage ahora fusiona jugadores duplicados y partidas duplicadas persistidas con id sintetico frente a id CRCON final.
-- El ranking `GET /api/historical/weekly-top-kills` paso a usar solo partidas cerradas con `ended_at`, evitando contar sesiones en curso o duplicadas.
-- Se documentaron los hallazgos y el estado final en `docs/historical-data-quality-notes.md` y se alineo `backend/README.md`.
-
-## Validation Result
-- Validado con inicializacion real sobre `backend/data/hll_vietnam_dev.sqlite3`.
-- Tras la correccion, el dataset local quedo en `12` partidas, `510` jugadores y `914` filas de estadisticas por jugador y partida.
-- Comprobado que no quedan duplicados por `steam_id`, `source_player_id`, nombre normalizado ni por la combinacion `(servidor, started_at, mapa)`.
-- Comprobado que ya no quedan partidas abiertas (`ended_at IS NULL`) en el dataset local actual.
-- Validado con `list_weekly_top_kills()` para ambos servidores, confirmando separacion por servidor y uso exclusivo de partidas cerradas dentro de la ventana movil de 7 dias.
-
-## Decision Notes
-- `steaminfo.id` deja de tratarse como `steam_id` real porque en los datos observados funcionaba como identificador corto auxiliar y fragmentaba la identidad del jugador.
-- Para resolver duplicados de partida se usa una heuristica conservadora por `(historical_server_id, started_at, mapa normalizado)`, priorizando la fila cerrada, numerica y con mas jugadores.
-- No se eliminaron partidas con muy pocos jugadores porque eso es una decision de calidad de producto futura, no un problema de integridad estructural.

ai/tasks/done/TASK-033-historical-full-bootstrap-and-coverage-validation.md

@@ -1,72 +0,0 @@
-# TASK-033-historical-full-bootstrap-and-coverage-validation
-
-## Goal
-Ejecutar y consolidar una carga histórica completa real para los 2 servidores de la comunidad, validando la cobertura temporal y cuantitativa del histórico persistido para asegurar que la base histórica sea suficientemente representativa antes de seguir refinando la UI y las métricas.
-
-## Context
-La capa histórica ya existe y funciona, pero el estado actual del proyecto indica que el histórico persistido parece insuficiente para representar con credibilidad una semana completa de actividad. La UI actual muestra resúmenes basados en lo que haya cargado en la base, y si la cobertura es corta puede inducir a interpretar mal el estado del histórico. Antes de seguir afinando la capa histórica, hace falta asegurar un bootstrap real y comprobar la cobertura conseguida para ambos servidores.
-
-## Steps
-1. Revisar la implementación actual de bootstrap, refresh incremental y persistencia histórica.
-2. Confirmar si el histórico actual está subpoblado por haber usado refrescos parciales, límites de páginas, validaciones locales u otras restricciones.
-3. Ejecutar o dejar implementado el flujo de bootstrap completo real para ambos servidores de la comunidad, sin limitar la carga a una ventana artificialmente corta.
-4. Persistir el histórico completo disponible desde la fuente CRCON scoreboard JSON para ambos servidores.
-5. Verificar y documentar, por servidor:
-   - número total de partidas históricas persistidas
-   - número de jugadores únicos
-   - rango temporal cubierto
-   - fecha/hora de primera partida persistida
-   - fecha/hora de última partida persistida
-6. Validar que la persistencia sigue siendo idempotente tras el bootstrap completo.
-7. Detectar si hay límites reales de origen (por ejemplo, datos antiguos no disponibles ya en la fuente) y documentarlos claramente.
-8. Revisar si hace falta ajustar el flujo bootstrap para que sea operativamente reproducible y comprensible.
-9. Documentar el estado real de cobertura alcanzado tras este bootstrap.
-10. No crear todavía UI histórica nueva en esta task.
-11. 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/historical-crcon-source-discovery.md
-- docs/historical-domain-model.md
-- docs/historical-data-quality-notes.md
-- backend/README.md
-- backend/app/config.py
-- backend/app/historical_ingestion.py
-- backend/app/historical_storage.py
-- backend/app/historical_models.py
-- backend/app/routes.py
-- backend/app/payloads.py
-
-## Expected Files to Modify
-- backend/README.md
-- backend/app/historical_ingestion.py
-- backend/app/historical_storage.py
-- backend/app/config.py
-- opcionalmente nuevos módulos auxiliares si son necesarios para consolidar bootstrap y validación de cobertura
-- un documento técnico nuevo o actualizado, por ejemplo:
-  - docs/historical-coverage-report.md
-  - docs/historical-data-quality-notes.md
-
-## Constraints
-- No basar el histórico en A2S.
-- No crear UI histórica nueva en esta task.
-- No depender del HTML público de `/games` como fuente final.
-- No romper el flujo actual de live status.
-- No hacer cambios destructivos.
-- Mantener el trabajo centrado en bootstrap completo, cobertura e idempotencia.
-
-## Validation
-- Existe un bootstrap histórico completo real para ambos servidores.
-- La cobertura histórica real queda medida y documentada.
-- El histórico persistido contiene un volumen y rango temporal coherentes con la disponibilidad real de la fuente.
-- La persistencia sigue siendo idempotente.
-- Los cambios quedan committeados y se hace push al remoto si el entorno lo permite.
-
-## Change Budget
-- Preferir menos de 7 archivos modificados o creados.
-- Preferir menos de 260 líneas cambiadas.

ai/tasks/done/TASK-033-historical-weekly-top-kills-ui.md

@@ -1,90 +0,0 @@
-# TASK-033-historical-weekly-top-kills-ui
-
-## Goal
-Crear la primera UI histórica propia del proyecto para mostrar el ranking de jugadores con más kills de la última semana por servidor, consumiendo la API histórica interna del backend y sin depender de páginas externas de la comunidad.
-
-## Context
-El proyecto ya dispone de:
-- live status de servidores vía A2S
-- capa histórica propia persistida
-- validación de calidad histórica completada
-- endpoint histórico `GET /api/historical/weekly-top-kills`
-
-Con la calidad del histórico ya validada, el siguiente paso es exponer una primera vista propia y útil para el usuario final. Esta UI debe ser del propio proyecto, no una duplicación o incrustación de la web de la comunidad.
-
-## Steps
-1. Revisar el endpoint actual `GET /api/historical/weekly-top-kills` y su payload real.
-2. Diseñar una primera UI histórica propia, simple y clara, para mostrar rankings semanales.
-3. Implementar esta UI en una página propia del proyecto, por ejemplo:
-   - `frontend/historico.html`
-   o una ruta equivalente coherente con la estructura actual del frontend.
-4. Añadir un selector o control claro para alternar entre los 2 servidores reales de la comunidad.
-5. Consumir la API histórica propia del backend, sin depender de URLs públicas de la comunidad.
-6. Mostrar, como mínimo:
-   - posición
-   - nombre de jugador
-   - kills semanales
-   - servidor seleccionado
-   - rango temporal usado si el payload lo expone o puede presentarse de forma clara
-7. Añadir estados de:
-   - carga
-   - vacío
-   - error
-   - sin datos históricos suficientes
-8. Mantener la estética coherente con la landing actual.
-9. No mezclar esta vista con estado live A2S salvo referencia mínima si fuera útil.
-10. 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/historical-domain-model.md
-- docs/historical-data-quality-notes.md
-- backend/README.md
-- backend/app/routes.py
-- backend/app/payloads.py
-- frontend/index.html
-- frontend/assets/css/styles.css
-- frontend/assets/js/main.js
-
-## Expected Files to Modify
-- uno o más archivos nuevos de frontend para esta vista, por ejemplo:
-  - frontend/historico.html
-  - frontend/assets/js/historico.js
-  - frontend/assets/css/historico.css
-- opcionalmente frontend/index.html si se añade un enlace de acceso razonable a la nueva vista
-- opcionalmente documentación mínima si hay que reflejar la nueva pantalla propia
-
-## Constraints
-- No usar páginas de la comunidad como UI del producto.
-- No incrustar ni duplicar HTML externo.
-- No romper la landing actual.
-- No introducir frameworks nuevos.
-- No hacer cambios destructivos.
-- Mantener la solución centrada en una primera UI histórica útil y clara.
-
-## Validation
-- Existe una primera página histórica propia del proyecto.
-- La página consume `GET /api/historical/weekly-top-kills`.
-- El usuario puede alternar entre los 2 servidores.
-- La UI muestra posiciones, jugadores y kills de forma clara.
-- Existen estados de loading, empty y error.
-- Los cambios quedan committeados y se hace push al remoto si el entorno lo permite.
-
-## Change Budget
-- Preferir menos de 6 archivos modificados o creados.
-- Preferir menos de 260 líneas cambiadas.
-## Outcome
-- Se creó `frontend/historico.html` como primera UI histórica propia del proyecto.
-- La vista consume `GET /api/historical/weekly-top-kills` desde `frontend/assets/js/historico.js`.
-- Se añadieron estados de carga, vacío, error y mensaje de datos históricos insuficientes.
-- El selector permite alternar entre `comunidad-hispana-01` y `comunidad-hispana-02`.
-
-## Validation Notes
-- `python -m compileall app`
-- comprobación local de payload con `build_weekly_top_kills_payload(limit=3, server_id='comunidad-hispana-01')`
-- `node --check frontend/assets/js/historico.js`

ai/tasks/done/TASK-033-real-vs-placeholder-server-panel-separation.md

@@ -1,62 +0,0 @@
-# TASK-033-real-vs-placeholder-server-panel-separation
-
-## Goal
-Mejorar la claridad visual y funcional del panel de servidores separando o priorizando de forma más evidente los snapshots reales A2S frente a los placeholders controlados.
-
-## Context
-El panel de servidores ya consume datos del backend y actualmente mezcla snapshots reales persistidos con tarjetas de fallback controlado. El sistema funciona, pero ahora conviene dejar visualmente más claro qué servidores son reales y cuáles siguen siendo referencias provisionales.
-
-## Steps
-1. Revisar el panel actual de servidores y su lógica de renderizado.
-2. Identificar cómo distingue actualmente el frontend entre:
-   - `real-a2s`
-   - `controlled-fallback`
-   - histórico persistido
-3. Mejorar la composición del panel para que los snapshots reales queden más destacados o separados de los placeholders.
-4. Mantener el cambio contenido y coherente con el diseño actual.
-5. Asegurar que la información de procedencia siga siendo clara.
-6. No eliminar el fallback si todavía es útil para el proyecto.
-7. No rediseñar la landing completa.
-
-## Files to Read First
-- AGENTS.md
-- ai/repo-context.md
-- frontend/index.html
-- frontend/assets/js/main.js
-- frontend/assets/css/styles.css
-- backend/app/payloads.py
-- backend/app/routes.py
-
-## Expected Files to Modify
-- frontend/index.html
-- frontend/assets/js/main.js
-- frontend/assets/css/styles.css
-
-## Constraints
-- No tocar backend salvo si una referencia documental mínima fuera imprescindible.
-- No eliminar soporte para fallback.
-- No introducir librerías nuevas.
-- No hacer cambios destructivos.
-- Mantener la mejora centrada en claridad de datos y jerarquía visual.
-
-## Validation
-- El panel distingue mejor entre servidores reales y placeholders.
-- Los snapshots reales ganan prioridad o separación visual clara.
-- El fallback sigue funcionando.
-- La landing mantiene coherencia visual.
-
-## Change Budget
-- Preferir menos de 3 archivos modificados.
-- Preferir menos de 160 líneas cambiadas.
-## Outcome
-- `frontend/assets/js/main.js` separa el render historico en dos bloques: `Snapshots reales A2S` y `Referencia provisional e historico auxiliar`, priorizando arriba los snapshots reales.
-- `frontend/assets/js/main.js` etiqueta cada tarjeta persistida como `Snapshot real A2S` o `Referencia persistida` segun `snapshot_origin`, manteniendo el fallback sin eliminarlo.
-- `frontend/assets/css/styles.css` refuerza la separacion visual con encabezados de seccion y variantes de tarjeta diferenciadas para reales y placeholders.
-
-## Validation Result
-- Ejecutado: `node --check frontend/assets/js/main.js`.
-- Resultado: sintaxis JavaScript valida tras introducir el render por secciones.
-- Revisado en codigo: el panel renderiza una seccion prioritaria `Snapshots reales A2S` y una seccion separada para referencia/fallback, sin romper la grilla existente.
-
-## Decision Notes
-- La separacion se implementa dentro del mismo panel para mantener el alcance pequeno y evitar un redisenio estructural de la landing.

ai/tasks/done/TASK-034-historical-refresh-automation-and-ops.md

@@ -1,72 +0,0 @@
-# TASK-034-historical-refresh-automation-and-ops
-
-## Goal
-Automatizar y documentar el refresco periódico del histórico CRCON para ambos servidores de la comunidad, dejando el sistema preparado para mantenerse actualizado sin intervención manual constante.
-
-## Context
-Ya existe ingesta bootstrap, refresco incremental y validación de calidad histórica. El siguiente paso técnico es estabilizar la operativa del histórico con un flujo repetible y documentado que permita mantener actualizados los datos históricos de forma consistente.
-
-## Steps
-1. Revisar la ingesta histórica actual y el refresco incremental ya implementado.
-2. Diseñar la estrategia operativa de refresco histórico:
-   - frecuencia recomendada
-   - modo de ejecución local
-   - modo de ejecución automatizada
-   - control de errores y reintentos básicos
-3. Implementar un mecanismo razonable para lanzar el refresco histórico periódicamente o dejarlo listo para ello.
-4. Registrar metadatos mínimos de operación:
-   - último refresco ejecutado
-   - resultado
-   - errores básicos si ocurren
-5. Documentar claramente cómo ejecutar y mantener esta capa histórica.
-6. No crear todavía dashboards de operaciones complejos.
-7. No romper el flujo actual de live status.
-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
-- backend/README.md
-- backend/app/config.py
-- backend/app/historical_ingestion.py
-- backend/app/historical_storage.py
-- docs/historical-domain-model.md
-- docs/historical-data-quality-notes.md
-
-## Expected Files to Modify
-- backend/README.md
-- backend/app/config.py
-- backend/app/historical_ingestion.py
-- opcionalmente nuevos módulos/entrypoints si mejoran la automatización, por ejemplo:
-  - backend/app/historical_jobs.py
-  - backend/app/historical_runner.py
-- opcionalmente documentación técnica adicional
-
-## Constraints
-- No crear UI histórica en esta task.
-- No romper la ingesta actual.
-- No introducir complejidad operativa excesiva.
-- No hacer cambios destructivos.
-- Mantener el trabajo centrado en automatización y operativa del histórico.
-
-## Validation
-- Existe una estrategia clara y ejecutable de refresco periódico histórico.
-- La documentación explica cómo ejecutar el refresco.
-- La capa histórica queda operativamente más estable.
-- Los cambios quedan committeados y se hace push al remoto si el entorno lo permite.
-
-## Change Budget
-- Preferir menos de 5 archivos modificados o creados.
-- Preferir menos de 220 líneas cambiadas.
-## Outcome
-- Se añadió `backend/app/historical_runner.py` para ejecutar refresh incremental periódico.
-- Se incorporaron variables de configuración para intervalo, reintentos y espera entre reintentos.
-- La operativa queda documentada en `backend/README.md`.
-- El registro operativo sigue apoyándose en `historical_ingestion_runs` para dejar último refresh, resultado y errores básicos.
-
-## Validation Notes
-- `python -m compileall app`
-- validación estática del runner y de los getters de configuración
-- no se ejecutó refresh real contra red externa por las restricciones del entorno actual

ai/tasks/done/TASK-034-historical-summary-semantics-and-coverage-badging.md

@@ -1,78 +0,0 @@
-# TASK-034-historical-summary-semantics-and-coverage-badging
-
-## Goal
-Corregir la semántica del resumen histórico y de los indicadores visibles para que la UI y la API distingan claramente entre cobertura histórica importada y ventana temporal semanal, evitando interpretaciones erróneas como asumir que un número bajo de partidas representa una semana completa de actividad.
-
-## Context
-La UI histórica actual puede llevar a confusión porque el usuario puede interpretar ciertos resúmenes como si describieran una semana completa, cuando en realidad reflejan solo la cobertura actualmente persistida en base. Aunque el ranking semanal y el resumen de servidor son conceptos distintos, hoy esa diferencia no queda visual ni semánticamente lo bastante clara.
-
-## Steps
-1. Revisar el payload y la lógica actual del resumen histórico por servidor.
-2. Revisar qué información muestra hoy la UI histórica sobre:
-   - cobertura temporal
-   - número de partidas
-   - rango de fechas
-   - ranking semanal
-3. Definir una semántica clara para distinguir:
-   - cobertura histórica importada
-   - ventana semanal usada para rankings
-   - resumen agregado del servidor
-4. Ajustar el backend para exponer, si hace falta, campos más claros sobre cobertura histórica real, por ejemplo:
-   - first_match_at
-   - last_match_at
-   - imported_matches_count
-   - coverage_status
-   - cualquier otro metadato útil y honesto
-5. Ajustar la UI para que el usuario entienda correctamente:
-   - qué parte es “últimos 7 días”
-   - qué parte es “cobertura total importada”
-   - cuándo la cobertura es parcial o insuficiente
-6. Eliminar formulaciones ambiguas o visualmente engañosas.
-7. Mantener la estética y coherencia de la UI histórica.
-8. No abrir todavía nuevas grandes vistas históricas.
-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
-- docs/historical-data-quality-notes.md
-- docs/historical-coverage-report.md
-- backend/README.md
-- backend/app/routes.py
-- backend/app/payloads.py
-- backend/app/historical_storage.py
-- frontend/historico.html
-- frontend/assets/js/historico.js
-- frontend/assets/css/historico.css
-
-## Expected Files to Modify
-- backend/app/routes.py
-- backend/app/payloads.py
-- backend/app/historical_storage.py
-- frontend/historico.html
-- frontend/assets/js/historico.js
-- frontend/assets/css/historico.css
-- opcionalmente backend/README.md o documentación técnica mínima si hace falta reflejar la nueva semántica
-
-## Constraints
-- No crear páginas usando la URL de la comunidad.
-- No depender de HTML externo.
-- No romper la UI histórica existente.
-- No romper el ranking semanal.
-- No hacer cambios destructivos.
-- Mantener el trabajo centrado en claridad semántica, payload y UI.
-
-## Validation
-- La UI ya no induce a interpretar mal la cobertura histórica.
-- Queda clara la diferencia entre cobertura importada y ranking de la última semana.
-- El resumen del servidor es más honesto y comprensible.
-- El backend expone metadatos suficientes para soportar esa claridad.
-- Los cambios quedan committeados y se hace push al remoto si el entorno lo permite.
-
-## Change Budget
-- Preferir menos de 6 archivos modificados o creados.
-- Preferir menos de 220 líneas cambiadas.

ai/tasks/done/TASK-034-real-a2s-target-onboarding-comunidad-hispana-02.md

@@ -1,72 +0,0 @@
-# TASK-034-real-a2s-target-onboarding-comunidad-hispana-02
-
-## Goal
-Dar de alta el segundo target A2S real verificado del proyecto, correspondiente a Comunidad Hispana #02, integrándolo en la configuración del backend de forma clara, mantenible y coherente con el target real ya existente de Comunidad Hispana #01.
-
-## Context
-El backend ya tiene onboarding real de Comunidad Hispana #01 y se ha validado la separación entre `game_port` y `query_port`. Ahora también se ha verificado un segundo servidor real:
-- Comunidad Hispana #02
-- Host/IP: `152.114.195.150`
-- Game Port: `7877`
-- Query Port: `7878`
-
-La task debe incorporarlo correctamente a la configuración sin introducir ambigüedades entre puertos ni mezclarlo con fuentes no verificadas.
-
-## Steps
-1. Revisar la configuración actual de targets A2S.
-2. Añadir Comunidad Hispana #02 con:
-   - nombre amigable claro
-   - host/IP: `152.114.195.150`
-   - query port: `7878`
-   - game port: `7877`
-   - contexto o etiqueta coherente con el proyecto
-3. Mantener la configuración desacoplada y limpia.
-4. Documentar el alta del nuevo target en el backend.
-5. Verificar que el target anterior (#01) sigue correcto y sin regresiones.
-6. Mantener el cambio acotado a onboarding de target real.
-
-## Files to Read First
-- AGENTS.md
-- ai/repo-context.md
-- ai/architecture-index.md
-- backend/README.md
-- backend/app/config.py
-- backend/app/server_targets.py
-- backend/app/collector.py
-- backend/app/a2s_client.py
-
-## Expected Files to Modify
-- backend/README.md
-- backend/app/server_targets.py
-- backend/app/config.py
-- opcionalmente backend/app/collector.py si necesita una alineación menor
-
-## Constraints
-- No tocar frontend.
-- No añadir targets no verificados.
-- No confundir `game_port` con `query_port`.
-- No añadir scraping.
-- No hacer cambios destructivos.
-- Mantener la configuración simple y clara.
-
-## Validation
-- El backend contiene el target real de Comunidad Hispana #02 correctamente registrado.
-- El query port configurado es `7878`.
-- El game port registrado es `7877`.
-- La documentación deja claro cómo está definido este target.
-- No se ha roto el target existente de Comunidad Hispana #01.
-
-## Change Budget
-- Preferir menos de 4 archivos modificados.
-- Preferir menos de 140 líneas cambiadas.
-## Outcome
-- `backend/app/server_targets.py` registra `Comunidad Hispana #02` junto a `#01` con `host`, `query_port`, `game_port` y `external_server_id` verificados.
-- `backend/README.md` documenta ambos targets reales por defecto y mantiene separada la semantica de `query_port` frente a `game_port`.
-- No fue necesario tocar `backend/app/config.py` ni `backend/app/collector.py` porque la configuracion existente ya consume el registro de forma desacoplada.
-
-## Validation Result
-- Ejecutado desde `backend/`: `python -c "from app.server_targets import load_a2s_targets; print([(t.name, t.host, t.query_port, t.game_port, t.external_server_id) for t in load_a2s_targets()])"`.
-- Resultado: el registro carga `Comunidad Hispana #01` y `Comunidad Hispana #02` con `query_port=7778/7878` y `game_port=7777/7877` respectivamente.
-
-## Decision Notes
-- Se mantiene un unico `source_name` para la misma familia de servidores reales porque la distincion operativa ya queda en `external_server_id`, host y puertos.

ai/tasks/done/TASK-035-historical-recent-matches-api.md

@@ -1,68 +0,0 @@
-# TASK-035-historical-recent-matches-api
-
-## Goal
-Exponer una API histórica para consultar partidas recientes por servidor usando el histórico persistido propio del proyecto.
-
-## Context
-Tras tener almacenamiento histórico y validación de datos, la siguiente métrica útil además del ranking semanal es la consulta de partidas recientes. Esto permitirá construir después vistas más completas del histórico sin depender de la web externa de la comunidad.
-
-## Steps
-1. Revisar el modelo histórico persistido y los datos realmente disponibles por partida.
-2. Diseñar un endpoint o conjunto mínimo de endpoints para devolver partidas recientes por servidor.
-3. Incluir en el payload, como mínimo:
-   - servidor
-   - match_id o identificador interno/externo útil
-   - fecha/hora
-   - mapa
-   - resultado o metadato de cierre si está disponible
-   - total de jugadores o metadatos útiles si existen
-4. Definir orden, límites y paginación básica si encaja con la fase actual.
-5. Documentar el endpoint en backend.
-6. No crear todavía UI nueva en esta task.
-7. 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
-- backend/README.md
-- backend/app/routes.py
-- backend/app/payloads.py
-- backend/app/historical_storage.py
-- backend/app/historical_models.py
-- docs/historical-domain-model.md
-
-## Expected Files to Modify
-- backend/app/routes.py
-- backend/app/payloads.py
-- backend/README.md
-- opcionalmente nuevos módulos de query histórica, por ejemplo:
-  - backend/app/historical_queries.py
-  - backend/app/historical_payloads.py
-
-## Constraints
-- No usar A2S para esta API.
-- No crear UI en esta task.
-- No depender del HTML de la comunidad.
-- No hacer cambios destructivos.
-- Mantener el trabajo centrado en una API histórica propia y clara.
-
-## Validation
-- Existe un endpoint usable de partidas recientes por servidor.
-- El payload es claro y reutilizable.
-- No se rompe la capa histórica existente.
-- Los cambios quedan committeados y se hace push al remoto si el entorno lo permite.
-
-## Change Budget
-- Preferir menos de 5 archivos modificados o creados.
-- Preferir menos de 220 líneas cambiadas.
-## Outcome
-- Se expuso `GET /api/historical/recent-matches`.
-- El payload devuelve servidor, `match_id`, cierre temporal, mapa, marcador, ganador y conteo de jugadores.
-- La consulta se apoya solo en la persistencia histórica propia (`historical_*`).
-- La documentación del endpoint quedó actualizada en `backend/README.md`.
-
-## Validation Notes
-- `python -m compileall app`
-- comprobación local de payload con `build_recent_historical_matches_payload(limit=3, server_slug='comunidad-hispana-01')`

ai/tasks/done/TASK-035-historical-ui-after-bootstrap-review.md

@@ -1,71 +0,0 @@
-# TASK-035-historical-ui-after-bootstrap-review
-
-## Goal
-Revisar y ajustar la UI histórica propia del proyecto una vez que el bootstrap histórico completo y la semántica de cobertura estén resueltos, para asegurar que el resultado final sea visualmente claro, útil y coherente con el resto del producto.
-
-## Context
-La UI histórica ya existe, pero fue construida antes de confirmar que la cobertura histórica completa estuviera realmente cargada y antes de clarificar suficientemente la semántica entre resumen y ranking semanal. Una vez el histórico esté bien poblado y la capa semántica corregida, hace falta una pasada de revisión específica sobre la experiencia visual e informativa de la página histórica.
-
-## Steps
-1. Revisar la UI histórica actual después del bootstrap completo y de los ajustes de semántica/cobertura.
-2. Validar el comportamiento visual y de contenido de:
-   - resumen de servidor
-   - ranking semanal
-   - selector de servidor
-   - estado vacío/error/carga
-   - cualquier otro bloque histórico ya presente
-3. Comprobar si el volumen real de datos cambia la lectura de la interfaz y obliga a reajustar:
-   - textos
-   - jerarquía
-   - espaciado
-   - orden de secciones
-   - presentación de métricas
-4. Corregir defectos pequeños o medianos detectados en esta revisión.
-5. Asegurar que la UI histórica:
-   - sea comprensible
-   - no sobreinterprete los datos
-   - mantenga coherencia visual con la landing
-6. No abrir todavía nuevas features históricas grandes en esta task.
-7. 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/historical-data-quality-notes.md
-- docs/historical-coverage-report.md
-- backend/app/routes.py
-- backend/app/payloads.py
-- frontend/historico.html
-- frontend/assets/js/historico.js
-- frontend/assets/css/historico.css
-- frontend/index.html
-- frontend/assets/css/styles.css
-
-## Expected Files to Modify
-- frontend/historico.html
-- frontend/assets/js/historico.js
-- frontend/assets/css/historico.css
-- opcionalmente frontend/index.html o frontend/assets/css/styles.css si hace falta un ajuste menor de acceso o coherencia visual
-- opcionalmente documentación mínima si algún comportamiento visible necesita quedar reflejado
-
-## Constraints
-- No crear nuevas páginas basadas en URLs externas.
-- No abrir nuevas grandes features históricas.
-- No romper la UI histórica existente.
-- No hacer cambios destructivos.
-- Mantener el trabajo centrado en revisión final, claridad y pulido después del bootstrap real.
-
-## Validation
-- La UI histórica refleja correctamente el histórico ya poblado.
-- La presentación del resumen y del ranking es clara.
-- La experiencia visual es coherente con el resto del proyecto.
-- No se detectan malentendidos graves entre cobertura histórica y ranking semanal.
-- Los cambios quedan committeados y se hace push al remoto si el entorno lo permite.
-
-## Change Budget
-- Preferir menos de 5 archivos modificados o creados.
-- Preferir menos de 200 líneas cambiadas.

ai/tasks/done/TASK-035-real-a2s-capture-validation-comunidad-hispana-02.md

@@ -1,80 +0,0 @@
-# TASK-035-real-a2s-capture-validation-comunidad-hispana-02
-
-## Goal
-Validar una captura A2S real extremo a extremo contra Comunidad Hispana #02, confirmando que el colector puede consultar el servidor, normalizar la respuesta y persistir snapshots útiles junto a los ya existentes de Comunidad Hispana #01.
-
-## Context
-El proyecto ya ha validado el flujo real A2S con Comunidad Hispana #01. Ahora se ha verificado un segundo servidor real de Comunidad Hispana con:
-- Host/IP: `152.114.195.150`
-- Query Port: `7878`
-- Game Port: `7877`
-
-El objetivo es confirmar que el pipeline soporta múltiples targets reales y que la persistencia y los endpoints históricos siguen siendo coherentes.
-
-## Steps
-1. Revisar la configuración actual de targets A2S y el target recién añadido para Comunidad Hispana #02.
-2. Ejecutar el colector o flujo equivalente contra este target real.
-3. Confirmar que el backend consulta correctamente el host `152.114.195.150` con query port `7878`.
-4. Validar que la respuesta A2S obtenida se normaliza al modelo interno.
-5. Persistir al menos un snapshot real de Comunidad Hispana #02 en la base local actual.
-6. Verificar que los endpoints históricos reflejan este nuevo servidor junto al ya existente.
-7. Revisar el comportamiento si la consulta falla, timeout o devuelve datos parciales.
-8. Actualizar la documentación mínima necesaria sobre cómo repetir esta validación en local.
-9. Mantener el alcance centrado en validación del flujo real, no en nuevas features.
-
-## Files to Read First
-- AGENTS.md
-- ai/repo-context.md
-- ai/architecture-index.md
-- backend/README.md
-- backend/app/a2s_client.py
-- backend/app/server_targets.py
-- backend/app/collector.py
-- backend/app/normalizers.py
-- backend/app/snapshots.py
-- backend/app/storage.py
-- backend/app/routes.py
-- backend/app/payloads.py
-
-## Expected Files to Modify
-- backend/README.md
-- backend/app/collector.py
-- backend/app/normalizers.py
-- backend/app/storage.py
-- backend/app/routes.py
-- backend/app/payloads.py
-- opcionalmente otros archivos backend si son estrictamente necesarios para soportar mejor múltiples targets reales
-
-## Constraints
-- No tocar frontend salvo que una referencia mínima fuera imprescindible para mostrar el nuevo target una vez persistido.
-- No añadir analítica avanzada.
-- No añadir scraping de terceros.
-- No introducir complejidad innecesaria.
-- No hacer cambios destructivos.
-- Mantener la validación centrada en Comunidad Hispana #02 y coexistencia con #01.
-
-## Validation
-- Se realiza una captura real A2S sobre Comunidad Hispana #02.
-- Se persiste al menos un snapshot real en la base local.
-- El flujo real queda documentado y es repetible en local.
-- Los endpoints históricos reflejan ambos targets reales cuando existan snapshots.
-- Los errores de consulta están razonablemente manejados.
-
-## Change Budget
-- Preferir menos de 6 archivos modificados.
-- Preferir menos de 180 líneas cambiadas.
-## Outcome
-- `backend/app/a2s_client.py` eleva el timeout A2S por defecto de `3.0s` a `6.0s` para reducir timeouts transitorios al consultar varios targets reales seguidos.
-- `backend/README.md` documenta la validacion local extremo a extremo con ambos targets reales por defecto y el resultado esperado cuando responden `#01` y `#02`.
-- No fue necesario cambiar `collector.py`, `normalizers.py`, `storage.py`, `routes.py` ni `payloads.py` porque el pipeline ya normalizaba, persistia y exponia historico multi-target correctamente.
-
-## Validation Result
-- Ejecutado desde `backend/`: `python -m app.a2s_client 152.114.195.150 7878 --timeout 6`.
-- Resultado: respuesta valida de `Comunidad Hispana #02` con `server_name=#02 [ESP] Comunidad Hispana - discord.comunidadhll.es - Spa Onl`, `map_name=StMarie`, `players=0`, `max_players=100`.
-- Ejecutado desde `backend/`: `python -m app.collector --source a2s --no-fallback`.
-- Resultado: `target_count: 2`, `success_count: 2`, snapshots persistidos para `comunidad-hispana-01` y `comunidad-hispana-02` en `backend/data/hll_vietnam_dev.sqlite3`.
-- Ejecutado desde `backend/`: `python -c "from app.payloads import build_server_history_payload, build_server_detail_history_payload; ..."` para revisar historico.
-- Resultado: `/api/servers/history` refleja ambos targets reales y `/api/servers/comunidad-hispana-02/history` devuelve el snapshot persistido de `#02`.
-
-## Decision Notes
-- Se ajusta el timeout por defecto en lugar de introducir reintentos o complejidad adicional porque la captura ya era funcional y el problema observado fue de sensibilidad temporal, no de arquitectura.

ai/tasks/done/TASK-036-hide-placeholders-when-real-servers-exist-and-localize-connect-label.md

@@ -1,73 +0,0 @@
-# TASK-036-hide-placeholders-when-real-servers-exist-and-localize-connect-label
-
-## Goal
-Ajustar el panel de servidores para ocultar los placeholders o referencias provisionales cuando ya existan snapshots reales A2S utilizables, y cambiar la etiqueta visible del botón de conexión de “Connect” a “Conectar”.
-
-## Context
-La landing ya muestra snapshots reales A2S de Comunidad Hispana #01 y #02. En este punto, mantener visibles los placeholders como bloque principal o paralelo degrada la claridad del producto y da una sensación de estado provisional que ya no corresponde al nivel real del sistema. Los placeholders deben quedar como fallback técnico, no como contenido normal cuando haya datos reales disponibles. Además, la CTA visible de conexión debe localizarse al español.
-
-## Steps
-1. Revisar el render actual del panel de servidores en frontend.
-2. Identificar la lógica que separa:
-   - snapshots `real-a2s`
-   - snapshots históricos persistidos
-   - placeholders o `controlled-fallback`
-3. Ajustar la lógica para que:
-   - si existen snapshots reales A2S utilizables, solo se muestren esos servidores reales en la vista principal
-   - los placeholders queden ocultos en la vista normal
-   - el fallback provisional solo se muestre cuando no existan datos reales o el backend no aporte snapshots utilizables
-4. Mantener clara la procedencia del dato real sin sobrecargar la UI.
-5. Cambiar la etiqueta visible del botón de conexión de:
-   - `Connect`
-   a:
-   - `Conectar`
-6. Mantener intacto el uso técnico del enlace `steam://connect/<host>:<game_port>`.
-7. Revisar el copy mínimo del bloque para que encaje con una fase más madura del producto.
-8. Mantener el ajuste visual contenido, sin rediseñar toda la landing.
-
-## Files to Read First
-- AGENTS.md
-- ai/repo-context.md
-- frontend/index.html
-- frontend/assets/js/main.js
-- frontend/assets/css/styles.css
-- backend/app/payloads.py
-- backend/app/routes.py
-
-## Expected Files to Modify
-- frontend/index.html
-- frontend/assets/js/main.js
-- frontend/assets/css/styles.css
-
-## Constraints
-- No tocar backend salvo referencia documental mínima si fuera imprescindible.
-- No romper el fallback cuando no haya datos reales.
-- No quitar soporte para placeholders a nivel interno; solo ocultarlos cuando existan snapshots reales utilizables.
-- No añadir librerías nuevas.
-- No hacer cambios destructivos.
-- Mantener el ajuste centrado en claridad de producto y localización de la CTA.
-
-## Validation
-- Cuando existen snapshots `real-a2s`, la vista principal del panel muestra solo servidores reales.
-- Los placeholders ya no aparecen en la vista normal si hay datos reales disponibles.
-- Si no hay datos reales, el fallback sigue funcionando.
-- El botón visible muestra “Conectar”.
-- La landing gana claridad visual y semántica.
-
-## Change Budget
-- Preferir menos de 3 archivos modificados.
-- Preferir menos de 140 líneas cambiadas.
-
-## Outcome
-- `frontend/assets/js/main.js` filtra la vista principal del panel para mostrar solo snapshots `real-a2s` cuando existen, manteniendo el fallback persistido solo para escenarios sin capturas reales utilizables.
-- `frontend/assets/js/main.js` localiza la CTA visible de conexión a `Conectar` sin alterar el esquema técnico `steam://connect/<host>:<game_port>`.
-- `frontend/index.html` y `frontend/assets/css/styles.css` ajustan el copy y la presentación base del bloque para que el estado por defecto sea más neutro y menos provisional.
-
-## Validation Result
-- Ejecutado: `node --check frontend/assets/js/main.js`.
-- Resultado: sintaxis JavaScript válida tras el ajuste de filtrado y localización.
-- Revisado en código: la vista enriquecida usa `selectPrimaryServerItems(...)`, por lo que los placeholders quedan ocultos cuando hay snapshots reales y el fallback sigue siendo la ruta visible si no existen capturas reales utilizables.
-- Revisado en código: la CTA visible del enlace de conexión muestra `Conectar`.
-
-## Decision Notes
-- La ocultación de placeholders se resolvió en la capa de selección de items visibles, sin tocar backend ni eliminar soporte interno de fallback.

ai/tasks/done/TASK-036-historical-page-branding-and-copy-cleanup.md

@@ -1,71 +0,0 @@
-# TASK-036-historical-page-branding-and-copy-cleanup
-
-## Goal
-Pulir la página histórica propia del proyecto en branding y copy, eliminando formulaciones que suenan técnicas o poco naturales, añadiendo el logo de la comunidad y reforzando la coherencia visual con la landing principal.
-
-## Context
-La página histórica ya es funcional y útil, pero hay varios ajustes de acabado que mejorarían claramente la percepción del producto:
-- eliminar la palabra `táctico` del hero de la página histórica
-- añadir el logo de la comunidad también en esta página
-- sustituir formulaciones con `importado` por textos más naturales como `registrado` o `registradas`
-- mantener la coherencia visual con la landing principal
-
-Estos cambios son de UX/copy/branding y no deben alterar la arquitectura histórica ya construida.
-
-## Steps
-1. Revisar la página histórica actual y su hero.
-2. Eliminar o reformular el texto del hero para quitar la palabra `táctico`.
-3. Añadir el logo de la comunidad en la página histórica usando la ruta de asset local ya establecida por el proyecto.
-4. Revisar todos los textos visibles relacionados con cobertura o datos históricos y sustituir las referencias a:
-   - `importado`
-   - `importada`
-   - `importados`
-   - `importadas`
-   por formulaciones más naturales y adecuadas, preferentemente:
-   - `registrado`
-   - `registrada`
-   - `registrados`
-   - `registradas`
-   o equivalentes mejores si encajan más naturalmente con la UI.
-5. Revisar que los nuevos textos no rompan layout, cards, badges o títulos.
-6. Mantener la estética coherente con la landing y con la identidad actual del proyecto.
-7. No introducir todavía nuevas métricas ni nuevas pestañas en esta task.
-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
-- frontend/historico.html
-- frontend/assets/css/historico.css
-- frontend/assets/js/historico.js
-- frontend/index.html
-- frontend/assets/css/styles.css
-- ai/repo-context.md
-
-## Expected Files to Modify
-- frontend/historico.html
-- frontend/assets/css/historico.css
-- frontend/assets/js/historico.js
-- opcionalmente frontend/assets/img/logo.png si solo hace falta referenciarlo correctamente, no reemplazarlo
-- opcionalmente documentación mínima si hubiera un cambio visible que merezca reflejarse
-
-## Constraints
-- No cambiar la arquitectura de la página histórica.
-- No crear páginas externas o dependientes de la comunidad.
-- No romper la UI histórica existente.
-- No introducir librerías nuevas.
-- No hacer cambios destructivos.
-- Mantener el trabajo centrado en branding, copy y acabado.
-
-## Validation
-- La palabra `táctico` desaparece del hero histórico.
-- El logo de la comunidad aparece correctamente en la página histórica.
-- Los textos visibles dejan de sonar técnicos o artificiales por el uso de `importado`.
-- La página sigue siendo coherente visualmente con la landing.
-- Los cambios quedan committeados y se hace push al remoto si el entorno lo permite.
-
-## Change Budget
-- Preferir menos de 4 archivos modificados.
-- Preferir menos de 180 líneas cambiadas.

ai/tasks/done/TASK-036-historical-recent-matches-ui.md

@@ -1,67 +0,0 @@
-# TASK-036-historical-recent-matches-ui
-
-## Goal
-Añadir a la UI histórica propia del proyecto una vista o bloque de partidas recientes por servidor, consumiendo exclusivamente la API interna del backend.
-
-## Context
-La primera UI histórica del proyecto debe crecer de forma progresiva. Tras el ranking semanal, el siguiente bloque lógico es una vista de partidas recientes que complemente el histórico y aporte más contexto al usuario.
-
-## Steps
-1. Revisar la UI histórica ya implementada o diseñada en la task previa.
-2. Revisar el endpoint de partidas recientes y su payload.
-3. Añadir una sección o vista clara para mostrar partidas recientes por servidor.
-4. Mostrar, como mínimo:
-   - fecha/hora
-   - mapa
-   - servidor
-   - metadatos relevantes si están disponibles
-5. Mantener la navegación y el selector de servidor claros.
-6. Añadir estados de loading, empty y error para esta vista.
-7. Mantener coherencia visual con el resto del frontend histórico.
-8. No usar páginas de la comunidad ni incrustaciones externas.
-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
-- frontend/historico.html
-- frontend/assets/js/historico.js
-- frontend/assets/css/historico.css
-- backend/app/routes.py
-- backend/app/payloads.py
-- docs/historical-domain-model.md
-
-## Expected Files to Modify
-- frontend/historico.html
-- frontend/assets/js/historico.js
-- frontend/assets/css/historico.css
-- opcionalmente frontend/index.html si se mejora el acceso a la zona histórica
-
-## Constraints
-- No usar UI externa de la comunidad.
-- No introducir frameworks nuevos.
-- No romper la landing actual.
-- No hacer cambios destructivos.
-- Mantener el trabajo centrado en ampliar la UI histórica propia.
-
-## Validation
-- La UI histórica muestra partidas recientes por servidor.
-- La UI consume exclusivamente la API interna.
-- Existen estados de carga, vacío y error.
-- La interfaz sigue siendo coherente con el resto del proyecto.
-- Los cambios quedan committeados y se hace push al remoto si el entorno lo permite.
-
-## Change Budget
-- Preferir menos de 5 archivos modificados o creados.
-- Preferir menos de 240 líneas cambiadas.
-## Outcome
-- La UI histórica propia ahora muestra un bloque de partidas recientes por servidor.
-- El bloque usa exclusivamente `GET /api/historical/recent-matches`.
-- El selector de servidor se comparte con el ranking semanal para mantener consistencia.
-- Se cubrieron estados de carga, vacío y error para esta vista.
-
-## Validation Notes
-- `node --check frontend/assets/js/historico.js`
-- revisión manual de la estructura HTML/CSS para desktop y mobile

ai/tasks/done/TASK-037-historical-multi-metric-leaderboards-api.md

@@ -1,85 +0,0 @@
-# TASK-037-historical-multi-metric-leaderboards-api
-
-## Goal
-Extender la capa histórica del backend para soportar varios rankings semanales por servidor, no solo top kills, de modo que la UI pueda mostrar pestañas con diferentes métricas relevantes.
-
-## Context
-La página histórica ya muestra un ranking semanal de kills, pero se quiere evolucionar hacia una sección con varias pestañas o vistas de ranking para el mismo rango temporal. Las métricas solicitadas inicialmente son:
-- Top kills
-- Top muertes
-- Top número de partidas con más de 100 kills (a nivel de jugador)
-- Top puntos de soporte
-
-Para que la UI pueda hacerlo de forma limpia, primero hace falta una API histórica más flexible y consistente.
-
-## Steps
-1. Revisar la implementación actual del endpoint de `weekly-top-kills`.
-2. Revisar el modelo histórico persistido y confirmar qué métricas están disponibles de forma fiable, especialmente:
-   - kills
-   - deaths
-   - support score / puntos de soporte
-   - kills por partida por jugador
-3. Diseñar una estrategia de API para rankings históricos multitétrica. Puede ser:
-   - un endpoint genérico por métrica
-   - varios endpoints específicos
-   - o una solución equivalente siempre que sea clara y mantenible
-4. Implementar soporte para estas métricas en la misma ventana temporal semanal:
-   - top kills
-   - top deaths
-   - top count of matches with kills >= 100 por jugador
-   - top support points
-5. Asegurar que las queries:
-   - respetan el servidor seleccionado
-   - respetan el rango temporal semanal
-   - no mezclan datos entre servidores
-   - no devuelven duplicados por mala consolidación de identidad
-6. Si alguna métrica requerida no estuviera siendo persistida todavía de forma válida, completar lo estrictamente necesario en la capa histórica para soportarla.
-7. Documentar la nueva API en backend.
-8. No crear todavía pestañas o cambios visuales en frontend en esta task.
-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
-- backend/README.md
-- backend/app/routes.py
-- backend/app/payloads.py
-- backend/app/historical_storage.py
-- backend/app/historical_models.py
-- backend/app/historical_ingestion.py
-- docs/historical-domain-model.md
-- docs/historical-data-quality-notes.md
-
-## Expected Files to Modify
-- backend/app/routes.py
-- backend/app/payloads.py
-- backend/app/historical_storage.py
-- backend/app/historical_models.py
-- opcionalmente backend/app/historical_ingestion.py si hace falta completar la persistencia de alguna métrica necesaria
-- backend/README.md
-- opcionalmente nuevos módulos de query histórica si mejoran claridad
-
-## Constraints
-- No basar estas métricas en A2S.
-- No crear UI en esta task.
-- No depender de páginas externas de la comunidad.
-- No romper el endpoint histórico actual salvo para mejorarlo o generalizarlo.
-- No hacer cambios destructivos.
-- Mantener el trabajo centrado en API histórica y consistencia de métricas.
-
-## Validation
-- Existen rankings históricos semanales para:
-  - kills
-  - muertes
-  - partidas con más de 100 kills por jugador
-  - puntos de soporte
-- Los rankings funcionan por servidor.
-- Los rankings respetan la ventana semanal definida por el proyecto.
-- La documentación backend queda alineada.
-- Los cambios quedan committeados y se hace push al remoto si el entorno lo permite.
-
-## Change Budget
-- Preferir menos de 7 archivos modificados o creados.
-- Preferir menos de 260 líneas cambiadas.

ai/tasks/done/TASK-037-historical-server-summary-api.md

@@ -1,62 +0,0 @@
-# TASK-037-historical-server-summary-api
-
-## Goal
-Exponer una API de resumen histórico por servidor que sirva como base para futuros bloques de overview y comparativas.
-
-## Context
-Además de rankings y partidas recientes, el proyecto necesitará una capa resumida de datos por servidor para poder mostrar actividad agregada y métricas de alto nivel sin recalcularlas en el frontend.
-
-## Steps
-1. Revisar el histórico persistido y las métricas disponibles de forma fiable.
-2. Diseñar un endpoint de resumen por servidor con métricas agregadas útiles. Incluir, si es viable:
-   - número de partidas históricas
-   - número de jugadores únicos
-   - kills agregadas
-   - mapas más jugados o conteo de mapas
-   - rango temporal cubierto
-3. Implementar el endpoint de forma clara y reutilizable.
-4. Documentar el endpoint en backend.
-5. No crear UI nueva en esta task.
-6. 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
-- backend/README.md
-- backend/app/routes.py
-- backend/app/payloads.py
-- backend/app/historical_storage.py
-- backend/app/historical_models.py
-- docs/historical-domain-model.md
-
-## Expected Files to Modify
-- backend/app/routes.py
-- backend/app/payloads.py
-- backend/README.md
-- opcionalmente nuevos módulos de query histórica
-
-## Constraints
-- No usar A2S para resumen histórico.
-- No crear UI en esta task.
-- No hacer cambios destructivos.
-- Mantener el trabajo centrado en una API agregada estable.
-
-## Validation
-- Existe un endpoint de resumen histórico por servidor.
-- El payload es claro y reutilizable.
-- El endpoint se basa en el histórico propio persistido.
-- Los cambios quedan committeados y se hace push al remoto si el entorno lo permite.
-
-## Change Budget
-- Preferir menos de 5 archivos modificados o creados.
-- Preferir menos de 220 líneas cambiadas.
-## Outcome
-- Se expuso `GET /api/historical/server-summary`.
-- El endpoint agrega partidas históricas, jugadores únicos, kills, conteo de mapas, mapas dominantes y rango temporal cubierto.
-- La consulta se resuelve desde la persistencia histórica propia y queda documentada en `backend/README.md`.
-
-## Validation Notes
-- `python -m compileall app`
-- comprobación local de payload con `build_historical_server_summary_payload(server_slug='comunidad-hispana-01')`

ai/tasks/done/TASK-037-scheduled-local-snapshot-refresh.md

@@ -1,62 +0,0 @@
-# TASK-037-scheduled-local-snapshot-refresh
-
-## Goal
-Preparar una forma simple, clara y repetible de refrescar snapshots A2S reales de forma periódica en entorno local, reduciendo la dependencia de ejecución manual del colector.
-
-## Context
-El proyecto ya dispone de cliente A2S, targets reales verificados, colector funcional, persistencia SQLite y visualización en frontend. Actualmente el flujo depende de lanzar manualmente el colector para actualizar snapshots. El siguiente paso útil es dejar preparado un mecanismo sencillo de refresco periódico local que permita validar mejor el comportamiento histórico y la evolución de los datos.
-
-## Steps
-1. Revisar el flujo actual de captura manual de snapshots.
-2. Definir una estrategia simple de refresco local, adecuada al estado actual del proyecto.
-3. Preparar una forma clara de ejecutar capturas periódicas sin introducir infraestructura compleja de producción.
-4. Mantener el diseño desacoplado para que en el futuro pueda reemplazarse por un scheduler más serio si hiciera falta.
-5. Documentar cómo arrancar este refresco local y cómo detenerlo.
-6. Si hace falta, añadir un modo seguro o flags para evitar comportamiento inesperado en desarrollo.
-7. Mantener el alcance en refresco local y desarrollo, no en despliegue productivo.
-
-## Files to Read First
-- AGENTS.md
-- ai/repo-context.md
-- backend/README.md
-- backend/app/config.py
-- backend/app/collector.py
-- backend/app/server_targets.py
-- backend/app/storage.py
-
-## Expected Files to Modify
-- backend/README.md
-- backend/app/config.py
-- backend/app/collector.py
-- opcionalmente archivos nuevos si mejoran claridad, por ejemplo:
-  - backend/app/scheduler.py
-  - backend/scripts/run_local_refresh.py
-
-## Constraints
-- No tocar frontend.
-- No introducir un sistema de colas o infraestructura pesada.
-- No añadir complejidad innecesaria.
-- No hacer cambios destructivos.
-- Mantener la solución simple y enfocada a entorno local.
-
-## Validation
-- Existe una forma documentada y funcional de refrescar snapshots periódicamente en local.
-- El flujo sigue siendo controlable y fácil de detener.
-- La solución encaja con el backend actual sin sobredimensionarlo.
-- El sistema queda preparado para capturas más frecuentes y validación histórica.
-
-## Change Budget
-- Preferir menos de 5 archivos modificados o creados.
-- Preferir menos de 180 líneas cambiadas.
-## Outcome
-- `backend/app/scheduler.py` añade un bucle local de refresco periódico reutilizando el colector existente, sin introducir infraestructura de producción ni dependencias nuevas.
-- `backend/app/config.py` centraliza el intervalo por defecto mediante `HLL_BACKEND_REFRESH_INTERVAL_SECONDS`.
-- `backend/README.md` documenta cómo arrancar el refresco local, cómo detenerlo con `Ctrl+C` y qué flags de seguridad usar (`--interval`, `--no-fallback`, `--max-runs`).
-
-## Validation Result
-- Ejecutado: `python -m app.scheduler --source controlled --interval 1 --max-runs 1` desde `backend/`.
-- Resultado: se ejecutó un ciclo persistido correctamente sobre `backend/data/hll_vietnam_dev.sqlite3` y el proceso terminó al alcanzar el límite seguro de ejecuciones.
-- Revisado en código: el refresco local queda desacoplado del servidor HTTP y reutiliza `collect_server_snapshots(...)` sin duplicar lógica del colector.
-
-## Decision Notes
-- El refresco periódico se resolvió como un bucle local explícito y controlable para desarrollo, en lugar de introducir un scheduler embebido en el backend HTTP o infraestructura más pesada.

ai/tasks/done/TASK-038-historical-leaderboards-tabs-ui.md

@@ -1,72 +0,0 @@
-# TASK-038-historical-leaderboards-tabs-ui
-
-## Goal
-Transformar la sección de ranking semanal de la página histórica en un bloque con pestañas, permitiendo alternar entre varios leaderboards semanales del servidor seleccionado.
-
-## Context
-La UI histórica actual muestra un único ranking semanal de kills. El objetivo ahora es convertir esa zona en una sección con pestañas para poder consultar varias métricas sin recargar la página y manteniendo una experiencia clara. Las pestañas requeridas inicialmente son:
-- Top kills
-- Top muertes
-- Top número de partidas con más de 100 kills
-- Top puntos de soporte
-
-La UI debe seguir siendo propia del proyecto y consumir únicamente la API histórica interna.
-
-## Steps
-1. Revisar la página histórica actual y el bloque de ranking semanal.
-2. Revisar la nueva API histórica multitétrica disponible tras la task previa.
-3. Diseñar un sistema de pestañas claro y coherente con el estilo de la web.
-4. Implementar las pestañas para:
-   - Top kills
-   - Top muertes
-   - Top número de partidas con más de 100 kills
-   - Top puntos de soporte
-5. Hacer que las pestañas reutilicen el servidor actualmente seleccionado.
-6. Mantener estados de:
-   - loading
-   - vacío
-   - error
-7. Ajustar títulos, subtítulos y labels de la sección para que sean claros y no sobrecarguen visualmente.
-8. No usar páginas externas ni incrustaciones del scoreboard de la comunidad.
-9. Mantener la coherencia visual con el resto de la página histórica y con la landing principal.
-10. 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
-- frontend/historico.html
-- frontend/assets/js/historico.js
-- frontend/assets/css/historico.css
-- backend/app/routes.py
-- backend/app/payloads.py
-- backend/README.md
-
-## Expected Files to Modify
-- frontend/historico.html
-- frontend/assets/js/historico.js
-- frontend/assets/css/historico.css
-- opcionalmente documentación mínima si hay un cambio visible relevante en la navegación histórica
-
-## Constraints
-- No crear nuevas páginas basadas en URLs externas.
-- No romper la UI histórica actual fuera del bloque de ranking.
-- No introducir frameworks nuevos.
-- No hacer cambios destructivos.
-- Mantener la solución centrada en pestañas, claridad y consumo de nuestra API.
-
-## Validation
-- La sección de ranking semanal se convierte en un bloque con pestañas funcionales.
-- Las pestañas muestran:
-  - Top kills
-  - Top muertes
-  - Top partidas con más de 100 kills
-  - Top puntos de soporte
-- La UI consume únicamente la API interna del proyecto.
-- El selector de servidor sigue funcionando con estas pestañas.
-- Los cambios quedan committeados y se hace push al remoto si el entorno lo permite.
-
-## Change Budget
-- Preferir menos de 5 archivos modificados.
-- Preferir menos de 220 líneas cambiadas.

ai/tasks/done/TASK-038-historical-player-profile-api-foundation.md

@@ -1,65 +0,0 @@
-# TASK-038-historical-player-profile-api-foundation
-
-## Goal
-Crear la base de API para perfiles históricos de jugador dentro del proyecto, apoyándose en el histórico propio ya persistido y preparando futuras vistas de detalle sin depender de páginas externas.
-
-## Context
-Una vez resueltos rankings y partidas, el siguiente paso natural del histórico es poder profundizar por jugador. Esta task no debe construir todavía la UI completa de perfil, pero sí dejar lista una base de consulta que permita en fases posteriores mostrar el recorrido histórico de un jugador en los servidores de la comunidad.
-
-## Steps
-1. Revisar la estructura actual de identidad de jugador validada en la task de calidad histórica.
-2. Diseñar una base de endpoint o endpoints para consultar un jugador histórico.
-3. Incluir, como mínimo, datos como:
-   - identidad de jugador
-   - servidor o servidores donde aparece
-   - kills agregadas
-   - número de partidas
-   - rango temporal cubierto
-4. Implementar la consulta de forma consistente con la estructura histórica existente.
-5. Documentar el endpoint en backend.
-6. No crear todavía UI final de perfil.
-7. 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
-- backend/README.md
-- backend/app/historical_storage.py
-- backend/app/historical_models.py
-- backend/app/routes.py
-- backend/app/payloads.py
-- docs/historical-data-quality-notes.md
-
-## Expected Files to Modify
-- backend/app/routes.py
-- backend/app/payloads.py
-- backend/README.md
-- opcionalmente nuevos módulos de query histórica por jugador
-
-## Constraints
-- No usar páginas externas como perfil del producto.
-- No crear UI final de perfil todavía.
-- No romper endpoints históricos existentes.
-- No hacer cambios destructivos.
-- Mantener el trabajo centrado en la base de API de perfil.
-
-## Validation
-- Existe una base de endpoint para perfil histórico de jugador.
-- El endpoint se apoya en la persistencia histórica propia.
-- La identidad de jugador usada es consistente con la corrección de calidad ya realizada.
-- Los cambios quedan committeados y se hace push al remoto si el entorno lo permite.
-
-## Change Budget
-- Preferir menos de 5 archivos modificados o creados.
-- Preferir menos de 220 líneas cambiadas.
-## Outcome
-- Se expuso `GET /api/historical/player-profile?player=...`.
-- El endpoint acepta `stable_player_key`, `steam_id` o `source_player_id`.
-- La respuesta devuelve identidad de jugador, kills agregadas, número de partidas, rango temporal y desglose por servidores.
-- No se construyó UI final de perfil en esta task.
-
-## Validation Notes
-- `python -m compileall app`
-- comprobación local de payload reutilizando un `stable_player_key` real del ranking semanal

ai/tasks/done/TASK-038-server-history-summary-cards.md

@@ -1,72 +0,0 @@
-# TASK-038-server-history-summary-cards
-
-## Goal
-Añadir al backend y al frontend una primera capa de métricas históricas resumidas para los servidores reales, de forma que el panel muestre información más útil que el simple último snapshot.
-
-## Context
-La web ya muestra snapshots reales A2S y dispone de histórico persistido. Sin embargo, el valor actual del panel sigue siendo limitado si solo enseña la última captura y una tendencia básica. El siguiente paso lógico es construir resúmenes históricos ligeros a partir de lo ya almacenado, sin convertir aún la landing en un dashboard complejo.
-
-## Steps
-1. Revisar los endpoints históricos actuales y el panel de servidores existente.
-2. Identificar qué métricas históricas resumidas son viables con los snapshots ya persistidos, por ejemplo:
-   - última vez visto online
-   - número de capturas recientes
-   - promedio reciente de jugadores
-   - valor máximo reciente de población
-   - tiempo desde la última captura
-3. Añadir la capa mínima necesaria en backend para exponer estas métricas de forma clara.
-4. Integrar esas métricas en las tarjetas de servidores reales del frontend.
-5. Mantener la mejora ligera y coherente con el diseño actual.
-6. No introducir cálculos pesados ni analítica compleja.
-7. Preservar el comportamiento correcto si aún hay pocos snapshots disponibles.
-
-## Files to Read First
-- AGENTS.md
-- ai/repo-context.md
-- backend/README.md
-- backend/app/routes.py
-- backend/app/payloads.py
-- backend/app/storage.py
-- frontend/index.html
-- frontend/assets/js/main.js
-- frontend/assets/css/styles.css
-
-## Expected Files to Modify
-- backend/app/routes.py
-- backend/app/payloads.py
-- backend/app/storage.py
-- frontend/index.html
-- frontend/assets/js/main.js
-- frontend/assets/css/styles.css
-
-## Constraints
-- No rediseñar toda la landing.
-- No añadir gráficas complejas.
-- No introducir librerías nuevas.
-- No romper el fallback actual.
-- No hacer cambios destructivos.
-- Mantener la mejora centrada en valor histórico resumido.
-
-## Validation
-- El backend expone métricas históricas resumidas útiles para servidores reales.
-- El frontend las muestra de forma clara y legible.
-- La UI sigue funcionando aunque el histórico disponible sea limitado.
-- El panel gana valor funcional sin perder claridad.
-
-## Change Budget
-- Preferir menos de 6 archivos modificados.
-- Preferir menos de 220 líneas cambiadas.
-## Outcome
-- `backend/app/storage.py` adjunta a cada snapshot más reciente un `history_summary` ligero con capturas recientes, promedio de jugadores, pico, última vez visto online y minutos desde la última captura.
-- `backend/app/payloads.py` expone esas métricas en `GET /api/servers/latest` sin abrir un endpoint nuevo.
-- `frontend/assets/js/main.js` integra las métricas resumidas en las tarjetas reales e históricas ya renderizadas por la landing.
-- `frontend/assets/css/styles.css` añade el bloque visual compacto para mostrar esos resúmenes sin convertir la landing en un dashboard pesado.
-
-## Validation Result
-- Ejecutado: import directo de `build_server_latest_payload()` desde `backend/`.
-- Resultado: el payload devuelve `history_summary` por servidor con valores coherentes incluso cuando hay pocas capturas disponibles.
-- Ejecutado: `node --check frontend/assets/js/main.js`.
-- Resultado: sintaxis JavaScript válida tras integrar el bloque de métricas resumidas.
-
-## Decision Notes
-- Las métricas históricas resumidas se calculan sobre una ventana corta de snapshots recientes y se entregan junto al payload de último estado para mantener el backend simple y evitar analítica o endpoints adicionales en esta fase.

ai/tasks/done/TASK-039-community-clans-section-on-landing.md

@@ -1,62 +0,0 @@
-# TASK-039-community-clans-section-on-landing
-
-## Goal
-Añadir una nueva sección en la página principal para mostrar clanes/comunidades aliadas o relacionadas, con sus logos y un enlace hacia sus respectivos Discords.
-
-## Context
-Además de los servidores y del histórico, se quiere que la home tenga una sección específica de clanes donde puedan verse logos representativos y un link hacia cada Discord. Esta sección debe integrarse en la landing sin romper su simplicidad ni convertirse en un directorio desordenado.
-
-## Steps
-1. Revisar la landing actual y decidir una ubicación razonable para la nueva sección de clanes.
-2. Diseñar una sección clara y visualmente coherente con el resto de la home.
-3. Preparar una estructura de datos simple y mantenible para los clanes mostrados, por ejemplo:
-   - nombre
-   - logo
-   - enlace Discord
-   - descripción breve opcional
-4. Implementar la sección mostrando al menos:
-   - logo de cada clan
-   - nombre
-   - botón o link claro hacia su Discord
-5. Mantener la solución suficientemente flexible para añadir o quitar clanes más adelante sin reescribir la sección completa.
-6. Asegurar que la sección funciona bien en escritorio y móvil.
-7. No incrustar widgets completos de Discord salvo que ya estén expresamente aprobados; en esta task basta con enlaces claros al servidor Discord.
-8. Mantener la landing limpia y visualmente consistente.
-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
-- frontend/index.html
-- frontend/assets/css/styles.css
-- frontend/assets/js/main.js
-- ai/repo-context.md
-
-## Expected Files to Modify
-- frontend/index.html
-- frontend/assets/css/styles.css
-- frontend/assets/js/main.js
-- opcionalmente un archivo de datos/config simple en frontend si mejora claridad, por ejemplo:
-  - frontend/assets/js/community-clans.js
-- opcionalmente assets de logos si se dejan preparados o referenciados correctamente
-
-## Constraints
-- No romper la landing actual.
-- No recargar la home con demasiada información.
-- No depender de páginas externas como iframes para esta sección.
-- No introducir frameworks nuevos.
-- No hacer cambios destructivos.
-- Mantener el trabajo centrado en una sección limpia, visual y fácil de mantener.
-
-## Validation
-- Existe una nueva sección de clanes en la página principal.
-- Cada clan mostrado tiene logo y enlace claro a su Discord.
-- La sección es coherente con el estilo de la landing.
-- La estructura permite mantener y ampliar la lista de clanes razonablemente.
-- Los cambios quedan committeados y se hace push al remoto si el entorno lo permite.
-
-## Change Budget
-- Preferir menos de 5 archivos modificados o creados.
-- Preferir menos de 240 líneas cambiadas.

ai/tasks/done/TASK-039-historical-navigation-and-entry-points.md

@@ -1,58 +0,0 @@
-# TASK-039-historical-navigation-and-entry-points
-
-## Goal
-Añadir puntos de entrada y navegación razonables hacia la zona histórica propia del proyecto sin romper la simplicidad actual de la landing.
-
-## Context
-Si el proyecto empieza a tener una UI histórica propia, hace falta que el usuario pueda llegar a ella con una navegación clara. Esta task debe resolver ese acceso sin convertir la landing en una aplicación compleja ni depender de enlaces a páginas externas de la comunidad.
-
-## Steps
-1. Revisar la landing actual y la UI histórica creada.
-2. Diseñar uno o más puntos de entrada razonables hacia la zona histórica propia.
-3. Añadir enlaces o CTAs discretos y coherentes para acceder al histórico.
-4. Mantener la simplicidad de la landing.
-5. No sustituir los botones `Histórico` actuales del panel de servidores si siguen teniendo sentido como acceso al scoreboard externo; solo añadir navegación propia del proyecto donde aporte valor.
-6. 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
-- frontend/index.html
-- frontend/assets/css/styles.css
-- frontend/assets/js/main.js
-- frontend/historico.html
-- frontend/assets/css/historico.css
-- frontend/assets/js/historico.js
-
-## Expected Files to Modify
-- frontend/index.html
-- frontend/assets/css/styles.css
-- opcionalmente frontend/assets/js/main.js
-- opcionalmente la propia UI histórica si requiere ajustes de navegación
-
-## Constraints
-- No recargar la landing con demasiada navegación.
-- No romper la landing actual.
-- No depender de URLs de la comunidad como navegación principal del producto.
-- No hacer cambios destructivos.
-- Mantener el trabajo centrado en accesos claros y ligeros.
-
-## Validation
-- Existe una forma clara de acceder a la zona histórica propia.
-- La landing mantiene su simplicidad.
-- No se rompe el flujo actual de usuario.
-- Los cambios quedan committeados y se hace push al remoto si el entorno lo permite.
-
-## Change Budget
-- Preferir menos de 4 archivos modificados.
-- Preferir menos de 160 líneas cambiadas.
-## Outcome
-- Se añadieron CTAs discretos hacia `frontend/historico.html` en la hero y en el panel de servidores.
-- Se añadió un enlace de vuelta desde la vista histórica a la landing.
-- Se preservaron los botones actuales `Historico` hacia scoreboards externos en las cards de servidores.
-
-## Validation Notes
-- revisión de `frontend/index.html` y `frontend/assets/css/styles.css` para mantener simplicidad y coherencia visual
-- `node --check frontend/assets/js/historico.js`

ai/tasks/done/TASK-039-real-server-panel-data-density-pass.md

@@ -1,67 +0,0 @@
-# TASK-039-real-server-panel-data-density-pass
-
-## Goal
-Mejorar la densidad informativa y la claridad de las tarjetas de servidores reales, aprovechando mejor los datos ya disponibles sin recargar visualmente la landing.
-
-## Context
-Tras ocultar los placeholders cuando existen snapshots reales y preparar una CTA de conexión en español, el panel real ya tiene buena base. Sin embargo, todavía puede ganar valor mostrando mejor la información disponible y organizando mejor la jerarquía interna de las tarjetas.
-
-## Steps
-1. Revisar la composición actual de las tarjetas de servidores reales.
-2. Revisar qué datos ya están disponibles o pasarán a estar disponibles tras la task de resúmenes históricos.
-3. Mejorar la jerarquía interna de cada tarjeta:
-   - nombre
-   - estado
-   - mapa
-   - jugadores
-   - región
-   - última captura
-   - CTA
-   - métricas resumidas si existen
-4. Hacer que la tarjeta transmita más información útil sin volverse pesada.
-5. Mantener coherencia visual con la landing actual.
-6. Mejorar legibilidad en desktop y móvil.
-7. No rediseñar toda la página ni añadir nuevas secciones grandes.
-
-## Files to Read First
-- AGENTS.md
-- ai/repo-context.md
-- frontend/index.html
-- frontend/assets/js/main.js
-- frontend/assets/css/styles.css
-- backend/app/payloads.py
-- backend/app/routes.py
-
-## Expected Files to Modify
-- frontend/index.html
-- frontend/assets/js/main.js
-- frontend/assets/css/styles.css
-
-## Constraints
-- No tocar backend salvo si es estrictamente necesario por alineación menor con payloads ya existentes.
-- No añadir librerías nuevas.
-- No romper el fallback ni la CTA Conectar.
-- No hacer cambios destructivos.
-- Mantener la mejora centrada en claridad, jerarquía y densidad informativa.
-
-## Validation
-- Las tarjetas reales muestran mejor la información útil.
-- La jerarquía interna mejora.
-- La experiencia visual sigue siendo limpia.
-- El panel se entiende mejor en desktop y móvil.
-
-## Change Budget
-- Preferir menos de 3 archivos modificados.
-- Preferir menos de 180 líneas cambiadas.
-## Outcome
-- `frontend/assets/js/main.js` reorganiza la jerarquía interna de las tarjetas reales para destacar nombre, estado, población actual, mapa, región, última captura, CTA y métricas resumidas.
-- `frontend/assets/css/styles.css` refuerza la densidad informativa con una columna compacta de estado/población y una fila de quick facts legible en desktop y móvil.
-- La CTA `Conectar`, la tendencia reciente y el fallback existente se mantienen operativos.
-
-## Validation Result
-- Ejecutado: `node --check frontend/assets/js/main.js`.
-- Resultado: sintaxis JavaScript válida tras el ajuste de jerarquía y densidad visual.
-- Revisado en código: la versión enriquecida de la tarjeta conserva `steam://connect/<host>:<game_port>` para snapshots reales y mantiene el fallback cuando no hay datos reales utilizables.
-
-## Decision Notes
-- La mejora de densidad se concentró dentro de la tarjeta existente, sin añadir nuevas secciones grandes ni cambiar la arquitectura del panel.

ai/tasks/done/TASK-040-full-width-page-shell-and-section-width-rebalance.md

@@ -1,60 +0,0 @@
-# TASK-040-full-width-page-shell-and-section-width-rebalance
-
-## Goal
-Reorganizar el layout general de la landing para aprovechar mucho mejor el ancho de página disponible, separando el ancho útil de las distintas secciones y eliminando la sensación de página excesivamente estrecha.
-
-## Context
-La UI actual ya funciona y muestra datos reales, pero la composición general está demasiado constreñida en ancho. Esto provoca mucho espacio muerto lateral, reduce el impacto visual del diseño y comprime en exceso el panel de servidores. La landing necesita una estructura de anchuras más flexible y más coherente con un formato panorámico de desktop.
-
-## Steps
-1. Revisar la estructura general de contenedores de `frontend/index.html`.
-2. Revisar el sistema de anchuras, `max-width`, paddings laterales y shells actuales en `frontend/assets/css/styles.css`.
-3. Reorganizar la página para que no todas las secciones dependan del mismo ancho máximo.
-4. Definir al menos una separación clara entre:
-   - ancho del hero
-   - ancho del tráiler
-   - ancho del panel de servidores
-5. Aumentar el ancho útil del bloque de servidores para aprovechar mejor desktop amplio.
-6. Mantener el diseño responsive y sin romper móvil o tablet.
-7. Preservar la identidad visual actual sin rediseñar completamente la página.
-
-## Files to Read First
-- AGENTS.md
-- ai/repo-context.md
-- frontend/index.html
-- frontend/assets/css/styles.css
-- frontend/assets/js/main.js
-
-## Expected Files to Modify
-- frontend/index.html
-- frontend/assets/css/styles.css
-
-## Constraints
-- No tocar backend.
-- No añadir librerías nuevas.
-- No romper el comportamiento actual del frontend.
-- No hacer cambios destructivos.
-- Mantener la landing coherente con el tono visual actual.
-
-## Validation
-- La página ocupa mejor el ancho disponible en desktop.
-- El panel de servidores gana anchura real.
-- El hero y el tráiler mantienen buen equilibrio visual.
-- La UI sigue funcionando correctamente en tablet y móvil.
-
-## Change Budget
-- Preferir menos de 3 archivos modificados.
-- Preferir menos de 180 líneas cambiadas.
-
-## Outcome
-- `frontend/assets/css/styles.css` separa el ancho del hero, del bloque de trailer y del panel de servidores con shells independientes.
-- El `page-shell` deja de imponer un unico ancho maximo a toda la landing y el panel de servidores gana mas ancho util en desktop.
-- La mejora se mantuvo en CSS para no introducir cambios estructurales innecesarios en el HTML.
-
-## Validation Result
-- Revisado en diff: el ajuste queda limitado a `frontend/assets/css/styles.css` y al propio archivo de task.
-- Revisado en codigo: hero, trailer y panel de servidores usan anchuras maximas distintas y el layout movil conserva los resets responsive existentes.
-- Limitacion: no se ejecuto una comprobacion visual automatizada del navegador en esta tarea.
-
-## Decision Notes
-- La separacion de shells se resolvio con anchuras por seccion en lugar de crear nuevos wrappers HTML, para mantener la landing estable y reducir riesgo sobre el frontend actual.

ai/tasks/done/TASK-040-historical-ui-qa-and-polish-pass.md

@@ -1,72 +0,0 @@
-# TASK-040-historical-ui-qa-and-polish-pass
-
-## Goal
-Realizar una pasada final de QA y pulido sobre la nueva capa histórica del proyecto, tanto en backend como en la UI histórica propia, antes de abrir futuras métricas más avanzadas.
-
-## Context
-Tras añadir varias capas históricas de API y UI, conviene consolidar la calidad del resultado antes de seguir creciendo. Esta task debe centrarse en detectar pequeños defectos de presentación, consistencia, navegación, payload o comportamiento.
-
-## Steps
-1. Revisar la UI histórica completa y los endpoints históricos ya expuestos.
-2. Validar:
-   - weekly top kills
-   - partidas recientes
-   - resumen histórico si existe
-   - navegación histórica
-3. Revisar:
-   - estados de loading/error/empty
-   - consistencia de servidor seleccionado
-   - consistencia de naming
-   - legibilidad de tablas/listados
-   - responsive básico
-4. Corregir pequeños defectos o inconsistencias detectadas.
-5. No abrir rediseños grandes en esta task.
-6. 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
-- backend/README.md
-- backend/app/routes.py
-- backend/app/payloads.py
-- frontend/historico.html
-- frontend/assets/js/historico.js
-- frontend/assets/css/historico.css
-- frontend/index.html
-- frontend/assets/css/styles.css
-
-## Expected Files to Modify
-- frontend/historico.html
-- frontend/assets/js/historico.js
-- frontend/assets/css/historico.css
-- backend/app/routes.py
-- backend/app/payloads.py
-- opcionalmente documentación mínima si alguna parte visible necesita quedar reflejada
-
-## Constraints
-- No abrir nuevas grandes features históricas en esta task.
-- No depender de UI externa.
-- No hacer cambios destructivos.
-- Mantener el trabajo centrado en QA y acabado.
-
-## Validation
-- La capa histórica propia funciona con consistencia suficiente.
-- La UI histórica está pulida y usable.
-- No hay defectos relevantes en el flujo principal.
-- Los cambios quedan committeados y se hace push al remoto si el entorno lo permite.
-
-## Change Budget
-- Preferir menos de 6 archivos modificados.
-- Preferir menos de 220 líneas cambiadas.
-## Outcome
-- Se revisó la consistencia entre selector de servidor, resumen, ranking semanal y partidas recientes.
-- Se ajustaron estados visibles de loading, error y vacío en la vista histórica.
-- Se añadieron ajustes responsive básicos en `frontend/assets/css/historico.css`.
-- No se abrieron features históricas grandes fuera del alcance de QA y acabado.
-
-## Validation Notes
-- `python -m compileall app`
-- `node --check frontend/assets/js/historico.js`
-- comprobación local de payloads históricos: weekly top kills, recent matches, server summary y player profile

ai/tasks/done/TASK-040-randomized-community-clans-section.md

@@ -1,107 +0,0 @@
-# TASK-040-randomized-community-clans-section
-
-## Goal
-Implementar una sección única de clanes/comunidades en la landing principal, mostrando los clanes indicados con sus logos y enlaces a Discord, en orden aleatorio en cada carga de página.
-
-## Context
-La home ya incorpora una sección de clanes/comunidad, pero ahora hay una definición concreta de qué clanes deben aparecer, qué logos deben usarse y qué Discord debe enlazarse en cada caso. La sección debe ser única, clara y mantenible, y el orden de los clanes debe variar aleatoriamente cada vez que se cargue la página.
-
-## Datos a usar
-Los clanes/comunidades que deben mostrarse son estos:
-
-1. LCM
-   - Discord: `https://discord.gg/9F9S353QZv`
-   - Logo: usar la imagen proporcionada para LCM
-
-2. La 129
-   - Discord: placeholder por ahora
-   - Logo: usar la imagen proporcionada para La 129
-
-3. 250 Hispania
-   - Discord: `https://discord.gg/3E62Yb6Aw3`
-   - Logo: usar solo el escudo de la imagen proporcionada, quitando la parte de texto `Historia de la 250` y quedándose únicamente con el emblema/escudo
-
-4. H9H
-   - Discord: `https://discord.gg/tYnXK7MQjB`
-   - Logo: placeholder por ahora
-
-5. BxB
-   - Discord: placeholder por ahora
-   - Logo: usar la imagen proporcionada para BxB
-
-6. 7dv
-   - Discord: `https://discord.gg/3sxNQZwrg6`
-   - Logo: usar la imagen proporcionada para 7dv
-
-## Steps
-1. Revisar la landing actual y la sección de clanes/comunidad ya existente.
-2. Ajustar la sección para que muestre exactamente estos 6 clanes/comunidades y no una lista distinta.
-3. Mantener toda la información de los clanes en una estructura de datos clara y mantenible, preferiblemente en JS si eso encaja mejor con el renderizado actual.
-4. Implementar la sección para mostrar, como mínimo, por cada clan:
-   - logo
-   - nombre
-   - botón o enlace a Discord
-5. Hacer que el orden de aparición de los clanes sea aleatorio en cada carga de página.
-6. Asegurar que la aleatorización no rompe la estructura visual ni genera duplicados.
-7. Para los clanes con Discord aún no definido (`La 129` y `BxB`), mostrar un estado coherente y no roto, por ejemplo:
-   - botón deshabilitado
-   - etiqueta `Próximamente`
-   - o equivalente visual claro y honesto
-8. Para los clanes con logo pendiente (`H9H`), usar un placeholder visual coherente con la estética de la web.
-9. Para `250 Hispania`, usar solo el escudo/emblema, sin el texto `Historia de la 250`.
-10. Mantener la sección como una única sección de comunidad/clanes en la home, sin duplicarla.
-11. Asegurar que la sección funciona correctamente en escritorio y móvil.
-12. Mantener la estética coherente con la landing actual.
-13. 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
-- frontend/index.html
-- frontend/assets/css/styles.css
-- frontend/assets/js/main.js
-- cualquier archivo actual de datos/renderizado de la sección de clanes si ya existe
-- assets actuales relacionados con logos de comunidad
-
-## Expected Files to Modify
-- frontend/index.html
-- frontend/assets/css/styles.css
-- frontend/assets/js/main.js
-- opcionalmente un archivo de datos/config si mejora claridad, por ejemplo:
-  - frontend/assets/js/community-clans.js
-- opcionalmente nuevos assets referenciados correctamente si la implementación los necesita, por ejemplo dentro de:
-  - frontend/assets/img/clans/
-
-## Constraints
-- No romper la landing actual.
-- No crear varias secciones de clanes; debe quedar una sola.
-- No introducir frameworks nuevos.
-- No depender de widgets externos o iframes de Discord para esta sección.
-- No hacer cambios destructivos.
-- Mantener el trabajo centrado en la sección de clanes, su contenido real y el orden aleatorio por carga.
-
-## Validation
-- La home muestra una única sección de clanes/comunidades.
-- Aparecen exactamente estos 6 clanes/comunidades:
-  - LCM
-  - La 129
-  - 250 Hispania
-  - H9H
-  - BxB
-  - 7dv
-- El orden cambia aleatoriamente en cada carga de página.
-- Los enlaces de Discord correctos funcionan para:
-  - LCM
-  - 250 Hispania
-  - H9H
-  - 7dv
-- Los clanes sin enlace definitivo no muestran botones rotos.
-- `250 Hispania` usa solo el escudo/emblema, sin el texto lateral.
-- La sección sigue siendo visualmente coherente y responsive.
-- Los cambios quedan committeados y se hace push al remoto si el entorno lo permite.
-
-## Change Budget
-- Preferir menos de 6 archivos modificados o creados.
-- Preferir menos de 260 líneas cambiadas.

ai/tasks/done/TASK-041-historical-resumable-backfill-expansion.md

@@ -1,108 +0,0 @@
-# TASK-041-historical-resumable-backfill-expansion
-
-## Goal
-Ampliar la cobertura historica persistida de ambos servidores de la comunidad lo maximo posible mediante un proceso de backfill reanudable, seguro e idempotente, capaz de continuar sesiones incompletas sin perder progreso cuando la fuente CRCON publica falle intermitentemente.
-
-## Context
-La capa historica del proyecto ya esta funcionando y la UI ya muestra cobertura registrada, pero la cobertura actual sigue siendo parcial. La fuente CRCON publica indica archivos mucho mas profundos que lo actualmente persistido, pero las sesiones largas de bootstrap sufren respuestas `502` intermitentes bajo carga. Eso significa que el limite actual de fechas no representa necesariamente el historico real disponible, sino el alcance conseguido hasta ahora por la importacion.
-
-La solucion correcta no es asumir que el historico ya esta completo, sino implementar o consolidar un backfill reanudable por lotes que permita seguir retrocediendo en el tiempo y ampliando la cobertura historica de forma progresiva.
-
-## Steps
-1. Revisar la implementacion actual de:
-   - bootstrap historico
-   - refresh incremental
-   - persistencia historica
-   - validacion de cobertura
-2. Revisar como se manejan actualmente:
-   - paginacion
-   - progreso de bootstrap
-   - reintentos
-   - errores upstream tipo `502`
-3. Diseñar o consolidar una estrategia de backfill reanudable que permita:
-   - continuar desde una pagina o cursor previo
-   - guardar progreso util por servidor
-   - reintentar sin duplicar datos
-   - ampliar cobertura historica por bloques
-4. Implementar o reforzar un mecanismo para ejecutar sesiones sucesivas de backfill historico para ambos servidores.
-5. Garantizar que el sistema:
-   - no pierde progreso util
-   - no vuelve a importar innecesariamente lo ya consolidado
-   - puede seguir avanzando aunque una sesion concreta falle a mitad
-6. Añadir o mejorar metadatos operativos de cobertura y progreso, por ejemplo:
-   - ultima pagina procesada por servidor
-   - rango temporal cubierto actual
-   - numero total de partidas persistidas
-   - estado del ultimo intento de backfill
-7. Ejecutar o dejar documentado un flujo operativo realista para seguir ampliando cobertura en varias sesiones.
-8. Documentar claramente que la cobertura historica puede crecer progresivamente y que el limite actual no debe interpretarse como limite definitivo del origen mientras siga habiendo paginas disponibles.
-9. No crear todavia nueva UI historica en esta task salvo ajustes minimos de payload o semantica si fueran imprescindibles para reflejar mejor la cobertura.
-10. Al completar la implementacion:
-   - 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/historical-crcon-source-discovery.md
-- docs/historical-domain-model.md
-- docs/historical-data-quality-notes.md
-- docs/historical-coverage-report.md
-- backend/README.md
-- backend/app/config.py
-- backend/app/historical_ingestion.py
-- backend/app/historical_storage.py
-- backend/app/historical_models.py
-- backend/app/routes.py
-- backend/app/payloads.py
-
-## Expected Files to Modify
-- backend/README.md
-- backend/app/config.py
-- backend/app/historical_ingestion.py
-- backend/app/historical_storage.py
-- backend/app/historical_models.py
-- opcionalmente nuevos modulos auxiliares si mejoran claridad del backfill y del checkpoint de progreso, por ejemplo:
-  - backend/app/historical_backfill_state.py
-  - backend/app/historical_backfill_runner.py
-- opcionalmente documentacion tecnica adicional, por ejemplo:
-  - docs/historical-coverage-report.md
-  - docs/historical-backfill-operations.md
-
-## Constraints
-- No basar esta ampliacion historica en A2S.
-- No crear paginas frontend nuevas usando la URL de la comunidad.
-- No depender del HTML de `/games` como fuente final.
-- No romper el flujo actual de live status.
-- No romper la persistencia historica ya existente.
-- No hacer cambios destructivos.
-- Mantener el trabajo centrado en backfill reanudable, idempotencia, resiliencia y ampliacion de cobertura.
-
-## Validation
-- Existe un mecanismo reanudable para seguir ampliando el historico por lotes.
-- El backfill puede continuar sin duplicar datos ya persistidos.
-- El sistema registra progreso util por servidor.
-- La cobertura historica puede ampliarse progresivamente con sesiones sucesivas.
-- La documentacion deja claro el estado real y las limitaciones operativas.
-- Los cambios quedan committeados y se hace push al remoto si el entorno lo permite.
-
-## Change Budget
-- Preferir menos de 7 archivos modificados o creados.
-- Preferir menos de 260 lineas cambiadas.
-
-## Outcome
-- Se añadio persistencia de checkpoint por servidor y modo en `historical_backfill_progress`.
-- El bootstrap ahora reanuda automaticamente desde `next_page` cuando no se pasa `--start-page`.
-- Cada pagina completada guarda progreso util (`last_completed_page`, `next_page`, total descubierto y estado del ultimo intento).
-- `server-summary` y el reporte de cobertura exponen metadatos operativos de backfill para reflejar mejor la cobertura real importada.
-- Se documento el flujo operativo reanudable y los nuevos ajustes de reintentos para errores CRCON intermitentes.
-
-## Validation Notes
-- `python -m compileall app`
-- validacion local con SQLite de prueba en workspace verificando:
-  - reanudacion desde pagina `4` tras completar la pagina `3`
-  - persistencia de `last_completed_page`
-  - exposicion de `discovered_total_pages` en cobertura y resumen
-- no se ejecuto backfill real contra CRCON por las restricciones de red del entorno actual

ai/tasks/done/TASK-041-real-server-card-layout-reorganization.md

@@ -1,68 +0,0 @@
-# TASK-041-real-server-card-layout-reorganization
-
-## Goal
-Reorganizar internamente las tarjetas de servidores reales para que aprovechen mejor el espacio horizontal, reduzcan compresión vertical y mejoren la legibilidad de los datos.
-
-## Context
-Las tarjetas actuales contienen información útil, pero en una composición demasiado estrecha y alta. Eso hace que varias métricas queden apelotonadas, con mala jerarquía y sensación de desborde. Esta task debe rediseñar la distribución interna de la tarjeta, no la arquitectura funcional del panel.
-
-## Steps
-1. Revisar la estructura HTML y JS que renderiza las tarjetas de servidores reales.
-2. Reorganizar la composición interna para que la tarjeta tenga una lectura más horizontal y clara.
-3. Priorizar visualmente:
-   - nombre del servidor
-   - estado
-   - botón Conectar
-   - jugadores
-   - mapa
-   - región
-   - última captura
-   - métricas resumidas
-4. Reducir altura innecesaria y mejorar la distribución interna de bloques.
-5. Mantener la CTA de conexión visible y bien integrada.
-6. Mejorar el comportamiento de nombres largos y textos densos.
-7. No romper el fallback ni la lógica actual del panel.
-
-## Files to Read First
-- AGENTS.md
-- ai/repo-context.md
-- frontend/index.html
-- frontend/assets/js/main.js
-- frontend/assets/css/styles.css
-- backend/app/payloads.py
-
-## Expected Files to Modify
-- frontend/index.html
-- frontend/assets/js/main.js
-- frontend/assets/css/styles.css
-
-## Constraints
-- No tocar backend salvo alineación mínima si fuera imprescindible.
-- No añadir librerías nuevas.
-- No romper la CTA Conectar.
-- No hacer cambios destructivos.
-- Mantener la mejora centrada en layout y legibilidad.
-
-## Validation
-- Las tarjetas reales son más legibles y aprovechan mejor el ancho.
-- La jerarquía interna mejora claramente.
-- El texto largo deja de sentirse comprimido o desbordado.
-- La UI mantiene coherencia visual con el resto de la landing.
-
-## Change Budget
-- Preferir menos de 3 archivos modificados.
-- Preferir menos de 180 líneas cambiadas.
-
-## Outcome
-- `frontend/assets/js/main.js` reorganiza la tarjeta real en dos zonas: cabecera prioritaria con estado, poblacion y CTA, y cuerpo con quick facts, resumen historico y tendencia.
-- `frontend/assets/css/styles.css` adapta la tarjeta a una lectura mas horizontal en desktop y endurece el wrapping de nombres y valores largos.
-- No fue necesario tocar `frontend/index.html` ni alinear payloads del backend.
-
-## Validation Result
-- Ejecutado: `node --check frontend/assets/js/main.js`.
-- Resultado: sintaxis JavaScript valida tras la reorganizacion del render.
-- Revisado en codigo: la CTA `Conectar` sigue ligada a `steam://connect/<host>:<game_port>` y solo aparece para snapshots reales A2S.
-- Limitacion: no se ejecuto una comprobacion visual automatizada del navegador en esta tarea.
-
-## Decision Notes
-- La reduccion de altura se resolvio moviendo resumen y tendencia a una composicion interna mas horizontal, sin cambiar la logica de secciones del panel ni el fallback existente.

ai/tasks/done/TASK-042-historical-snapshots-storage-and-model.md

@@ -1,68 +0,0 @@
-# TASK-042-historical-snapshots-storage-and-model
-
-## Goal
-Diseñar e implementar una capa de almacenamiento de snapshots históricos precalculados para el proyecto, preparada para servir rápidamente resumen, rankings y partidas recientes sin recalcular agregados pesados en tiempo real.
-
-## Context
-La página histórica ya funciona, pero parte de la información puede requerir agregaciones costosas si se calculan en el momento de cada carga o al cambiar de pestaña. El objetivo es introducir una capa de snapshots precalculados y persistidos que permita responder de forma rápida y estable. Esto debe incluir no solo el resumen del servidor, sino también los tops/rankings semanales.
-
-## Steps
-1. Revisar la estructura histórica actual y los endpoints/API que hoy calculan resumen, rankings y partidas recientes.
-2. Diseñar un modelo de snapshot persistido que soporte, como mínimo:
-   - resumen de servidor
-   - top kills semanales
-   - top muertes semanales
-   - top partidas con más de 100 kills por jugador
-   - top puntos de soporte semanales
-   - partidas recientes
-3. Definir para cada snapshot metadatos claros, por ejemplo:
-   - server_key
-   - snapshot_type
-   - metric
-   - window
-   - payload_json
-   - generated_at
-   - source_range_start
-   - source_range_end
-   - is_stale
-4. Implementar el almacenamiento local de snapshots de forma coherente con la persistencia histórica actual.
-5. Documentar la estructura y propósito de esta nueva capa.
-6. No migrar todavía toda la UI a snapshots en esta task.
-7. 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
-- backend/README.md
-- backend/app/historical_models.py
-- backend/app/historical_storage.py
-- backend/app/payloads.py
-- backend/app/routes.py
-- docs/historical-domain-model.md
-
-## Expected Files to Modify
-- backend/README.md
-- backend/app/historical_models.py
-- backend/app/historical_storage.py
-- opcionalmente nuevos módulos, por ejemplo:
-  - backend/app/historical_snapshots.py
-  - backend/app/historical_snapshot_storage.py
-- opcionalmente documentación técnica adicional
-
-## Constraints
-- No basar esta capa en A2S.
-- No crear todavía nueva UI en esta task.
-- No hacer cambios destructivos.
-- Mantener el trabajo centrado en almacenamiento y modelo de snapshots.
-
-## Validation
-- Existe un modelo de snapshot persistido claro.
-- El modelo cubre resumen, rankings y partidas recientes.
-- La estructura está lista para ser rellenada periódicamente.
-- Los cambios quedan committeados y se hace push al remoto si el entorno lo permite.
-
-## Change Budget
-- Preferir menos de 6 archivos modificados o creados.
-- Preferir menos de 220 líneas cambiadas.

ai/tasks/done/TASK-042-server-panel-grid-and-overflow-hardening.md

@@ -1,62 +0,0 @@
-# TASK-042-server-panel-grid-and-overflow-hardening
-
-## Goal
-Fortalecer la rejilla del panel de servidores y corregir problemas de compresión, desborde y distribución espacial en desktop, tablet y móvil.
-
-## Context
-El panel de servidores ya consume datos reales y funciona correctamente, pero la rejilla actual no está aprovechando bien el espacio horizontal y deja tarjetas demasiado estrechas. Además, la estructura necesita endurecerse frente a nombres largos, métricas densas y cambios de anchura de viewport.
-
-## Steps
-1. Revisar la rejilla actual del panel de servidores.
-2. Ajustar el sistema de columnas para permitir una distribución más robusta y flexible.
-3. Usar una estrategia de `grid` adecuada para:
-   - desktop ancho
-   - desktop medio
-   - tablet
-   - móvil
-4. Revisar `min-width`, `max-width`, `gap`, `overflow-wrap` y cualquier punto de compresión o desborde.
-5. Asegurar que las tarjetas no se rompan visualmente con contenido real.
-6. Mantener una composición limpia, con buen aire y buen equilibrio.
-7. No rediseñar toda la landing fuera del panel de servidores.
-
-## Files to Read First
-- AGENTS.md
-- ai/repo-context.md
-- frontend/index.html
-- frontend/assets/css/styles.css
-- frontend/assets/js/main.js
-
-## Expected Files to Modify
-- frontend/assets/css/styles.css
-- frontend/index.html
-- opcionalmente frontend/assets/js/main.js si hay que ajustar clases o hooks del render
-
-## Constraints
-- No tocar backend.
-- No añadir librerías nuevas.
-- No romper el comportamiento actual del panel.
-- No hacer cambios destructivos.
-- Mantener el trabajo centrado en grid, responsive y overflow.
-
-## Validation
-- El panel de servidores ocupa mejor el ancho disponible.
-- Las tarjetas ya no se sienten excesivamente estrechas.
-- Se corrigen problemas de compresión y desborde.
-- El comportamiento responsive mejora en desktop, tablet y móvil.
-
-## Change Budget
-- Preferir menos de 3 archivos modificados.
-- Preferir menos de 160 líneas cambiadas.
-
-## Outcome
-- `frontend/assets/css/styles.css` sustituye la rejilla fija de dos columnas por un `auto-fit` con `minmax`, permitiendo mejor reparto en desktop ancho y desktop medio.
-- El mismo archivo endurece el panel con `min-width: 0`, `max-width: 100%`, `overflow: hidden` y subrejillas flexibles para quick facts y resumen.
-- No fue necesario tocar `frontend/index.html` ni `frontend/assets/js/main.js`.
-
-## Validation Result
-- Revisado en codigo: el panel ahora define comportamiento especifico para desktop ancho, desktop medio, tablet y movil mediante breakpoints en `1120px`, `760px` y el ajuste movil existente.
-- Revisado en diff: la task queda limitada a `frontend/assets/css/styles.css` y al archivo de task.
-- Limitacion: no se ejecuto una comprobacion visual automatizada del navegador en esta tarea.
-
-## Decision Notes
-- La hardening del panel se resolvio a nivel de grid y overflow sin volver a rediseñar las tarjetas ni tocar la logica de render ya ajustada en la task anterior.