[DASH-05] Show dashboard baseline requirements and action - #2390
Conversation
|
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. |
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
|
🤖 Review skipped: Repository rate limit exceeded. Free accounts are limited to 2 reviews per 4 hours per repository. Upgrade to a paid plan for unlimited reviews. |
Reviewer's GuideThis PR introduces a shared, server‑authored baseline progress contract, wires baseline processing status and observed‑day counts into health status computation, and surfaces baseline requirements/progress/action consistently across server, web dashboard, and mobile recovery cards, including a new resting‑heart‑rate trend label that respects baseline blockers. Sequence diagram for baseline progress propagation to dashboardsequenceDiagram
actor User
participant WebDashboard
participant dailyMetricsRouter
participant DailyMetricsRepository
participant ProcessingRepository
participant BaselineProgressService as baseline_progress_ts
User->>WebDashboard: load Dashboard
WebDashboard->>dailyMetricsRouter: dailyMetrics.trends
dailyMetricsRouter->>DailyMetricsRepository: getTrends
dailyMetricsRouter->>ProcessingRepository: status({ datasets: ["recovery"] })
ProcessingRepository-->>dailyMetricsRouter: processingSnapshot
DailyMetricsRepository-->>dailyMetricsRouter: trends
dailyMetricsRouter->>BaselineProgressService: baselineProcessingStatus(processingSnapshot, "recovery")
dailyMetricsRouter->>BaselineProgressService: buildDailyMetricHealthStatuses(trends, baselineRelative, processingStatus)
BaselineProgressService-->>dailyMetricsRouter: healthStatus(with baselineProgress)
dailyMetricsRouter->>BaselineProgressService: buildRestingHeartRateTrendLabel({ latest, average, baselineProgress })
BaselineProgressService-->>dailyMetricsRouter: restingHeartRateTrendLabel
dailyMetricsRouter-->>WebDashboard: { trends, healthStatus, restingHeartRateTrendLabel }
WebDashboard->>DashboardEvidenceOverview: render trend with restingHeartRateBaselineProgress
WebDashboard->>HealthStatusBar: render metrics with baselineProgress
File-Level Changes
Assessment against linked issues
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
|
Warning Review limit reached
Next review available in: 40 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 (2)
📝 WalkthroughWalkthroughThe PR adds server-calculated baseline progress and processing states to health-status metrics. It exposes sample counts and resting-heart-rate trend labels, then renders requirements, progress, summaries, and actions in web and mobile dashboards. ChangesBaseline progress reporting
Estimated code review effort: 4 (Complex) | ~60 minutes Assessment against linked issues
Possibly related PRs
Suggested labels: 🚥 Pre-merge checks | ✅ 1 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (1 passed)
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 |
Mobile PreviewScan to open on device:
To test on device:
|
|
Storybook previews for This comment updates automatically on each PR push. |
PR Summary by QodoShow baseline progress requirements and actions in dashboard + mobile cards
AI Description
Diagram
High-Level Assessment
Files changed (28)
|
Code Review by Qodo
Context used✅ Compliance rules (platform):
194 rules✅ Skills:
fix-provider, write-tests, cloudflare 1.
|
![qodo-code-review[bot]](https://avatars.githubusercontent.com/in/484649?s=60&v=4){kind=small}
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 6
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
packages/web/src/pages/Dashboard.test.tsx (1)
499-530: 📐 Maintainability & Code Quality | 🟡 Minor | ⚡ Quick winAssert the new overview contract.
The fixture supplies
restingHeartRateTrendLabel, but the assertion does not verify thatDashboardforwards it. Add a resting-heart-ratehealthStatusfixture withbaselineProgress, then assert bothtrend.restingHeartRateTrendLabelandtrend.restingHeartRateBaselineProgress.As per coding guidelines, “changed behavior must have tests rather than being dismissed as pre-existing.”
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/web/src/pages/Dashboard.test.tsx` around lines 499 - 530, Update the Dashboard test’s health-status fixture to include a resting-heart-rate entry with baselineProgress, then extend the mockDashboardEvidenceOverview assertion to verify trend.restingHeartRateTrendLabel and trend.restingHeartRateBaselineProgress are forwarded from Dashboard.Source: Coding guidelines
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@packages/server/src/repositories/daily-metrics-repository.ts`:
- Around line 251-256: Update the sample_count_resting_hr aggregation in the
daily metrics query to count only resting_hr values greater than zero, using the
query’s conditional-count mechanism. Leave the other sample-count aggregations
unchanged.
In `@packages/server/src/services/health-status.test.ts`:
- Around line 137-161: Expand the recovery-processing regression coverage across
all four sites: in packages/server/src/services/health-status.test.ts:137-161,
add syncing and sync_error cases to buildHealthStatusFromSummary and assert each
expected blocker, summary, and action; in
packages/server/src/routers/daily-metrics.test.ts:37-46, make the processing
mock configurable and verify non-ready recovery status appears in returned
resting-heart-rate baselineProgress; in
packages/server/src/routers/mobile-dashboard.test.ts:154-163, verify the
normalized non-ready status is passed to loadMobileRecoveryTab; and in
packages/server/src/services/mobile-recovery-tab.test.ts:588-605, pass non-ready
status through the test context and assert every health-status builder receives
it.
In `@packages/server/src/services/mobile-recovery-tab.ts`:
- Around line 264-270: Update the label passed by buildHealthStatusFromValues
for the spo2 metric from the acronym-only text to “Blood Oxygen Saturation
(SpO2)”, preserving the existing metric, values, intent, and processingStatus.
In `@packages/web/src/components/DashboardEvidenceOverview.test.tsx`:
- Around line 16-30: Add null and undefined test cases for
restingHeartRateTrendLabel in the trendPositionLabel tests, using the existing
heart-rate inputs and expecting "Waiting for baseline". Ensure the tests cover
the fallback behavior when the optional label is absent.
In `@packages/web/src/components/HealthStatusBar.stories.tsx`:
- Around line 21-29: Add blocked-baseline Storybook coverage in
packages/web/src/components/HealthStatusBar.stories.tsx at lines 21-29 by
setting baselineProgress.blocker to a non-null value and providing visible
requirement, progress, summary, and action content. Also update
packages/web/src/components/DashboardEvidenceOverview.stories.tsx at line 26 so
restingHeartRateBaselineProgress.blocker is set and its baseline-progress
content is visible.
In `@packages/web/src/components/HealthStatusBar.test.tsx`:
- Around line 20-28: Add a blocked baseline-progress fixture in the
HealthStatusBar tests with a non-null blocker, then assert the rendered
requirement, observed/required day count, summary, and action for that state.
Keep the existing ready-state fixture and assertions unchanged, and target the
baselineProgress test setup and assertions covering the HealthStatusBar blocked
section.
---
Outside diff comments:
In `@packages/web/src/pages/Dashboard.test.tsx`:
- Around line 499-530: Update the Dashboard test’s health-status fixture to
include a resting-heart-rate entry with baselineProgress, then extend the
mockDashboardEvidenceOverview assertion to verify
trend.restingHeartRateTrendLabel and trend.restingHeartRateBaselineProgress are
forwarded from Dashboard.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 82930678-53aa-41bf-a3bb-d09c59af46e3
📒 Files selected for processing (28)
packages/mobile/components/HealthStatusCards.stories.tsxpackages/mobile/components/HealthStatusCards.test.tsxpackages/mobile/components/HealthStatusCards.tsxpackages/server/src/contracts/mobile-dashboard-contracts.tspackages/server/src/repositories/daily-metrics-repository.test.tspackages/server/src/repositories/daily-metrics-repository.tspackages/server/src/routers/body-analytics.tspackages/server/src/routers/daily-metrics.integration.test.tspackages/server/src/routers/daily-metrics.test.tspackages/server/src/routers/daily-metrics.tspackages/server/src/routers/mobile-dashboard.test.tspackages/server/src/routers/mobile-dashboard.tspackages/server/src/services/baseline-progress.test.tspackages/server/src/services/baseline-progress.tspackages/server/src/services/health-status.test.tspackages/server/src/services/health-status.tspackages/server/src/services/mobile-recovery-tab.test.tspackages/server/src/services/mobile-recovery-tab.tspackages/web/src/components/DashboardEvidenceOverview.stories.tsxpackages/web/src/components/DashboardEvidenceOverview.test.tsxpackages/web/src/components/DashboardEvidenceOverview.tsxpackages/web/src/components/HealthStatusBar.stories.tsxpackages/web/src/components/HealthStatusBar.test.tsxpackages/web/src/components/HealthStatusBar.tsxpackages/web/src/lib/healthStatus.test.tspackages/web/src/lib/healthStatus.tspackages/web/src/pages/Dashboard.test.tsxpackages/web/src/pages/Dashboard.tsx
|
🤖 Review skipped: Repository rate limit exceeded. Free accounts are limited to 2 reviews per 4 hours per repository. Upgrade to a paid plan for unlimited reviews. |
# Conflicts: # packages/mobile/components/HealthStatusCards.tsx # packages/server/src/contracts/mobile-dashboard-contracts.ts # packages/server/src/services/health-status.test.ts # packages/server/src/services/health-status.ts # packages/web/src/lib/healthStatus.test.ts # packages/web/src/lib/healthStatus.ts
|
🤖 Review skipped: Repository rate limit exceeded. Free accounts are limited to 2 reviews per 4 hours per repository. Upgrade to a paid plan for unlimited reviews. |
|
🤖 Review skipped: Repository rate limit exceeded. Free accounts are limited to 2 reviews per 4 hours per repository. Upgrade to a paid plan for unlimited reviews. |
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (3)
packages/web/src/pages/Dashboard.test.tsx (1)
499-499: 🎯 Functional Correctness | 🟡 Minor | ⚡ Quick winAssert forwarding of
restingHeartRateTrendLabel.The fixture supplies
"below average", but the assertion at Line 518 does not verify thatDashboardpasses it toDashboardEvidenceOverview. AddrestingHeartRateTrendLabel: "below average"to the expectedtrendobject.As per coding guidelines, “changed behavior must have tests rather than being dismissed as pre-existing.”
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/web/src/pages/Dashboard.test.tsx` at line 499, Update the Dashboard test’s expected trend object in the DashboardEvidenceOverview assertion to include restingHeartRateTrendLabel: "below average", matching the fixture and verifying Dashboard forwards the value.Source: Coding guidelines
packages/server/src/services/mobile-recovery-tab.ts (1)
251-257: 🎯 Functional Correctness | 🟠 Major | ⚡ Quick winExclude non-positive fallback resting-heart-rate values.
buildHealthStatusFromValues()accepts every finite value. WhenbaselineRelativehas no resting-heart-rate metric, Line 254 forwards0and negativeresting_hrvalues.DailyMetricsRepository.getTrends()treats onlyresting_hr > 0as valid.This fallback can display an invalid rate, overstate
observedObservationDays, and complete a baseline prematurely. Filter fallback values withresting_hr > 0. Add a regression case with zero, negative, and positive values.Proposed fix
- values: hrvBaseline.flatMap((row) => (row.resting_hr == null ? [] : [row.resting_hr])), + values: hrvBaseline.flatMap((row) => + row.resting_hr != null && row.resting_hr > 0 ? [row.resting_hr] : [], + ),As per coding guidelines, “Write tests first; bug fixes require a failing regression test before implementation, and changed behavior must have tests.”
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/server/src/services/mobile-recovery-tab.ts` around lines 251 - 257, Update the fallback values construction in the health-status flow around buildHealthStatusFromValues to include only resting_hr values greater than zero, matching DailyMetricsRepository.getTrends validation. Add a regression test covering zero, negative, and positive fallback values, verifying only the positive value contributes to the status and observation-day calculations.Source: Coding guidelines
packages/mobile/components/HealthStatusCards.stories.tsx (1)
132-164: 🩺 Stability & Availability | 🔴 Critical | ⚡ Quick winAdd
baselineProgressto both story metrics.
HealthStatusMetricrequiresbaselineProgress. The consumer inpackages/mobile/components/HealthStatusCards.tsxreadsmetric.baselineProgress.blockerat Line 77. Without this field, the story can fail type checking and throw when Storybook renders it.Add
baselineProgress: readyBaselineProgressto both the HRV and Steps objects.Proposed fixture fix
explanation: "Heart Rate Variability (HRV) is above your baseline.", + baselineProgress: readyBaselineProgress, }, @@ explanation: "Steps is close to your usual range.", + baselineProgress: readyBaselineProgress, },🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/mobile/components/HealthStatusCards.stories.tsx` around lines 132 - 164, Update both the HRV and Steps metric objects in the story fixture to include baselineProgress: readyBaselineProgress, matching the required HealthStatusMetric shape and the consumer in HealthStatusCards. Leave the existing metric values unchanged.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In `@packages/mobile/components/HealthStatusCards.stories.tsx`:
- Around line 132-164: Update both the HRV and Steps metric objects in the story
fixture to include baselineProgress: readyBaselineProgress, matching the
required HealthStatusMetric shape and the consumer in HealthStatusCards. Leave
the existing metric values unchanged.
In `@packages/server/src/services/mobile-recovery-tab.ts`:
- Around line 251-257: Update the fallback values construction in the
health-status flow around buildHealthStatusFromValues to include only resting_hr
values greater than zero, matching DailyMetricsRepository.getTrends validation.
Add a regression test covering zero, negative, and positive fallback values,
verifying only the positive value contributes to the status and observation-day
calculations.
In `@packages/web/src/pages/Dashboard.test.tsx`:
- Line 499: Update the Dashboard test’s expected trend object in the
DashboardEvidenceOverview assertion to include restingHeartRateTrendLabel:
"below average", matching the fixture and verifying Dashboard forwards the
value.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 850074a0-70d4-4a0e-a3c0-461e96b643fd
📒 Files selected for processing (24)
packages/mobile/components/HealthStatusCards.stories.tsxpackages/mobile/components/HealthStatusCards.test.tsxpackages/mobile/components/HealthStatusCards.tsxpackages/server/src/contracts/mobile-dashboard-contracts.tspackages/server/src/repositories/daily-metrics-repository.tspackages/server/src/routers/daily-metrics.integration.test.tspackages/server/src/routers/daily-metrics.test.tspackages/server/src/routers/daily-metrics.tspackages/server/src/routers/mobile-dashboard.test.tspackages/server/src/routers/router-sql.integration.test.tspackages/server/src/services/baseline-progress.test.tspackages/server/src/services/baseline-progress.tspackages/server/src/services/health-status.test.tspackages/server/src/services/health-status.tspackages/server/src/services/mobile-recovery-tab.test.tspackages/server/src/services/mobile-recovery-tab.tspackages/web/src/components/DashboardEvidenceOverview.stories.tsxpackages/web/src/components/DashboardEvidenceOverview.test.tsxpackages/web/src/components/HealthStatusBar.stories.tsxpackages/web/src/components/HealthStatusBar.test.tsxpackages/web/src/components/HealthStatusBar.tsxpackages/web/src/pages/Dashboard.test.tsxpackages/web/src/pages/Dashboard.tsxsrc/db/schema/core.ts
|
LGTM! 🚀 Summary of Review
🤖 Reviewed by codereviewbot.ai - Catch bugs before your team does. |
Summary
origin/mainatcf3ca9d7d(#2110).Tests
pnpm test— 1,022 files passed; 15,634 tests passed; 2 files and 21 tests skipped by the repository suite.pnpm tsc --noEmit— passed.pnpm test:integration— blocked before tests because Docker could not createissue-2107_default: all predefined address pools are fully subnetted.pnpm lint— code and policy stages passed; analytics SQL lint was blocked because ClickHouse at127.0.0.1:61874was unavailable.Closes #2107
Summary by CodeRabbit
New Features
Bug Fixes