Clarify landing preview metrics

[Asherlc]

Summary

• label the landing dashboard as a fixed illustrative example with coherent dates and values
• add comparison, coverage, source, limitation, and next-action context to each preview insight
• expose chart axes, units, time endpoints, and accessible chart names
• add regression coverage and an illustrative Storybook story

Validation

• pnpm --filter dofek-web exec vitest run src/pages/LandingPage.test.tsx
• pnpm --filter dofek-web exec tsc --noEmit
• pnpm --filter dofek-web build-storybook
• pnpm lint
• pnpm tsc --noEmit
• cd packages/server && pnpm tsc --noEmit
• pnpm test
• desktop/mobile, light/dark Storybook visual and accessibility audit

Fixes #2093

Summary by Sourcery

Clarify the landing page product preview with concrete, labeled example metrics and accessible chart context.

New Features:

• Add explicit chart axes, tick labels, units, and accessible names to preview scatter and line charts.
• Introduce an illustrative decision-focused Storybook story for the landing page preview.

Enhancements:

• Update landing overview and daily summary to use coherent, example-based date ranges and metric values that demonstrate typical analysis.
• Augment correlation, trend, comparison, and health monitor panels with coverage, source, confidence, and next-action text to better explain insights.

Tests:

• Expand LandingPage tests to validate example values, explanatory context, and accessibility metadata for preview charts.

---

Summary by cubic

Clarifies the landing-page preview with a fixed, illustrative example and accessible, labeled charts, while centralizing chart rendering and metric formatting for consistent units. Fixes #2093.

• New Features
  • Marked the dashboard as “Illustrative example” with coherent dates (“Apr 28–May 27, 2026”) and “May 27, 2026 · Example data”; filled the daily summary with concrete values (Recovery 74%, Strain 8.6, Sleep 7h 42m, 96% of need).
  • Introduced reusable LandingPreviewScatterPlot and LandingPreviewLineChart components with axis labels, tick labels, units, time endpoints, and accessible names; updated the landing page to use them.
  • Added clearer insight context: correlation values (e.g., r = 0.72 with 24/30 days; r = -0.46 with 22/30), sources, confidence, and “Next” actions for each panel.
  • Formatted metrics via the unit system for consistent labels (e.g., 52 bpm average, 68 ms HRV, 98% SpO2) and removed ambiguous copy.
  • Added stories for the landing preview and chart components, and tests covering example values, units, labeled axes, and accessibility.

^{Written for commit ea0cb93. Summary will update on new commits.}

[codereviewbot-ai]

🤖 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.

[cursor]

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.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

[sourcery-ai]

Sorry @Asherlc, you have reached your weekly rate limit of 500000 diff characters.

Please try again later or upgrade to continue using Sourcery

[coderabbitai]

Warning

Review limit reached

@Asherlc, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 33 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

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 configuration

Configuration used: Path: .coderabbit.yaml

Review profile: ASSERTIVE

Plan: Pro Plus

Run ID: 91ba4503-01cb-4177-b826-4c96c1168183

📥 Commits

Reviewing files that changed from the base of the PR and between d644426 and ea0cb93.

📒 Files selected for processing (6)

• packages/web/src/components/LandingPreviewCharts.stories.tsx
• packages/web/src/components/LandingPreviewCharts.test.tsx
• packages/web/src/components/LandingPreviewCharts.tsx
• packages/web/src/pages/LandingPage.stories.tsx
• packages/web/src/pages/LandingPage.test.tsx
• packages/web/src/pages/LandingPage.tsx

---

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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[sourcery-ai]

Reviewer's Guide

Clarifies that the landing page preview shows fixed example data, enriches each insight panel with comparison/coverage/source/confidence/next-action context, and refactors the chart components to be accessible with labeled axes, units, and time ranges, backed by updated tests and a new Storybook story.

File-Level Changes

Change	Details	Files
Clarified landing overview and daily summary as fixed illustrative examples with coherent dates and values.	Labeled the overview preview as an illustrative example and updated its date range to a concrete future interval. Replaced placeholder daily summary ring values and captions with realistic recovery, strain, and sleep metrics. Changed the daily summary date display to a fixed example date with an explicit "Example data" suffix. Removed runtime date formatting dependency now that preview dates are static.	packages/web/src/pages/LandingPage.tsx packages/web/src/pages/LandingPage.test.tsx
Enriched correlation, trend, comparison, and health monitor panels with comparison, coverage, source, confidence, and next-action context.	Updated correlation and comparison cards to show explicit r-values, strength labels, paired-day counts, and descriptive next actions. Added coverage and confidence text blocks (e.g., moderate vs low confidence, descriptive vs causal) under correlation/comparison panels. Expanded the resting heart rate trend panel with a comparison vs prior days, coverage count, source, confidence, and suggested follow-up actions. Annotated the health monitor preview with example source systems and coverage information.	packages/web/src/pages/LandingPage.tsx packages/web/src/pages/LandingPage.test.tsx
Refactored scatter and line chart previews to expose accessible names, axes, units, tick labels, and time endpoints.	Extended the ScatterPlot component to accept accessibleName, axis labels, and tick labels props, and rendered labeled axes and ticks inside the SVG. Adjusted ScatterPlot geometry/margins so points align with new axes while remaining visually coherent. Extended the LineChart component to accept an accessible name, draw axes and value ticks, and render labeled time endpoints beneath the chart. Updated all chart usages in the landing page preview to pass appropriate accessible names, axes, units, and time ranges. Added tests asserting ARIA img roles, accessible names, axis labels, units, and time endpoints for the preview charts.	packages/web/src/pages/LandingPage.tsx packages/web/src/pages/LandingPage.test.tsx
Added an illustrative Storybook story showcasing the clarified decision preview context.	Introduced a new IllustrativeDecisionPreview story variant for the LandingPage component. Documented that the story demonstrates comparison, coverage, source, limitations, actions, and labeled chart context in the landing preview.	packages/web/src/pages/LandingPage.stories.tsx

Assessment against linked issues

Issue	Objective	Addressed	Explanation
#2093	Provide clear chart context on the landing page previews, including axes, units, time endpoints, coverage, and accessible chart names.	✅
#2093	Replace decorative or misleading preview data (e.g., 'No data' beside polished charts) with coherent example metrics and explicit example labeling and coverage.	✅
#2093	Demonstrate the decision grammar in landing preview insights: value, comparison, confidence, source, and next action.	✅

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[qodo-code-review]

PR Summary by Qodo

Clarify landing-page preview metrics with labeled examples and accessible charts

✨ Enhancement 🧪 Tests 🕐 40+ Minutes

AI Description

• Mark the landing dashboard preview as an illustrative example with coherent dates and values.
• Add comparison/coverage/source/confidence/next-action context across preview insight panels.
• Make preview charts accessible with axis labels, units, tick labels, and time endpoints.

Diagram

graph TD
  STORY["LandingPage.stories.tsx"] --> LP["LandingPage.tsx"] --> PANELS["Preview panels"] --> SP["ScatterPlot (SVG)"]
  PANELS --> LC["LineChart (SVG)"]
  PANELS --> CTX["Example insight context"]
  TESTS["LandingPage.test.tsx"] --> LP

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Extract preview fixtures into a shared data module

• ➕ Single source of truth for example dates/values/copy across component, tests, and Storybook
• ➕ Easier to update without chasing string literals in multiple places
• ➖ Adds indirection; readers must jump files to understand the preview output
• ➖ May encourage over-engineering for a purely illustrative section

2. Reuse the app’s real chart components in preview mode

• ➕ Higher fidelity to production visuals and accessibility patterns
• ➕ Avoids maintaining bespoke SVG rendering/labeling logic
• ➖ May require more dependencies/data plumbing for a marketing/preview surface
• ➖ Harder to keep deterministic and lightweight for tests/Storybook

3. Use SVG / + aria-labelledby instead of long aria-label strings

• ➕ More semantically aligned with SVG accessibility best practices
• ➕ Keeps the accessible name content structured rather than one long string
• ➖ More verbose markup; requires careful ID management to avoid collisions
• ➖ Tests need to query title/desc semantics instead of role+name alone

Recommendation: The current approach is appropriate for a deterministic, illustrative landing preview and keeps the a11y contract testable. If the example content is expected to evolve frequently, consider extracting the example fixtures (values + explanatory strings) into a shared module to reduce duplication between LandingPage, tests, and Storybook.

Files changed (3) +212 / -50

Enhancement (1) +139 / -49

LandingPage.tsxMake landing preview metrics coherent, contextual, and accessible +139/-49

Make landing preview metrics coherent, contextual, and accessible

• Replaces placeholder preview values with a coherent, explicitly-labeled illustrative dataset (fixed date range, daily summary rings, health monitor values). Enhances correlation/trend/comparison panels with coverage, sources, confidence/limitations, and next-action guidance; updates charts to expose axis labels, tick labels, and accessible names by refactoring ScatterPlot/LineChart to accept these props and render labeled SVGs.

packages/web/src/pages/LandingPage.tsx

Tests (1) +61 / -1

LandingPage.test.tsxExpand landing preview tests for example metrics and chart accessibility +61/-1

Expand landing preview tests for example metrics and chart accessibility

• Extends the product preview test to assert the new "Illustrative example" labeling, fixed example date/value outputs, and removal of "No data" placeholders. Adds new tests covering insight context (coverage/source/confidence/next actions) and verifying accessible chart names plus axis/unit/time labels.

packages/web/src/pages/LandingPage.test.tsx

Documentation (1) +12 / -0

LandingPage.stories.tsxAdd Storybook story for decision-focused illustrative preview +12/-0

Add Storybook story for decision-focused illustrative preview

• Introduces a dedicated Storybook story that frames the landing page preview as an illustrative decision example. Adds doc text describing the added comparison/coverage/source/limitation/action and chart labeling context.

packages/web/src/pages/LandingPage.stories.tsx

[github-actions]

Storybook previews for cf0c85b8 are ready:

• Web Storybook
• Mobile Storybook

This comment updates automatically on each PR push.

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (0) 📜 Skill insights (0)

Context used

✅ Compliance rules (platform): 159 rules

✅ Skills: fix-provider, write-tests, cloudflare

1. HRV not expanded in copy ✓ Resolved 📘 Rule violation ☑ Accessibility

Description

The new user-facing chart context text includes the acronym HRV without an expansion, which can be
unclear to users. Update the label to spell out the term (optionally keeping the acronym in
parentheses).

Code

packages/web/src/pages/LandingPage.tsx[370]

+        <p>Example sources: Oura sleep + Apple Health HRV</p>

Relevance

●●● Strong

Repo has accepted expanding acronyms in user-facing copy to meet accessibility/compliance guidance.

PR-#2236

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance ID 773517 requires acronyms in user-facing chart text to be expanded in the same
label. The added string Example sources: Oura sleep + Apple Health HRV uses HRV without
expansion.

Rule 773517: Avoid unexplained acronyms in user-facing chart text
packages/web/src/pages/LandingPage.tsx[369-372]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
User-facing chart copy includes an unexplained acronym (`HRV`).

## Issue Context
Compliance requires acronyms in chart text to be expanded (e.g., `Heart rate variability (HRV)`) unless they are standard units.

## Fix Focus Areas
- packages/web/src/pages/LandingPage.tsx[369-372]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. Hardcoded bpm/ms labels ✓ Resolved 📘 Rule violation ⚙ Maintainability

Description

New user-facing chart labels/accessible names and a health monitor preview metric hardcode unit
strings (e.g., %, ms, bpm, including 52 bpm) directly in string literals instead of sourcing
them from the shared unit formatting/i18n mechanism (e.g., useUnitConverter). This bypasses the
centralized formatting path, risks inconsistent unit labeling, and makes future localization harder.

Code

packages/web/src/pages/LandingPage.tsx[R361-367]

+        <ScatterPlot
+          accessibleName="Example correlation scatter plot. X-axis: Sleep consistency (%). Y-axis: Heart rate variability (ms)."
+          xAxisLabel="Sleep consistency (%)"
+          xTickLabels={["70", "100"]}
+          yAxisLabel="Heart rate variability (ms)"
+          yTickLabels={["45", "85"]}
+        />

Relevance

●●● Strong

Prior reviews accepted moving hardcoded unit strings to shared formatting/expanded labels.

PR-#1123

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance IDs 722048 and 722094 require that user-facing unit text and numeric+unit measurements
be produced via the shared unit formatting/i18n mechanism rather than embedded in literals. The
cited LandingPage code includes newly added chart axis labels and aria-label text containing unit
markers like %, ms, and bpm directly in string literals, and the HealthMonitorPreview
metrics array includes a manually formatted 52 bpm string literal, demonstrating the formatting is
being bypassed.

Rule 722048: Centralize user-facing unit strings in a shared formatter or i18n layer
Rule 722094: Use shared unit formatting hooks/contexts for all user-facing measurements
packages/web/src/pages/LandingPage.tsx[361-367]
packages/web/src/pages/LandingPage.tsx[563-590]
packages/web/src/pages/LandingPage.tsx[443-452]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Chart axis labels, chart `aria-label` text, and a health monitor preview metric currently hardcode unit strings (e.g., `bpm`, `ms`, `%`, including `52 bpm`) in string literals instead of using the shared unit formatting/i18n mechanism (e.g., `useUnitConverter`).

## Issue Context
Compliance requires user-facing unit text and numeric+unit UI measurements to be produced through the centralized unit formatting path so unit labels remain consistent, unit-system behavior is respected, and localization is feasible. The codebase already uses `useUnitConverter()` for canonical unit labels (e.g., `units.percentageLabel`) and measurement formatting in other components, so these Landing page preview/chart strings should pull unit labels/formatting from the same shared source to avoid drift.

## Fix Focus Areas
- packages/web/src/pages/LandingPage.tsx[361-367]
- packages/web/src/pages/LandingPage.tsx[443-452]
- packages/web/src/pages/LandingPage.tsx[563-590]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. LandingPage.tsx over 1000 lines ✓ Resolved 📘 Rule violation ⚙ Maintainability

Description

packages/web/src/pages/LandingPage.tsx is now 1032 lines long, exceeding the 1000-line TypeScript
file limit. This increases maintenance risk and should be addressed by splitting the page into
smaller modules/components.

Code

packages/web/src/pages/LandingPage.tsx[R283-288]

+          <div className="text-[10px] font-bold uppercase tracking-[0.12em] text-accent-secondary">
+            Illustrative example
+          </div>
          <div className="text-sm font-semibold text-foreground">Overview</div>
-          <div className="text-xs text-subtle">Apr 28 - May 27</div>
+          <div className="text-xs text-subtle">Apr 28–May 27, 2026</div>
        </div>

Relevance

●●● Strong

Team previously extracted UI to keep pages under 1000-line guideline.

PR-#1871

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance ID 773521 caps TypeScript files at 1000 lines. The PR branch version of
LandingPage.tsx includes line numbers past 1000 (up to 1032), proving it exceeds the limit.

Rule 773521: Enforce a 1000-line maximum per TypeScript file
packages/web/src/pages/LandingPage.tsx[1000-1032]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
A changed TypeScript file exceeds the 1000-line limit.

## Issue Context
The compliance rule sets a hard cap of 1000 physical lines for changed .ts/.tsx files; `LandingPage.tsx` is 1032 lines.

## Fix Focus Areas
- packages/web/src/pages/LandingPage.tsx[1-1032]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

_{To customize comments, go to the Qodo configuration screen, or learn more in the docs.}

[codereviewbot-ai]

🤖 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.