feat(ui): Analytics dashboard pilot on the shared design system (U5 B2)#439
Conversation
Second B2 slice, composing the chart primitives from #438 into a generic dashboard screen that all four B2 views can reuse: - libs/ui: new AnalyticsDashboard screen — a KPI stat-tile row (each with an optional area sparkline), a column of titled line-chart cards, and an optional right rail of summary meta cards; loading/error/empty states with aria-live. Data-agnostic via new shared types UiKpi / UiChartCard, so Productivity / Merge Analytics / Model Usage can reuse it by mapping their report onto the same props. - Electron: pure analytics-ui mappers (formatCount/Percent/Cost, successRateTone, UTC shortDate, evenly-sampled axis labels, and buildKpis/buildCharts/buildSections from AnalyticsReport; 14 tests) + AnalyticsPilotView over the existing analytics.getReport IPC. Mounted as "Analytics (new UI)" beside the legacy multi-tab view. - i18n: analytics:analyticsPilot.* keys (en+fr), navigation.analyticsNext. Scope: the pilot renders the report's summary KPIs + trend charts + outcome/QA summary cards. The legacy view keeps the agent-stats and QA-issue drilldowns (dedicated tables), which are a natural part 2. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Bugbot is not enabled for your account, so this pull request was not reviewed. Enable Bugbot in the Cursor dashboard to get automatic reviews on future PRs. |
|
Warning Review limit reached
Next review available in: 36 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: ASSERTIVE Plan: Pro Plus Run ID: 📒 Files selected for processing (14)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
…440) Third B2 slice — the first to reuse the generic AnalyticsDashboard from #439 with no new libs/ui component: - Electron: pure productivity-ui mappers (formatHours; buildProductivity Kpis/Charts/Sections from ProductivitySummary + ProductivityTrend Point, reusing analytics-ui's formatters/shortDate/sampleLabels/ successRateTone; converts the backend 0-1 rates to whole percents; 7 tests) + ProductivityPilotView over getProductivitySummary + getProductivityTrends. Mounted as "Productivity (new UI)". - i18n: analytics:productivityPilot.* keys (en+fr; the productivity screens share the analytics namespace), navigation.productivityNext. Scope: the productivity mockup's categorical bar panels ("when you ship", "where the time went") have no backing data in the report, so — like the Patterns pilot — this maps only the real data: KPI summary figures + the daily trend series as line charts + outcome/effort cards. No BarChart primitive is invented for panels the backend can't fill. Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
1 participant
Summary
Second B2 slice. Composes the chart primitives from #438 into a generic
AnalyticsDashboardscreen — deliberately data-agnostic so all four B2 views (Analytics, Productivity, Merge Analytics, Model Usage) reuse it, not just Analytics.libs/ui
aria-live/role="alert".UiKpi/UiChartCarddescribe the dashboard inputs; the screen composesStatTile+Sparkline+LineChart.Electron
analytics-uimappers:formatCount/formatPercent/formatCost,successRateTone, UTCshortDate, evenly-sampled axis labels, andbuildKpis/buildCharts/buildSectionsfromAnalyticsReport— 14 tests.AnalyticsPilotViewover the existinganalytics.getReportIPC, mounted as "Analytics (new UI)" beside the legacy multi-tab view (which stays untouched).i18n
analytics:analyticsPilot.*(en+fr),navigation:items.analyticsNext.Scope
The pilot renders the report's summary KPIs + trend charts + outcome/QA summary cards. The legacy view's agent-stats and QA-issue drilldown tables are a natural part 2 (they need a dedicated table primitive not yet built).
Verification
libs/ui+ Electron tsc clean; Storybook rebuilt and the Dashboard story verified against the mockup (KPI sparklines, two-series velocity chart with legend + W-axis, single-series rate chart, Outcomes/QA rail).Next in B2
Productivity / Merge Analytics / Model Usage reuse this same
AnalyticsDashboard— mostly new mappers per screen.🤖 Generated with Claude Code