feat/ui-impact

avgFp3m NaN when site has no recent bills

apps/platform/src/app/[locale]/(dashboard)/energia/demanda/page.tsx:137

`avgFp3m = recentBills.reduce(...) / recentBills.length` produces NaN when recentBills is empty. Not triggered today on static mock data (all AXO sites have 24 billed periods), but if ever fed real API data a site with < 3 billed periods will silently produce NaN for avgFp3m, making every downstream comparison (`avgFp3m < 0.9`, fpTextColor, fpSeverity) return false. Fix: `recentBills.length > 0 ? sum / recentBills.length : 1.0`.

f.rpu ?? undefined is a no-op (rpu is non-nullable in FindingResponse)

apps/platform/src/app/[locale]/(dashboard)/energia/_lib/findingView.ts:150

FindingResponse.rpu is typed as `string` (never null), so `f.rpu ?? undefined` always evaluates to `f.rpu`. The nullish coalescing is harmless but misleading — implies the field could be undefined at runtime when the schema guarantees it cannot.

demanda/page.tsx has zero i18n coverage — all display strings hardcoded Spanish

apps/platform/src/app/[locale]/(dashboard)/energia/demanda/page.tsx

Page title, subtitle, DriverLegend labels, sub-chart annotations, badge copy ('En vivo · ledger de hallazgos', 'Ilustrativo') are all hardcoded Spanish literals. The project convention requires all user-facing strings in messages/{locale}.json via next-intl. This commit adds several new hardcoded strings on an already-uncovered page. The nav label ('Demanda y FP') IS correctly in both locale files — the gap inside the page is more visible.

rpu comment in realData.ts ('from the API') is misleading against the SECURITY annotation

apps/platform/src/app/[locale]/(dashboard)/energia/_lib/realData.ts:44

The file's SECURITY header (lines 3-4) says it must contain NO real RPUs. The rpu?: string field is type-level only and PLACEHOLDER_FINDINGS never sets it — no real data ships in this file. But the comment '// the finding's real RPU (from the API)' implies the opposite to a future contributor, suggesting it's acceptable to populate rpu here. The comment should clarify that this field is only populated by findingView.ts (the API projection path), not by synthetic data.

Arbitrary Tailwind font-size values (text-[10px], text-[11px]) bypass the design-system scale

apps/platform/src/app/[locale]/(dashboard)/energia/demanda/page.tsx

TailwindCSS v4 with a design-system scale — arbitrary values circumvent consistent typography. Closest equivalent is text-xs (12px); if these micro-label sizes are intentional, add them to the theme config.

WHAT-style comments on storeId/storeName fields in realData.ts

apps/platform/src/app/[locale]/(dashboard)/energia/_lib/realData.ts:45

Comments '// details.storeId — links a consumption finding to its real series' and '// details.storeName — display label when present' describe what the fields are, not why a non-obvious decision was made. Project convention restricts comments to WHY reasoning.

toFindingView rpu passthrough not asserted in findingView.test.ts

apps/platform/src/app/[locale]/(dashboard)/energia/_lib/__tests__/findingView.test.ts:66

The existing test calls toFindingView() but only checks v.impactKind and v.title. The new rpu field is never asserted — a regression that drops or misnames it would be invisible. Add: expect(v.rpu).toBe('123456789012') plus a case with rpu: null to verify the ?? undefined coercion.

demandTextColor and fpTextColor branch logic untested

apps/platform/src/app/[locale]/(dashboard)/energia/demanda/page.tsx:38

Both are pure functions with distinct threshold boundaries (pct: 100, 85; fp: 0.9) but are unexported module-level consts inside a 'use client' page. Cheapest fix: extract to demanda/_lib/metrics.ts, export, and unit-test boundary values. The boundary at pct === 100 (not > 100) and pct === 85 are silent correctness questions that tests would pin.

buildSiteMetrics severity tie-break logic untested

apps/platform/src/app/[locale]/(dashboard)/energia/demanda/page.tsx:131

The rank comparison has three meaningful paths: demand wins outright, FP wins outright, and tie (both critico — rank equal, demand wins by >=). None is covered. Function is unexported; extraction to demanda/_lib/metrics.ts would allow unit testing.

illustrativeRpu deletion leaves no orphaned tests; buildLetter fallback untested

illustrativeRpu() had no tests before deletion — nothing to clean up. The new 'por confirmar' fallback path in buildLetter() (when finding.rpu is undefined) is also untested, but low urgency given the demo context.

rank lookup object recreated inside the per-site loop — hoist to module level

apps/platform/src/app/[locale]/(dashboard)/energia/demanda/page.tsx:150

const rank: Record<Sev, number> = { critico: 2, atencion: 1, saludable: 0 } is allocated fresh inside the per-site map body of buildSiteMetrics(). It contains no site-specific data. Hoist to module level alongside demandTextColor/fpTextColor — consistent with the file's existing pattern for static helpers.

rpu: f.rpu ?? undefined — simplify to rpu: f.rpu

apps/platform/src/app/[locale]/(dashboard)/energia/_lib/findingView.ts:150

FindingResponse.rpu is string (non-optional). The ?? undefined is a no-op that misleads the reader. Write rpu: f.rpu to match the actual type contract.

Extract metrics helpers from page.tsx to testable module

apps/platform/src/app/[locale]/(dashboard)/energia/demanda/page.tsx

demandTextColor, fpTextColor, and the rank logic in buildSiteMetrics are pure functions co-located in a 'use client' page component. Moving them to demanda/_lib/metrics.ts would make them exportable and unit-testable without mounting the component. This also resolves the tests lens findings on the same functions.