feat: system health summary with overall status and refresh

[kahboom]

Summary

• Aggregate individual service statuses (Fulcio, Rekor, TUF) into an overall system status: Operational, Degraded, or Down — displayed in the header with a matching PatternFly status dot and label
• Wire up the Refresh button to trigger a React Query refetch of /api/v1/systemHealth
• Add unit tests for the new getOverallStatus and overallStatusToSeverity utility functions

Feature flag

The system health page is gated behind the FEATURE_OBSERVABILITY environment variable (defaults to off). When set to on, it enables the /system-health route and adds a "System Health" entry to the sidebar navigation. The flag is read from common/src/environment.ts and consumed via the useFeatureFlags hook in client/src/app/hooks/useFeatureFlags.tsx.

Test plan

• Lint passes (0 errors)
• Full test suite passes (42 files, 430 tests)
• New utils.test.ts covers all status aggregation variants (Operational, Degraded, Down)
• Manual verification with FEATURE_OBSERVABILITY=on and MOCK=on that the header shows "Degraded" (since mock data has one unhealthy service) and Refresh button triggers re-fetch

🤖 Generated with Claude Code

Relevant Jiras: SECURESIGN-3895, SECURESIGN-3894, SECURESIGN-3890

[qodo-for-securesign]

PR Summary by Qodo

System Health page: overall status header, refresh refetch, and observability flag

✨ Enhancement 🧪 Tests ⚙️ Configuration changes 🕐 40+ Minutes

AI Description

• Add System Health page gated behind FEATURE_OBSERVABILITY and sidebar/nav routing.
• Show aggregated overall system status (Operational/Degraded/Down) with status dot in header.
• Wire Refresh button to React Query refetch of /api/v1/systemHealth and add utility tests.

Diagram

graph TD
  EnvFlag{{"FEATURE_OBSERVABILITY"}} --> Flags["FeatureFlagsProvider"] --> NavRoute["Routes + Sidebar"] --> Page["SystemHealth page"]
  Page --> Query["useFetchSystemHealth"] --> Api[("/api/v1/systemHealth")]
  Page --> Utils["Status utils"] --> Dot["StatusDot"]
  subgraph Legend
    direction LR
    _cfg{{"Config/Flag"}} ~~~ _ui["UI component"] ~~~ _api[("API endpoint")]
  end

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Compute overall status in the query hook (or API response)

• ➕ Avoids recomputing overall status multiple times per render
• ➕ Centralizes derivation logic closer to data fetching / backend contract
• ➕ Simplifies the page component (render-only)
• ➖ Slightly reduces flexibility if the UI later needs multiple aggregation variants
• ➖ If done server-side, requires API change coordination and versioning

2. Use invalidateQueries instead of refetch for Refresh

• ➕ Scales better if multiple components consume the same query key
• ➕ Keeps refresh logic consistent with global cache invalidation patterns
• ➖ Slightly less direct than refetch for a single consumer button
• ➖ Requires access to QueryClient in the component

Recommendation: Current approach is appropriate for an initial feature: client-side aggregation is simple and testable, and using refetch keeps the Refresh button behavior explicit. If more consumers or derived fields appear, consider moving overall status computation into the query layer (or API) to prevent duplicated derivations and to standardize the contract.

Files changed (19) +640 / -1

Enhancement (12) +534 / -0

Routes.tsxRegister /system-health route behind observability flag +3/-0

Register /system-health route behind observability flag

• Adds lazy loading and path constant for System Health. Conditionally includes the route only when features.observability is enabled.

client/src/app/Routes.tsx

sidebar.tsxConditionally show System Health link in sidebar +12/-0

Conditionally show System Health link in sidebar

• Adds a new sidebar navigation entry for System Health. The link is rendered only when features.observability is enabled.

client/src/app/layout/sidebar.tsx

SystemHealth.tsxImplement System Health page header summary and refresh +119/-0

Implement System Health page header summary and refresh

• Adds the main System Health page layout and header section. Fetches system health via a React Query hook, displays an aggregated overall status with a status dot, shows last checked time, and wires the Refresh button to refetch().

client/src/app/pages/SystemHealth/SystemHealth.tsx

ErrorRateCard.tsxAdd error rate summary card (mock data) +79/-0

Add error rate summary card (mock data)

• Introduces a PatternFly card showing total errors, error rate, and a breakdown list. Uses StatusDot for highlighting severe breakdown items.

client/src/app/pages/SystemHealth/components/ErrorRateCard.tsx

ExpiringTrustAssets.tsxAdd expiring trust assets card (mock data) +105/-0

Add expiring trust assets card (mock data)

• Adds a card listing trust assets with expiry details and severity-based coloring. Shows an 'expired' count label when applicable and includes a placeholder Renewal runbook link.

client/src/app/pages/SystemHealth/components/ExpiringTrustAssets.tsx

IncidentTimeline.tsxAdd incident timeline card (mock data) +85/-0

Add incident timeline card (mock data)

• Adds a vertical incident list with severity dots and connecting line segments. Uses static mock incidents with timestamps and severities.

client/src/app/pages/SystemHealth/components/IncidentTimeline.tsx

PipelineStatusBanner.tsxAdd signing pipeline status banner +17/-0

Add signing pipeline status banner

• Introduces an inline danger Alert describing pipeline unavailability. Includes placeholder action links for incident and runbook navigation.

client/src/app/pages/SystemHealth/components/PipelineStatusBanner.tsx

ServiceStatusCard.tsxAdd per-service status card component +32/-0

Add per-service status card component

• Creates a compact card for a single service showing status dot, name, status text, and detail text. Maps statuses to severity/colors via shared utilities.

client/src/app/pages/SystemHealth/components/ServiceStatusCard.tsx

StatusDot.tsxAdd reusable status dot indicator +10/-0

Add reusable status dot indicator

• Implements a small SVG circle wrapped in a PatternFly Icon for consistent status indicators. Color is driven by the shared severityColor utility.

client/src/app/pages/SystemHealth/components/StatusDot.tsx

index.tsExport SystemHealth page as default module entry +1/-0

Export SystemHealth page as default module entry

• Adds an index barrel export so the page can be lazy-imported cleanly from the folder path.

client/src/app/pages/SystemHealth/index.ts

utils.tsAdd status aggregation and severity/color utilities +50/-0

Add status aggregation and severity/color utilities

• Defines ServiceStatus/OverallStatus/Severity types and implements getOverallStatus plus status/severity mapping helpers. Provides color mapping to PatternFly CSS variables for consistent UI styling.

client/src/app/pages/SystemHealth/utils.ts

system-health.tsAdd React Query hook for /api/v1/systemHealth (mockable) +21/-0

Add React Query hook for /api/v1/systemHealth (mockable)

• Implements useFetchSystemHealth using useMockableQuery and the generated client getApiV1SystemHealth call. Exposes data, isFetching, fetchError, and refetch for page consumption.

client/src/app/queries/system-health.ts

Tests (2) +47 / -1

sidebar.test.tsxTest System Health nav visibility under observability flag +15/-1

Test System Health nav visibility under observability flag

• Updates the mocked feature flags to include observability. Adds test cases asserting the System Health link is hidden when off and visible when on.

client/src/app/layout/sidebar.test.tsx

utils.test.tsAdd unit tests for overall status aggregation and mapping +32/-0

Add unit tests for overall status aggregation and mapping

• Adds test coverage for getOverallStatus across healthy/unhealthy/mixed cases. Verifies overallStatusToSeverity mapping to success/warning/danger.

client/src/app/pages/SystemHealth/utils.test.ts

Other (5) +59 / -0

settings.local.jsonAdd local Claude tool permissions settings +18/-0

Add local Claude tool permissions settings

• Introduces a Claude local settings file defining allowed commands/reads and additional directories. This appears to be developer-local configuration rather than application runtime configuration.

.claude/settings.local.json

useFeatureFlags.tsxAdd observability feature flag sourced from env +2/-0

Add observability feature flag sourced from env

• Extends feature flags context to include observability. Maps ENV.FEATURE_OBSERVABILITY to the new features.observability boolean.

client/src/app/hooks/useFeatureFlags.tsx

system-health.tsAdd mock SystemHealth API response data +8/-0

Add mock SystemHealth API response data

• Introduces a mock SystemHealthResponse payload with one unhealthy service and an updatedAt timestamp. Used to support MOCK mode for UI development/testing.

client/src/app/queries/mocks/system-health.ts

environment.tsIntroduce FEATURE_OBSERVABILITY env var with default off +5/-0

Introduce FEATURE_OBSERVABILITY env var with default off

• Extends the console environment contract to include FEATURE_OBSERVABILITY. Ensures it is defaulted to 'off' and surfaced through the shared env builder.

common/src/environment.ts

package-lock.jsonLockfile update (peer metadata changes) +26/-0

Lockfile update (peer metadata changes)

• Updates package-lock entries to mark certain platform-specific packages as peer dependencies. No direct application code changes are introduced here, but it impacts dependency metadata.

package-lock.json

[qodo-for-securesign]

Code Review by Qodo

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

1. Committed local Claude settings ✓ Resolved 🐞 Bug ⛨ Security

Description

The PR commits .claude/settings.local.json containing developer-specific absolute paths and broad
tool permissions (including reads outside the repo), which can leak local details and
unintentionally propagate unsafe permissions to other contributors/automation.

Code

.claude/settings.local.json[R7-10]

+      "Bash(awk '/^diff --git a\\\\/package-lock.json/{skip=1; next} /^diff --git/{skip=0} !skip' /Users/ryordan/.claude/projects/-Users-ryordan-projects-rhtas-console-ui/b4ef0fe3-ad32-4195-bc09-90a78aa0d59d/tool-results/bh86uw4jy.txt > /tmp/pr298_meaningful.txt && wc -l /tmp/pr298_meaningful.txt)",
+      "Bash(npm ls *)",
+      "WebSearch",
+      "Bash(gh api *)",

Relevance

●●● Strong

Local AI settings with absolute paths/extra permissions shouldn’t be committed; likely
removed/ignored via gitignore.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The committed file includes an allow-list with an absolute /Users/ryordan/... path and a rule
allowing reads under //Users/ryordan/**, which is both user-specific and outside the repo.

.claude/settings.local.json[1-17]

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 local Claude configuration file was added to the repo with user-specific absolute paths and broad permissions. This is not portable and can leak sensitive local filesystem details and expand permitted actions when others use the tooling.

## Issue Context
This file appears to be local/editor/tool state (`settings.local.json`) and includes paths under `/Users/ryordan/...` plus permissive allow rules.

## Fix Focus Areas
- Remove file from version control and add to ignore:
 - .claude/settings.local.json[1-18]
 - .gitignore[1-160]

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

---

2. Empty status yields Operational 🐞 Bug ≡ Correctness

Description

getOverallStatus returns "Operational" for an empty statuses array because every() is
vacuously true, which can incorrectly report healthy status if a caller ever passes an empty list.

Code

client/src/app/pages/SystemHealth/utils.ts[R7-10]

+export function getOverallStatus(statuses: ServiceStatus[]): OverallStatus {
+  if (statuses.every((s) => s === "healthy")) return "Operational";
+  if (statuses.every((s) => s === "unhealthy")) return "Down";
+  return "Degraded";

Relevance

●●● Strong

Vacuous truth on empty arrays is a subtle but real bug; adding a length guard is low-risk.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The implementation uses statuses.every(...) without checking statuses.length, and the added
tests do not cover the empty-array case.

client/src/app/pages/SystemHealth/utils.ts[7-11]
client/src/app/pages/SystemHealth/utils.test.ts[4-18]

Agent prompt

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

## Issue description
`getOverallStatus([])` currently returns "Operational" due to `Array.every()` semantics on empty arrays. This is unsafe for a general-purpose utility and can silently misclassify overall health.

## Issue Context
Current page usage passes a fixed 3-element array, but the function is exported and unit-tested as a standalone utility.

## Fix Focus Areas
- Add an explicit empty-array guard (and add a unit test):
 - client/src/app/pages/SystemHealth/utils.ts[7-11]
 - client/src/app/pages/SystemHealth/utils.test.ts[4-18]

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

---

3. Inline margin style on Button 📘 Rule violation ⚙ Maintainability

Description

The new System Health UI uses inline spacing styles (e.g., marginTop) where PatternFly utility
classes can express the same layout, increasing custom styling surface area.

Code

client/src/app/pages/SystemHealth/components/ExpiringTrustAssets.tsx[R96-99]

+        isInline
+        icon={<ArrowRightIcon />}
+        iconPosition="end"
+        style={{ marginTop: "var(--pf-t--global--spacer--md)" }}

Relevance

●●● Strong

Repo has accepted reducing inline/custom styling in favor of PatternFly defaults/utilities.

PR-#82

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance ID 457 requires using PatternFly utilities/props instead of custom CSS/inline styles
for standard spacing/layout. The Button adds a style prop only to apply top margin.

Rule 457: Prefer PatternFly utilities and props over custom CSS
client/src/app/pages/SystemHealth/components/ExpiringTrustAssets.tsx[94-102]

Agent prompt

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

## Issue description
Prefer PatternFly utility classes/props over inline styles for common spacing/layout.

## Issue Context
The `Renewal runbook` link button uses an inline `marginTop` token that can be replaced with a PatternFly spacing utility class.

## Fix Focus Areas
- client/src/app/pages/SystemHealth/components/ExpiringTrustAssets.tsx[94-102]

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

---

4. Sigstore status labeled Fulcio 🐞 Bug ≡ Correctness

Description

SystemHealth renders a service card named "Fulcio" but binds its status to
data.sigstoreServices, which the OpenAPI schema describes as overall "Sigstore services" health;
this mislabels the status and can mislead incident triage.

Code

client/src/app/pages/SystemHealth/SystemHealth.tsx[R25-28]

+    {
+      name: "Fulcio",
+      status: data?.sigstoreServices ?? "unknown",
+      detail: "No response · 47 attempts (mock data)",

Relevance

●●● Strong

Label/status mismatch is a user-facing correctness issue; likely they’ll rename card or bind correct
field.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

The System Health page maps sigstoreServices to a card named "Fulcio", while the OpenAPI schema
explicitly describes sigstoreServices as "Sigstore services health status" (not Fulcio-specific).

client/src/app/pages/SystemHealth/SystemHealth.tsx[24-32]
client/openapi/console.yaml[1147-1154]

Agent prompt

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

## Issue description
The UI labels `sigstoreServices` as "Fulcio" even though the API schema defines it as "Sigstore services" health. This mismatch can confuse users about which component is unhealthy.

## Issue Context
The API provides `sigstoreServices`, `rekorStatus`, `tufStatus`. If a Fulcio-specific status is intended, the API/response field name should reflect that; otherwise, the UI label should.

## Fix Focus Areas
- Update card label or data mapping:
 - client/src/app/pages/SystemHealth/SystemHealth.tsx[24-32]
- Confirm schema meaning:
 - client/openapi/console.yaml[1147-1154]

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

---

View more (4)

5. Order-dependent sidebar tests 🐞 Bug ☼ Reliability

Description

sidebar.test.tsx mutates a shared mockFeatures object across tests without resetting it, making
the test outcomes depend on execution order and increasing flakiness risk.

Code

client/src/app/layout/sidebar.test.tsx[R44-52]

+    mockFeatures.observability = false;
+    renderSidebar();
+
+    expect(screen.queryByRole("link", { name: "System Health" })).not.toBeInTheDocument();
+  });
+
+  test("shows System Health link when observability flag is on", () => {
+    mockFeatures.observability = true;
+    renderSidebar();

Relevance

●●● Strong

Order-dependent test state is a common flake source; resetting mockFeatures per test is a
straightforward fix.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

A single module-level mockFeatures object is returned by the hook mock and is mutated in multiple
tests (including the newly added observability tests) without a reset.

client/src/app/layout/sidebar.test.tsx[6-10]
client/src/app/layout/sidebar.test.tsx[29-55]

Agent prompt

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

## Issue description
The mocked feature flags object is module-scoped and mutated within tests, but it is never reset in a `beforeEach`. This makes tests order-dependent and can fail under different execution ordering.

## Issue Context
The mock returns the same `mockFeatures` object reference for every render.

## Fix Focus Areas
- Reset flags in `beforeEach` or create a fresh object per test:
 - client/src/app/layout/sidebar.test.tsx[6-55]

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

---

6. UI labels embedded in assets 📘 Rule violation ⌂ Architecture

Description

ExpiringTrustAssets hardcodes UI-derived fields like expiryLabel and timeRemaining directly in
mock data, instead of deriving them in a mapper/view-model layer from raw domain fields.

Code

client/src/app/pages/SystemHealth/components/ExpiringTrustAssets.tsx[R19-24]

+interface TrustAsset {
+  name: string;
+  expiryLabel: string;
+  timeRemaining: string;
+  severity: Severity;
+}

Relevance

●● Moderate

Refactoring mock fixtures into a mapper/view-model is architectural and may be deferred, especially
for mock-data UI.

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance IDs 422 and 469 require UI-derived/computed state to live in mapping/view-model code
rather than being embedded in mock/fixture data. The assets fixture includes preformatted display
strings (expiryLabel, timeRemaining) and UI severity values baked into the data.

Rule 422: Separate UI-computed state into a mapper/view-model layer (do not embed in mock data)
Rule 469: UI state transformations must live in mapping/view-model layers, not in mock data or raw query DTOs
client/src/app/pages/SystemHealth/components/ExpiringTrustAssets.tsx[19-45]

Agent prompt

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

## Issue description
Mock/fixture data should contain raw domain fields only; UI-computed/derived fields (labels, formatted strings, UI severities) should be computed in a mapper/view-model layer.

## Issue Context
`ExpiringTrustAssets` defines `TrustAsset` with UI-derived fields (`expiryLabel`, `timeRemaining`, `severity`) and hardcodes mock entries with preformatted strings.

## Fix Focus Areas
- client/src/app/pages/SystemHealth/components/ExpiringTrustAssets.tsx[19-45]

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

---

7. SystemHealthKey not key factory 📘 Rule violation ⚙ Maintainability

Description

useFetchSystemHealth uses an exported array literal (SystemHealthKey) instead of a semantically
named query key factory, making reuse and consistency harder across call sites.

Code

client/src/app/queries/system-health.ts[6]

+export const SystemHealthKey = ["system-health"];

Relevance

●● Moderate

They’ve accepted query-key improvements before, but no close precedent on “factory vs exported
literal” requirement.

PR-#6

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance ID 465 requires query keys be generated by exported factories rather than inline
arrays/string literals. The new code defines SystemHealthKey as an exported array literal and uses
it directly in useMockableQuery.

Rule 465: Export and semantically name query key factories
client/src/app/queries/system-health.ts[6-13]

Agent prompt

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

## Issue description
React Query keys should be produced by a named, exported factory (not inline arrays or exported array literals) so keys are consistent and reusable across hooks/components.

## Issue Context
`SystemHealthKey` is currently defined as an array literal and used directly as `queryKey`.

## Fix Focus Areas
- client/src/app/queries/system-health.ts[6-13]

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

---

8. SystemHealth refresh lacks tests 📘 Rule violation ▣ Testability

Description

The new System Health page adds user-visible behavior (Refresh triggers refetch()), but no
automated tests validate this interaction or the page’s data-driven rendering.

Code

client/src/app/pages/SystemHealth/SystemHealth.tsx[R73-75]

+                    <Button variant="secondary" icon={<SyncAltIcon />} onClick={() => void refetch()}>
+                      Refresh
+                    </Button>

Relevance

●● Moderate

Team has rejected some “add tests for patch coverage” asks; unclear they’ll add UI interaction tests
now.

PR-#306
PR-#309

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance ID 462 requires tests for behavior-changing modifications. The PR introduces a new
page with a Refresh interaction calling refetch(), while the added tests under the feature only
exercise getOverallStatus/overallStatusToSeverity and do not cover the UI behavior.

Rule 462: Require tests for all behavior-changing code modifications
client/src/app/pages/SystemHealth/SystemHealth.tsx[21-76]
client/src/app/pages/SystemHealth/utils.test.ts[1-32]

Agent prompt

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

## Issue description
Behavior-changing UI code (new page + refresh interaction) must have automated tests that would fail if the behavior were removed.

## Issue Context
`SystemHealth` wires the Refresh button to React Query `refetch()`, but the only new tests in this feature area cover pure utilities.

## Fix Focus Areas
- client/src/app/pages/SystemHealth/SystemHealth.tsx[21-79]
- client/src/app/pages/SystemHealth/utils.test.ts[1-32]

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

---

9. Observability flag undocumented 🐞 Bug ⚙ Maintainability

Description

The PR introduces the FEATURE_OBSERVABILITY configuration flag but the repository's
environment-variable documentation does not mention it, reducing discoverability for enabling the
feature.

Code

common/src/environment.ts[R23-25]

+  /** Controls whether observability features (system health) are enabled */
+  FEATURE_OBSERVABILITY: string;
+

Relevance

●●● Strong

Repo commonly accepts documentation updates when configs/manifests change; adding new env var to
README fits that pattern.

PR-#38
PR-#331

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

FEATURE_OBSERVABILITY is added to the shared env schema, but the README env var table only lists
FEATURE_MONITORING (and not the new flag).

common/src/environment.ts[20-25]
README.md[57-65]

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 new env var (`FEATURE_OBSERVABILITY`) is now used to gate the System Health UI, but README environment documentation hasn’t been updated.

## Issue Context
Operators/devs will likely rely on README to discover required configuration flags.

## Fix Focus Areas
- Add a README table row for FEATURE_OBSERVABILITY (purpose, accepted values, default):
 - README.md[57-65]
- Confirm env var definition/default:
 - common/src/environment.ts[20-25]

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

---

Context used

✅ Compliance rules (platform): 29 rules

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

[codecov-commenter]

Codecov Report

❌ Patch coverage is 89.65517% with 9 lines in your changes missing coverage. Please review.
✅ Project coverage is 76.58%. Comparing base (65f165c) to head (7cc2272).
⚠️ Report is 1 commits behind head on main.

Files with missing lines	Patch %	Lines
client/src/app/queries/system-health.ts	0.00%	7 Missing ⚠️
client/src/app/Routes.tsx	50.00%	0 Missing and 1 partial ⚠️
client/src/app/queries/mocks/system-health.ts	0.00%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #358      +/-   ##
==========================================
+ Coverage   75.94%   76.58%   +0.64%     
==========================================
  Files         109      119      +10     
  Lines        1621     1708      +87     
  Branches      496      530      +34     
==========================================
+ Hits         1231     1308      +77     
- Misses        343      351       +8     
- Partials       47       49       +2     

Flag	Coverage Δ
unit	61.99% <89.65%> (+1.49%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.