ReviewOS

stacks/wildloop

Add a ranking job to compute weekly_rank/all_time_rank (currently hardcoded 999)

#944
Closed glennmichael123 opened this 9 days ago ·
9 days ago

Problem

TerritoryStats.weekly_rank/all_time_rank are written as 999 on every claim/conquest (ClaimTerritoryAction.ts, ProcessActivityConquestAction.ts) and never recomputed. TerritoryLeaderboardAction recomputes order per-request but never persists ranks, so any per-user rank display is wrong.

Acceptance

  • A job/command recomputes weekly + all-time ranks (by area/count/conquests) and writes them to territory_stats.
  • Scheduled (cron) and runnable on demand.
9 days ago

Implemented in df62d5f.

  • Ranking math in resources/functions/ranks.ts (pure, shared): all-time ranks current holdings by area; weekly ranks area gained in the trailing 7 days from claimed/conquered history events — gains, not net worth, so the boards genuinely differ.
  • On demand: POST /api/territories/recompute-ranks (auth) via ComputeTerritoryRanksAction.
  • Always fresh: claim/conquest call recomputeTerritoryRanks() after every holdings change, so the persisted ranks can't go stale between requests (event-driven beats cron here).
  • Cron/CLI: ./buddy territory:ranks (with --dry-run), registered in app/Commands.ts — point a crontab at it as the safety net.
  • New stats rows start unranked (null) — the hardcoded 999 is gone from both write sites.

Verified by scripts/verify-territory-ranks.ts: the seeded world yields all-time You > Rival > Explorer but weekly Rival > You > Explorer (Rival gained more this week despite holding less), recompute is idempotent (0 rewrites when stable), and no 999s exist anywhere.

Sign in to comment on this issue.