feat/ui-impact

useState initializer reads ?tienda= only on mount — soft-nav deep-link silently ignored

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

The lazy initializer in useState(() => { if (typeof window === 'undefined') return 't26'; const t = new URLSearchParams(window.location.search).get('tienda'); ... }) runs exactly once per component mount. On Next.js App Router client-side navigation the ComparativoPage component may already be mounted in the router cache from a previous visit. When the user clicks 'Ver en Comparativo de consumo' (which calls router.push('/energia/comparativo?tienda=<id>')), the URL changes but the initializer does NOT re-run — storeId stays at its previous value. The intent of ConsumptionFindingContent.tsx:116 (deep-link into Comparativo pre-selecting the anomalous store) silently fails. Fix: use useState(null) + useEffect(() => { const t = params.get('tienda'); if (t && STORES.some(s => s.id === t)) setStoreId(t); }, []) — the pattern already used in useSiteSelection.ts.

Division by zero when store has no series data — NaN renders in KPI and % badge

apps/platform/src/app/[locale]/(dashboard)/energia/_components/ConsumptionFindingContent.tsx:61

Line 60: const recent = store.series.slice(-6). If store.series is empty, recent.length === 0. Line 61: mine = recent.reduce(..., 0) / recent.length → NaN. NaN.toFixed(0) renders 'NaN kWh/día' in the KPI card and 'NaN%' in the warning badge. The !store null-guard (line 56) protects against a missing storeId but not against a store with no billing records. Similarly, if any cohort store has an empty series, the per-store average inside cohort.map() also divides by zero. Fix: guard both sides: const mine = recent.length ? recent.reduce((a,p) => a + kwhDia(p), 0) / recent.length : 0.

Duplicate median() function — should be exported from shared realConsumption lib

apps/platform/src/app/[locale]/(dashboard)/energia/_components/ConsumptionFindingContent.tsx:20

Identical median(xs: number[]) implementation exists in both ConsumptionFindingContent.tsx (line 20) and comparativo/page.tsx. ConsumptionFindingContent already imports STORES, kwhDia, and MonthPoint from comparativo/_lib/realConsumption — median should be exported there and imported by both consumers. A future correction (e.g. true interpolated median for even-length arrays) currently requires editing two files.

Em dashes in user-facing label strings

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

Kpi label prop and CardTitle text contain em dashes (—) in rendered copy (e.g. '${store.nombre} — consumo'). ui-patterns.md prohibits em dashes in user-facing copy. Replace with a colon or period: '${store.nombre}: consumo'.

No i18n — hardcoded Spanish strings throughout (pre-existing pattern, extended)

apps/platform/src/app/[locale]/(dashboard)/energia/_components/ConsumptionFindingContent.tsx:1

All user-facing strings are hardcoded in Spanish instead of sourced from messages/{locale}.json via next-intl. CLAUDE.md ui-patterns requires next-intl for all user-facing strings. Mitigating: the entire energía module shares this deviation — this diff extends an existing non-conforming pattern rather than establishing a new one.

toFindingView storeId branch untested — action 'Ver consumo' and routing to ConsumptionFindingContent

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

The new ternary path storeId ? 'Ver consumo' : CATEGORY_ACTION[category] is completely uncovered. A test should pass details: { storeId: 's26', storeName: 'KK Tijuana' } and assert action === 'Ver consumo', storeId === 's26', storeName === 'KK Tijuana'. Without this, a future reordering of the ternary conditions could silently break FindingRow.tsx routing — cotizacion findings with a storeId would route to ConsumptionFindingContent instead of the quote flow.

toFindingView desc uses storeName prefix when present — not tested

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

When details.storeName is set, desc leads with the store name instead of 'RPU ${rpu}'. The existing tests never assert the desc field. Two cases needed: (1) details: { storeId: 's26', storeName: 'KK Tijuana' } → desc starts with 'KK Tijuana'; (2) details: { storeId: 's26' } (no storeName) → desc falls back to 'RPU ${rpu}'. desc is displayed as the subtitle in both the finding list and the detail sheet.

toFindingView: non-string storeId/storeName in details falls back to undefined — not tested

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

The defensive guards typeof details.storeId === 'string' and typeof details.storeName === 'string' are untested. A test should pass details: { storeId: 42, storeName: null } and assert storeId === undefined, storeName === undefined, action !== 'Ver consumo'. This prevents a server sending a numeric storeId from silently routing to the ConsumptionFindingContent.

COTIZACION_TYPES priority over storeId interaction untested

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

If a finding has both a COTIZACION_TYPES type AND details.storeId set, action should be 'Solicitar cotización' (COTIZACION_TYPES check first in the ternary). A brief test makes the priority ordering explicit and guards against future condition reordering.

Cohort includes the store being compared — biases the peer median toward the outlier

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

cohort = STORES.filter(s => s.tarifa === store.tarifa) includes the current store. When this store is the anomaly being flagged as 'consume más que sus pares', its high consumption value is included in the cohort median computation, systematically understating the gap. The same pattern exists in comparativo/page.tsx (pre-existing), but the finding-detail context makes the bias more visible — the card is supposed to show why this store was flagged. Fix: add && s.id !== store.id to the filter predicate.

Stats block re-derives 6-month average already computed inside chart useMemo

apps/platform/src/app/[locale]/(dashboard)/energia/_components/ConsumptionFindingContent.tsx:44

The chart useMemo iterates all months and the stats block independently slices and averages the last 6 months — same traversal, duplicated logic. Extract avgKwhDia(series, last = 6) and use it from both sites.

median() returns lower-bound element, not a true median for even-length arrays

apps/platform/src/app/[locale]/(dashboard)/energia/_components/ConsumptionFindingContent.tsx:20

Math.floor(s.length / 2) always picks the lower of the two middle elements for even-length arrays. For a 4-element cohort the standard median is the mean of elements [1] and [2]. Low impact with static data but systematically biases results downward for small cohorts.