fix(analytics): calculate and format hero deltas for the selected range

[castrojo]

Fixes #1087.

Problem

CountmeAnalyticsCharts's hero KPI:

• formatted the delta as +${bluefinDeltaPct}%, so a negative delta rendered as +-4.2%.
• computed initialTotalBluefin from weeks[0] (the all-time first week) regardless of the selected hero range, so switching between 12-week/24-week/all-history left the delta baseline tied to the complete history instead of the start of the selected range.

Fix

src/components/analytics/CountmeAnalyticsCharts.tsx:

• firstWeek now comes from heroFilteredWeeks[0] instead of weeks[0], so the delta baseline moves with the selected heroRange.
• Added bluefinDeltaIsPositive and use it to format the sign conditionally (+ only when non-negative), matching the existing convention in ReportCountmeTrend.tsx (isPositive ? \+${changePct}%` : `${changePct}%`) instead of hardcoding +`.
• The chart's accessible summary text now says "up"/"down" based on the same sign, uses Math.abs(...) so it never reads "down -4.2%", and reports heroFilteredWeeks.length (the selected range's week count) instead of the all-time weeks.length.

Verification

No React component test harness exists in this repo (test only runs scripts/**/*.test.js; no .test.tsx/testing-library anywhere), so I traced the extracted logic in a throwaway script with synthetic week data (fleet count rising for 18 weeks then declining for 12):

• range=all: baseline = week 0 (1000) → +195.0% overall, 30 tracked weeks.
• range=24w: baseline = week 6 (2200) → +34.1% overall, 24 tracked weeks.
• range=12w: baseline = week 18, the peak (4600) → -35.9% overall (no +-), "down 35.9% across 12 tracked weeks" — reproducing and then fixing the exact +-35.9% glitch from the issue.

Confirmed the pre-fix code reproduces both bugs (baseline stuck at the all-time first week regardless of range; +${"-35.9"}% → +-35.9%).

— hive: backend=omp

[hanthor]

Fix reads correct. Two notes — one of them contradicts the Verification section.

Both bugs are real and the change addresses them precisely: firstWeek moving from weeks[0] to heroFilteredWeeks[0] fixes the baseline drift, and bluefinDeltaIsPositive fixes the +-4.2% glitch. Merged into current main the suite is unchanged and green:

$ npm run test:coverage   # origin/main + pr1227
ℹ tests 925
ℹ pass 925
ℹ fail 0

(same as the unmodified-main baseline, as expected for a .tsx-only change.)

1. The delta stays green when it goes negative

src/components/analytics/CountmeAnalyticsCharts.tsx:518-522:

<span style={{ fontWeight: 700, color: "#39d2c0" }}>
  {bluefinDeltaIsPositive ? "+" : ""}
  {bluefinDeltaPct}% overall
</span>

The sign is now conditional but color: "#39d2c0" is still hardcoded teal. On the 12w case from your own verification (-35.9%), the UI renders a decline in the growth accent colour. The summary text you fixed says "down"; the visual says otherwise. Worth making the colour follow bluefinDeltaIsPositive too, since you are already computing it one line up.

2. "No React component test harness exists in this repo" is not accurate

From the Verification section:

No React component test harness exists in this repo (test only runs scripts/**/*.test.js; no .test.tsx/testing-library anywhere), so I traced the extracted logic in a throwaway script

The .test.tsx half is true, but the repo does have a working harness for .tsx logic — it just lives under scripts/ so that npm test picks it up. scripts/portal-static-render.test.js ships a require-shim that resolves @site/ imports and .ts/.tsx suffixes, renders components to a string in-process, and asserts on the markup:

const rel = id.slice("@site/".length);
const target = path.resolve(root, rel);
...
for (const suffix of [".ts", ".tsx", ...])

docs/skills/component-testing.md documents this as the house pattern, and open PR #1211 uses it for a brand-new component test (scripts/portal-brand-icons.test.js, 4 tests — I mutated an icon path and it failed, so it is a live gate).

The throwaway-script trace is good evidence and I do not think it blocks merge, but the delta arithmetic here is exactly the kind of pure function that pattern covers: extract the initialTotalBluefin / bluefinDeltaPct / bluefinDeltaIsPositive computation and assert your three documented cases (all → +195.0%, 24w → +34.1%, 12w → -35.9% with no +-). That turns a one-time manual trace into a permanent regression gate, and would have caught the original bug.

---

Generated by Claude Code