[New] Engagement: Per-user leaderboards are all-time only — no weekly/monthly period scoping (except a lone weekly credits view)

Area: Engagement (audit p9) · Surface: /stats (#leaderboards), /leaderboard, StatsController · Dimension: competitor-gap · Severity: major

Skool's leaderboard is its signature engagement surface and offers 7-day / 30-day / all-time tabs precisely so newcomers can rank without competing against year-old accounts. All-time-only leaderboards calcify: the same veterans sit at the top forever, new members see no path to the board and disengage. We have the data and a per-snapshot cache layer already; we just never parameterize the window for posts/karma/achievements/uploads. Adding 7d/30d/all-time tabs to the existing leaderboards is a high-leverage, low-risk change.

Evidence

Every per-user leaderboard in StatsController::buildStatsSnapshot() is all-time: topPosters/topThreaders/topKarma/topAchievers etc. are GROUP BY u.id ORDER BY COUNT(...) with no date filter (StatsController.php:138-205). /leaderboard redirects to /stats#leaderboards (LeaderboardController.php:8). The only time-bounded leaderboard in the whole area is weeklyLeaderboard() — and it is credits-only and 7-day-only (StatsController.php:680-713). The leaderboard template has a single hardcoded 'This Week's Earners' link, no 7d/30d/all-time toggle (templates/stats/leaderboard.php:14).

Suggested fix. Parameterize the leaderboard queries with a period filter (7d/30d/all) driven by a tab on /stats#leaderboards and the standalone /leaderboard page, caching one snapshot per (metric, period). Reuse the existing filesystem snapshot pattern.

Filed by the automated tenant-app audit and adversarially evidence-verified. Status: verified. Open — not yet actioned.