feat(ui): analytics dashboard time-window selector (#2199)

[RealDiligent]

Summary

• Add 7d / 30d / 90d ToggleGroup to the /app/analytics header
• Thread the selected window through useApiResource(operatorDashboardPath(days)) so the query key re-fetches on change
• Persist the choice in local storage; restore on reload
• Backend: honor ?days= on GET /v1/app/operator-dashboard and clamp to supported windows

Closes #2199

Test plan

• npm run test --workspace=@jsonbored/gittensory-ui -- src/lib/analytics-window.test.ts (6 tests: parse, path, persistence, re-key)
• npx vitest run test/unit/operator-dashboard.test.ts (windowDays clamp + metadata)
• Rebased onto latest main

UI Evidence

Page / Feature	Before	After
/app/analytics header	before: fixed 30d window, no selector	after: 7d/30d/90d toggle drives dashboard fetch

[superagent-security]

Superagent didn't find any vulnerabilities or security issues in this PR.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 94.22%. Comparing base (eafcd35) to head (0c06486).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4747      +/-   ##
==========================================
- Coverage   94.22%   94.22%   -0.01%     
==========================================
  Files         440      440              
  Lines       38714    38720       +6     
  Branches    14103    14105       +2     
==========================================
+ Hits        36478    36483       +5     
  Misses       1576     1576              
- Partials      660      661       +1     

Files with missing lines	Coverage Δ
src/api/routes.ts	94.26% <100.00%> (+<0.01%)	⬆️
src/services/operator-dashboard.ts	100.00% <100.00%> (ø)

... and 1 file with indirect coverage changes

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[loopover-orb]

Warning

🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨🟨

⏸️ Gittensory review result - manual review recommended

_{Review updated: 2026-07-10 22:24:01 UTC}

6 files · 1 AI reviewer · no blockers · readiness 100/100 · CI green · clean

⏸️ Suggested Action - Manual Review

• Touches a guarded path — held for manual review: This PR changes guardrail-protected path(s): src/services/operator-dashboard.ts (matched src/services/**).

Review summary
This PR threads a 7/30/90-day window selector from a new ToggleGroup through useLocalStorage persistence, into the operator-dashboard fetch path, and clamps it server-side via clampOperatorDashboardWindowDays. The wiring for the primary target (usage summary, command-usefulness) is correct and well tested, but the diff also silently changes several other panels' data windows by coupling gateEval/cycleTime/fleetAnalytics/recommendationQuality to the same selector, and it does so without updating a downstream label that assumes a fixed 7-day window.

Blockers

• src/services/operator-dashboard.ts: computeGateEval and computeCycleTimeAggregate previously always used a fixed `days: 90` (per the adjacent feat(ui): gate-precision analytics card (precision + confusion matrix) #2191/feat(ui): cycle-time percentiles card (p50/p90/p99) #2194 comments, chosen for statistical stability on precision/percentile computations); this diff switches them to `days: windowDays`, whose default is 7 (DEFAULT_ANALYTICS_WINDOW_DAYS in apps/gittensory-ui/src/lib/analytics-window.ts), so every operator now sees gate-precision and cycle-time percentiles computed over 7 days by default instead of 90 unless they manually toggle to 90d — this is a real behavior regression not mentioned in the PR description and should either be reverted for these two calls or explicitly called out as intended.
• apps/gittensory-ui/src/routes/app.analytics.tsx (MCP compatibility section, untouched by this diff but fed by src/services/operator-dashboard.ts:117 `summarizeMcpCompatibilityAdoption(env, usageSince)`): usageSince is now derived from the selected windowDays instead of the previously-fixed USAGE_WINDOW_DAYS=7, but the 'MCP events'/'Active clients' Stat hints still hardcode `last 7 days` — selecting 30d or 90d will show data spanning that window under a label that still claims 7 days, a real data/label mismatch on the default render path.

Nits — 6 non-blocking

• src/services/operator-dashboard.ts:234 clampOperatorDashboardWindowDays hardcodes 7/30/90 rather than deriving from ANALYTICS_WINDOW_OPTIONS — fine for now but the two lists (UI and backend) can drift if one is edited without the other.
• No test asserts that gateEval/cycleTime/fleetAnalytics/recommendationQuality actually receive the selected windowDays (only commandUsefulness.windowDays is asserted in test/unit/operator-dashboard.test.ts) — given the default-window regression above, this gap let it through green CI.
• apps/gittensory-ui/src/routes/app.analytics.tsx: the ToggleGroup is only rendered once windowHydrated is true, causing a layout shift on first paint; consider rendering a disabled/skeleton toggle instead of omitting it entirely.
• External brief flags several new magic numbers (24/60/60 in the ms-per-day computation, 7/30/90 in clamp) — consider a shared MS_PER_DAY constant and reusing ANALYTICS_WINDOW_OPTIONS-equivalent values on the backend.
• Decouple gateEval/cycleTime from the UI window selector (keep them at a fixed 90d as before) unless product intent is to have precision/cycle-time percentiles shrink to 7 days by default — confirm which is intended.
• Touches a guarded path — held for manual review — A maintainer must review and merge this change.

Signal	Result	Evidence
Code review	✅ No blockers	1 reviewer
Linked issue	✅ Linked	#2199
Related work	✅ No active overlap found	No same-issue or scoped active PR overlap found.
Change scope	✅ 20/20	Low review scope from cached public metadata (1 linked issue).
Validation posture	✅ 25/25	PR body includes validation/test evidence.
Contributor workload	✅ 10/10	Author activity: 280 registered-repo PR(s), 120 merged, 23 issue(s).
Contributor context	✅ Confirmed Gittensor contributor	RealDiligent; Gittensor profile; 280 PR(s), 23 issue(s).
Gate result	⚠️ Not blocking	Advisory; not blocking this PR.

Review context

• Author: RealDiligent
• Role context: outside_contributor
• Public audience mode: oss maintainer
• Lane context: Repository is configured for direct PR review.
• Public profile languages: Python, JavaScript, Ruby, Svelte, TypeScript, Markdown, MDX
• Official Gittensor activity: 280 PR(s), 23 issue(s).
• PR-specific overlap: none found.

Contributor next steps

• Keep the PR focused and include validation evidence before maintainer review.

Signal definitions

• Related work = same linked issue, overlapping active PRs, or title/path similarity.
• Change scope = cached public metadata such as size labels, draft state, and review-burden hints.
• Validation posture = whether the PR provides enough public validation/test evidence for maintainer review.
• Contributor workload = public contributor activity and cleanup pressure, not a repo-wide quality failure.
• Contributor context = public GitHub/Gittensor identity context; non-Gittensor status is not a blocker.

Visual preview

Route	Viewport	Before (production)	After (this PR's preview)	Diff
/app/analytics	desktop			—
/app/analytics	mobile			—

Click any thumbnail to open the full-size screenshot. Before = production · After = this PR's preview deploy.

_{🟩 Safe / merged · 🟦 Advisory · 🟨 Held for review · 🟥 Blocked / closed}

---

💰 Earn for open-source contributions like this. Gittensor lets GitHub contributors earn for the work they already do — register to start earning →.

Checked by Gittensory, a quiet PR intelligence layer for OSS maintainers.

• Re-run Gittensory review

[loopover-orb]

An AI reviewer flagged a likely defect, but its confidence was below this repository's configured close-confidence floor, so this is held for a maintainer to confirm instead of closing automatically. Resolve the flagged defect (see the review notes), or ask a maintainer to override.

[JSONbored]

Blockers, closing:

Review summary
This PR threads a 7/30/90-day window selector from a new ToggleGroup through useLocalStorage persistence, into the operator-dashboard fetch path, and clamps it server-side via clampOperatorDashboardWindowDays. The wiring for the primary target (usage summary, command-usefulness) is correct and well tested, but the diff also silently changes several other panels' data windows by coupling gateEval/cycleTime/fleetAnalytics/recommendationQuality to the same selector, and it does so without updating a downstream label that assumes a fixed 7-day window.

Blockers

src/services/operator-dashboard.ts: computeGateEval and computeCycleTimeAggregate previously always used a fixed `days: 90` (per the adjacent https://github.com/JSONbored/gittensory/issues/2191/https://github.com/JSONbored/gittensory/issues/2194 comments, chosen for statistical stability on precision/percentile computations); this diff switches them to `days: windowDays`, whose default is 7 (DEFAULT_ANALYTICS_WINDOW_DAYS in apps/gittensory-ui/src/lib/analytics-window.ts), so every operator now sees gate-precision and cycle-time percentiles computed over 7 days by default instead of 90 unless they manually toggle to 90d — this is a real behavior regression not mentioned in the PR description and should either be reverted for these two calls or explicitly called out as intended.
apps/gittensory-ui/src/routes/app.analytics.tsx (MCP compatibility section, untouched by this diff but fed by src/services/operator-dashboard.ts:117 `summarizeMcpCompatibilityAdoption(env, usageSince)`): usageSince is now derived from the selected windowDays instead of the previously-fixed USAGE_WINDOW_DAYS=7, but the 'MCP events'/'Active clients' Stat hints still hardcode `last 7 days` — selecting 30d or 90d will show data spanning that window under a label that still claims 7 days, a real data/label mismatch on the default render path.