Complete Stats validation, comparison cards, and annual ranking hardening
This commit is contained in:
devRaGonSa
@@ -1,7 +1,7 @@
|
||||
---
|
||||
id: TASK-175-add-stats-regression-validation-script
|
||||
title: Add Stats regression validation script
|
||||
status: pending
|
||||
status: done
|
||||
type: platform
|
||||
team: PM
|
||||
supporting_teams:
|
||||
@@ -67,5 +67,31 @@ The Stats section already has public-facing pages, JS assets, and backend endpoi
|
||||
|
||||
## Outcome
|
||||
|
||||
Document validated endpoints, controlled limitations, and the immediate next task recommendation.
|
||||
Validated surfaces:
|
||||
|
||||
- `frontend/stats.html` asset wiring and required Stats UI anchors
|
||||
- `GET /health`
|
||||
- `GET /api/stats/players/search`
|
||||
- `GET /api/stats/players/{player_id}`
|
||||
- `GET /api/stats/rankings/annual`
|
||||
|
||||
Implemented validation:
|
||||
|
||||
- Added `scripts/run-stats-validation.ps1` to check Stats asset presence, route-contract behavior, invalid parameter handling, and controlled backend-unavailable messaging.
|
||||
- Wired `scripts/run-integration-tests.ps1` to execute the Stats validation and fail on non-zero child process exit codes.
|
||||
|
||||
Controlled limitations observed during validation:
|
||||
|
||||
- The local live backend was not running during task validation, so live HTTP checks reported the expected offline guidance instead of ambiguous failure.
|
||||
- Current normalized all-server scope is returned as `all-servers`.
|
||||
- Annual ranking `data.limit` currently reflects the effective stored snapshot size when a ready snapshot contains fewer rows than the requested limit; the validator accepts that current behavior without changing runtime logic.
|
||||
|
||||
Validation run:
|
||||
|
||||
- `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`
|
||||
|
||||
Immediate follow-up recommendation:
|
||||
|
||||
- Continue with `TASK-176-add-stats-player-comparison-cards`, using the new Stats validation script as the regression guard for the existing Stats surface.
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
id: TASK-176-add-stats-player-comparison-cards
|
||||
title: Add stats player comparison cards
|
||||
status: pending
|
||||
status: done
|
||||
type: frontend
|
||||
team: Frontend Senior
|
||||
supporting_teams:
|
||||
@@ -71,5 +71,54 @@ The Stats page already exposes player lookup and detail payloads. This task shou
|
||||
|
||||
## Outcome
|
||||
|
||||
Document which comparison cards were added, payload fields consumed, behavior with no data, and any remaining follow-up improvements.
|
||||
Implemented comparison cards:
|
||||
|
||||
- Added a dedicated comparison-card grid inside the selected-player profile panel.
|
||||
- Added weekly and monthly window cards using only existing profile payload fields.
|
||||
- Added a comparison card that contrasts weekly vs monthly KPM, K/D, kills delta, and matches delta.
|
||||
|
||||
Payload fields consumed:
|
||||
|
||||
- `player_id`
|
||||
- `player_name`
|
||||
- `matches_considered`
|
||||
- `kills`
|
||||
- `deaths`
|
||||
- `teamkills`
|
||||
- `kd_ratio`
|
||||
- `kills_per_match`
|
||||
- `deaths_per_match`
|
||||
- `weekly_ranking`
|
||||
- `monthly_ranking`
|
||||
- `window_kind`
|
||||
- `window_start`
|
||||
- `window_end`
|
||||
|
||||
Behavior with no data or limited ranking:
|
||||
|
||||
- If both weekly and monthly windows have zero matches, the existing warning state remains and the comparison cards show explicit "Sin actividad" messaging.
|
||||
- If a ranking block is absent, the cards show `Ranking ausente`.
|
||||
- If a ranking exists but `ranking_position` is empty and the active window is a fallback `previous-*` window, the cards show `Profundidad insuficiente`.
|
||||
- If a ranking exists but the player is not positioned in the visible ranking, the cards show `Fuera del ranking visible`.
|
||||
|
||||
Implementation notes:
|
||||
|
||||
- The frontend now fetches the existing player profile endpoint twice in parallel, once for `weekly` and once for `monthly`, without adding endpoints or changing backend contracts.
|
||||
- The tactical visual style stays within the current Stats surface and reuses the existing palette and panel language.
|
||||
|
||||
Validation run:
|
||||
|
||||
- `node --check frontend/assets/js/stats.js`
|
||||
- `powershell -ExecutionPolicy Bypass -File scripts/run-integration-tests.ps1`
|
||||
- Local static server:
|
||||
- `http://127.0.0.1:8091/stats.html` -> 200
|
||||
- `http://127.0.0.1:8091/assets/js/stats.js` -> 200
|
||||
|
||||
Known limitations:
|
||||
|
||||
- Visual validation against a live local backend was not possible because `http://127.0.0.1:8000` was unavailable during this task.
|
||||
- The Browser plugin surface was not available as `iab` in this session, so browser-level visual inspection could not be completed through the in-app browser.
|
||||
|
||||
Immediate follow-up improvements:
|
||||
|
||||
- Continue with `TASK-177-harden-annual-ranking-snapshot-operations` so the annual ranking endpoint behavior around effective limits and missing years is better defined and easier for the Stats UI to explain.
|
||||
@@ -1,7 +1,7 @@
|
||||
---
|
||||
id: TASK-177-harden-annual-ranking-snapshot-operations
|
||||
title: Harden annual ranking snapshot operations
|
||||
status: pending
|
||||
status: done
|
||||
type: backend
|
||||
team: Backend Senior
|
||||
supporting_teams:
|
||||
@@ -74,5 +74,45 @@ The annual snapshot flow is implemented and documented, but edge cases around mi
|
||||
|
||||
## Outcome
|
||||
|
||||
Document applied hardening, validated responses, known limits, and whether a future task is needed for scheduled/hardening automation.
|
||||
Applied hardening:
|
||||
|
||||
- Added explicit annual year normalization in `backend/app/rcon_annual_rankings.py` for supported `1..9999` values.
|
||||
- Added reusable limit normalization in the annual snapshot reader/generator with a bounded cap of `100`.
|
||||
- Added response metadata for annual snapshot reads:
|
||||
- `requested_limit`
|
||||
- `effective_limit`
|
||||
- `snapshot_limit`
|
||||
- `item_count`
|
||||
- Hardened effective-limit resolution so a ready snapshot serves no more rows than:
|
||||
- the requested limit,
|
||||
- the persisted snapshot limit,
|
||||
- and the actual stored item count.
|
||||
- Wrapped the annual route payload build in a `ValueError` guard so invalid annual requests return controlled `400` payloads.
|
||||
|
||||
Documentation updated:
|
||||
|
||||
- `docs/annual-ranking-snapshot-runbook.md` now documents annual limit metadata and explains why `effective_limit` can be lower than `requested_limit` for ready snapshots.
|
||||
|
||||
Validated responses:
|
||||
|
||||
- current year with `metric=kills` -> `200`
|
||||
- past year with no guaranteed data -> controlled `200` with `ready` or `missing` depending on stored snapshot presence
|
||||
- future year without snapshot -> `200` with `snapshot_status="missing"`
|
||||
- unsupported metric -> `400`
|
||||
- low limit `3` -> `200`, `requested_limit=3`, `effective_limit<=3`
|
||||
- high limit `101` -> `400`
|
||||
- unsupported year `10000` -> `400`
|
||||
|
||||
Validation run:
|
||||
|
||||
- Inline Python route validation for the annual endpoint cases above
|
||||
- `powershell -ExecutionPolicy Bypass -File scripts/run-integration-tests.ps1`
|
||||
|
||||
Known limits:
|
||||
|
||||
- The API still keeps `limit` aligned with the served effective limit for ready snapshots so current frontend behavior remains unchanged.
|
||||
- This task does not add scheduling or regeneration automation; it only hardens the existing read/generate contract.
|
||||
|
||||
Future task recommendation:
|
||||
|
||||
- If operations need stronger guarantees, create a follow-up task for scheduled annual snapshot generation/audit reporting rather than broadening this read-path hardening further.
|
||||
Reference in New Issue
Block a user