Add ranking metric expansion

This commit is contained in:
devRaGonSa
2026-06-09 07:32:29 +02:00
parent f74ac17f48
commit 12a215d11a
13 changed files with 869 additions and 94 deletions

View File

@@ -1,121 +0,0 @@
---
id: TASK-184-define-ranking-metric-expansion-contract
title: Define ranking metric expansion contract
status: pending
type: documentation
team: Analista
supporting_teams:
- PM
- Backend Senior
- Frontend Senior
- Arquitecto de Base de Datos
- Experto en interfaz
roadmap_item: foundation
priority: high
---
# TASK-184-define-ranking-metric-expansion-contract - Define ranking metric expansion contract
## Goal
Define the functional and technical contract for expanding `Ranking global` with additional metrics in V1.1 without reactivating Elo/MMR or introducing a new architecture.
## Context
The current Ranking implementation is limited to `kills`. The repository already has a dedicated Ranking route, an RCON materialized weekly/monthly read path, and an annual snapshot read path. Before backend or frontend expansion, HLL Vietnam needs explicit documentation that defines which extra metrics are safe, how they are calculated, what timeframes they support, and where annual support must remain constrained.
Preserve the current product identity: Spanish-speaking HLL Vietnam community, military/Vietnam/tactical/sober visual direction and controlled repository evolution.
## Steps
1. Read the listed files first.
2. Update the Ranking contract documentation for V1.1 metric expansion only.
3. Define the supported metrics and the formula or aggregation rule for each one.
4. Define expected ordering for each metric and clarify tie-break behavior.
5. Define supported timeframes per metric:
- `weekly`
- `monthly`
- `annual`
6. Clarify the difference between weekly/monthly runtime reads and annual snapshot reads.
7. Clarify whether annual remains limited to `kills` or only allows additional metrics when a safe snapshot-backed read path already exists.
8. Define payload expectations and controlled error behavior for unsupported metrics.
9. Keep non-goals and source-policy restrictions explicit.
## Files to Read First
- `AGENTS.md`
- `ai/repo-context.md`
- `ai/architecture-index.md`
- `docs/global-ranking-page-plan.md`
- `docs/stats-section-functional-plan.md`
- `docs/annual-ranking-snapshot-runbook.md`
- `backend/app/rcon_historical_leaderboards.py`
- `backend/app/rcon_annual_rankings.py`
- `backend/app/routes.py`
- `backend/app/payloads.py`
- `ai/tasks/done/TASK-183-review-global-ranking-implementation.md`
## Expected Files to Modify
- `docs/global-ranking-page-plan.md`
- `ai/tasks/done/TASK-184-define-ranking-metric-expansion-contract.md`
## Constraints
- Documentation-only task.
- Do not modify backend files.
- Do not modify frontend files.
- Do not create migrations.
- Do not change scripts.
- Do not reactivate Elo/MMR.
- Do not reintroduce Comunidad Hispana #03.
- Do not define public scoreboard as the normal primary source while RCON is available.
- Do not expand annual behavior into runtime full-year recalculation on public requests.
## Validation
Before completing the task ensure:
- `docs/global-ranking-page-plan.md` explicitly documents V1.1 supported Ranking metrics
- the contract defines formulas for:
- `kills`
- `deaths`
- `teamkills`
- `matches_considered`
- `kd_ratio`
- `kills_per_match`
- the contract defines safe handling for:
- `deaths=0`
- `matches_considered=0`
- the contract defines expected ordering for each metric
- the contract defines timeframe support per metric and annual limitations explicitly
- unsupported-metric error behavior is documented
- non-goals remain explicit:
- Elo/MMR
- public scoreboard as primary source
- large new tables
- advanced charts
- authentication
- Comunidad Hispana #03
- `git diff --name-only` stays within task scope
- if automated tests do not apply because the task is documentation-only, that limitation is documented in the task outcome
## Outcome
Document:
- supported Ranking V1.1 metrics
- formula for each metric
- ordering and tie-break expectations
- supported timeframes by metric
- annual snapshot limitations and safety rules
- expected payload adjustments, if any
- controlled error behavior for unsupported metrics
- validation performed
- explicit note that no automated tests apply if this remains documentation-only
## 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.

View File

@@ -1,121 +0,0 @@
---
id: TASK-185-add-ranking-extra-metrics-backend-support
title: Add ranking extra metrics backend support
status: pending
type: backend
team: Backend Senior
supporting_teams:
- Arquitecto Python
- Arquitecto de Base de Datos
roadmap_item: foundation
priority: high
---
# TASK-185-add-ranking-extra-metrics-backend-support - Add ranking extra metrics backend support
## Goal
Add backend support for additional `Ranking global` metrics by reusing the existing RCON materialized read model, while preserving the current Ranking route and avoiding unsafe annual recomputation.
## Context
`TASK-183` confirmed that `GET /api/ranking` currently supports only `metric=kills`, with weekly/monthly reading from the RCON materialized leaderboard and annual reading from snapshots. The next backend step is to extend metric support safely for weekly/monthly and keep annual constrained to snapshot-safe behavior only.
Preserve the current product identity: Spanish-speaking HLL Vietnam community, military/Vietnam/tactical/sober visual direction and controlled repository evolution.
## Steps
1. Read the listed files first.
2. Keep the public endpoint as:
- `GET /api/ranking?timeframe=weekly|monthly|annual&server_id=<server-or-all>&metric=<metric>&limit=<limit>&year=<year>`
3. Extend weekly/monthly support for:
- `kills`
- `deaths`
- `teamkills`
- `matches_considered`
- `kd_ratio`
- `kills_per_match`
4. Preserve `metric=kills` behavior and compatibility for existing Ranking requests.
5. Reuse the materialized RCON read model and avoid introducing a new ranking architecture.
6. Keep annual support safe:
- support `kills`
- only support additional annual metrics if they are snapshot-backed without public full-year recomputation
- otherwise return a controlled `400` for unsupported annual metrics
7. Update route validation and payload normalization only where necessary.
8. Extend validation coverage for the new metrics and failure cases.
## Files to Read First
- `AGENTS.md`
- `ai/repo-context.md`
- `ai/architecture-index.md`
- `docs/global-ranking-page-plan.md`
- `backend/app/routes.py`
- `backend/app/payloads.py`
- `backend/app/rcon_historical_leaderboards.py`
- `backend/app/rcon_annual_rankings.py`
- `scripts/run-stats-validation.ps1`
- `scripts/run-integration-tests.ps1`
- `ai/tasks/done/TASK-183-review-global-ranking-implementation.md`
- `ai/tasks/done/TASK-184-define-ranking-metric-expansion-contract.md`
## Expected Files to Modify
- `backend/app/rcon_historical_leaderboards.py`
- `backend/app/routes.py`
- `backend/app/payloads.py`
- `backend/app/rcon_annual_rankings.py`
- `scripts/run-stats-validation.ps1`
- `ai/tasks/done/TASK-185-add-ranking-extra-metrics-backend-support.md`
## Constraints
- Do not create migrations.
- Do not introduce a new architecture.
- Do not recalculate the annual full-year ranking on public requests.
- Do not reactivate Elo/MMR.
- Do not reintroduce Comunidad Hispana #03.
- Do not use public scoreboard as the normal primary source.
- Do not modify frontend files.
- Do not break Stats endpoints.
- Do not break the existing Ranking route for `metric=kills`.
## Validation
Before completing the task ensure:
- `powershell -ExecutionPolicy Bypass -File scripts/run-stats-validation.ps1`
- `powershell -ExecutionPolicy Bypass -File scripts/run-integration-tests.ps1`
- validate `GET /api/ranking` for:
- `timeframe=weekly&metric=kills`
- `timeframe=weekly&metric=deaths`
- `timeframe=weekly&metric=teamkills`
- `timeframe=weekly&metric=matches_considered`
- `timeframe=weekly&metric=kd_ratio`
- `timeframe=weekly&metric=kills_per_match`
- `timeframe=monthly&metric=kd_ratio`
- `timeframe=monthly&metric=kills_per_match`
- `timeframe=annual&metric=kills`
- unsupported metric
- unsupported timeframe
- `limit=3`
- `limit=101` or invalid limit according to the current contract
- confirm annual behavior is still snapshot-safe
- confirm `git diff --name-only` stays within scope
## Outcome
Document:
- metrics added
- formulas applied in backend ranking logic
- annual metric behavior and limitations
- validations executed
- known limitations
- recommended next task: expose the new metrics safely in Ranking frontend UX
## 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.

View File

@@ -1,117 +0,0 @@
---
id: TASK-186-polish-ranking-metric-ux-and-limits
title: Polish ranking metric UX and limits
status: pending
type: frontend
team: Frontend Senior
supporting_teams:
- Experto en interfaz
- Disenador grafico
- Backend Senior
roadmap_item: foundation
priority: high
---
# TASK-186-polish-ranking-metric-ux-and-limits - Polish ranking metric UX and limits
## Goal
Update the `Ranking` page UX so it exposes the backend-supported metric set clearly, improves limit handling and error messaging, and preserves the separation between global tops and player-specific Stats.
## Context
The current Ranking UI is limited to `kills`, only exposes a small set of limits, and handles invalid `limit` through a generic error path. If backend metric expansion is delivered, the frontend must expose the new metric set safely, keep annual constraints clear, and improve the explanatory UX without changing backend architecture.
Preserve the current product identity: Spanish-speaking HLL Vietnam community, military/Vietnam/tactical/sober visual direction and controlled repository evolution.
## Steps
1. Read the listed files first.
2. Update `ranking.html`, `ranking.js` and styling only as needed to expose the supported Ranking metric set.
3. Allow selecting:
- `kills`
- `deaths`
- `teamkills`
- `matches_considered`
- `kd_ratio`
- `kills_per_match`
4. Make the UI clearly show:
- the active metric
- the active timeframe
- the active server
5. If annual remains `kills`-only, hide, disable or clearly message unsupported annual metrics without breaking the flow.
6. Improve limit UX so the available UI limits are reasonable and aligned with backend constraints.
7. Add a clearer message for invalid `limit` if it arrives from manual URL or parameter manipulation.
8. Keep or improve the message for unsupported metric and unsupported timeframe.
9. Preserve the guidance that `Stats` is for one-player lookup and `Ranking` is for global tops.
10. Add only minimal cross-linking between `Ranking` and `Stats` if helpful and already aligned with existing page patterns.
## Files to Read First
- `AGENTS.md`
- `ai/repo-context.md`
- `ai/architecture-index.md`
- `docs/global-ranking-page-plan.md`
- `frontend/ranking.html`
- `frontend/assets/js/ranking.js`
- `frontend/assets/css/styles.css`
- `frontend/stats.html`
- `frontend/assets/js/stats.js`
- `backend/app/routes.py`
- `ai/tasks/done/TASK-185-add-ranking-extra-metrics-backend-support.md`
## Expected Files to Modify
- `frontend/ranking.html`
- `frontend/assets/js/ranking.js`
- `frontend/assets/css/styles.css`
- `frontend/stats.html`
- `scripts/run-stats-validation.ps1`
- `ai/tasks/done/TASK-186-polish-ranking-metric-ux-and-limits.md`
## Constraints
- Do not modify backend files.
- Do not create endpoints.
- Do not modify the database.
- Do not reactivate Elo/MMR.
- Do not reintroduce Comunidad Hispana #03.
- Do not introduce frameworks.
- Keep HTML/CSS/JS vanilla.
- Maintain the military/Vietnam/tactical/sober visual identity.
- Do not break Stats.
- Do not duplicate complex logic unnecessarily.
## Validation
Before completing the task ensure:
- `node --check frontend/assets/js/ranking.js`
- `node --check frontend/assets/js/stats.js`
- `powershell -ExecutionPolicy Bypass -File scripts/run-stats-validation.ps1`
- `powershell -ExecutionPolicy Bypass -File scripts/run-integration-tests.ps1`
- serve frontend with `python -m http.server` and confirm HTTP `200` for:
- `ranking.html`
- `assets/js/ranking.js`
- `stats.html`
- `index.html`
- if local backend is available, validate real metric selection against the supported backend contract
- if backend is unavailable, validate the offline fallback path explicitly
- confirm `git diff --name-only` stays within scope
## Outcome
Document:
- metrics exposed in UI
- annual behavior in the UX
- UI limit choices
- error states covered
- validations executed
- recommended follow-ups, if any
## 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.