feat/ui-impact

`monthly` output lacks comparable-store count — silent zeros ambiguous

apps/platform/src/app/[locale]/(dashboard)/energia/comparativo/_lib/likeForLike.ts:205

When `resolveWindow` returns a window anchored at the last month complete for 3+ stores but earlier months have fewer, the bar chart shows zeros for those months. The `monthly` type has no `n` field, so the UI cannot distinguish 'comparable stores consumed zero' from 'no comparable stores qualified this month'. This violates the honesty contract — the chart title says 'Mes a mes' with no qualification. Add `n: comparable.filter(r => r.curMonths[i] != null).length` to each monthly entry.

Bill supersession sort doesn't clear older bill's tail on partial re-issues

apps/platform/src/app/[locale]/(dashboard)/energia/comparativo/_lib/likeForLike.ts:75

Bills are sorted by (ps ASC, pe ASC). A corrective shorter bill (same start, shorter end) sorts second and overwrites the prefix correctly, but leaves the original bill's per-day value on the non-overlapping tail days — the older value survives. Coverage count is unaffected; allocated kWh on those tail days comes from the superseded bill. Low probability with bimonthly CFE data, but the doc comment promises more than the algorithm delivers.

t18 has a 30-day billing gap (Mar 23 – Apr 22 2026) — `ym='2026-04'` label is cosmetically misleading

apps/platform/src/app/[locale]/(dashboard)/energia/comparativo/_lib/realConsumption.ts

The algorithm correctly handles this (Apr 2026 gets only 9 covered days, never complete). The `ym` label for the bill covering Apr 22–May 21 is '2026-04' but the bill is 87% in May. calendarMonths ignores ym entirely, so no algorithmic error — purely cosmetic.

Real Grupo Axo financial data in client-served JS bundle

apps/platform/src/app/[locale]/(dashboard)/energia/comparativo/_lib/realConsumption.ts

The STORES array contains real MXN bill totals, kWh values, and period dates extracted from production Supabase. This ships in the Next.js client JS chunk and is readable by any authenticated Batu user — not just Grupo Axo. Anonymizing store names is necessary but not sufficient when real financials are included. Either scope the page to Grupo Axo's org only or replace exact MXN/kWh figures with order-of-magnitude-preserving synthetic values.

Real production data now permanent in git history

apps/platform/src/app/[locale]/(dashboard)/energia/comparativo/_lib/realConsumption.ts

Even if replaced with synthetic data in a future commit, the real Grupo Axo kWh/MXN figures are permanently in commit 7fc4ef0d. If the repo is ever shared externally, a filter-branch or git-filter-repo operation would be needed to expunge them.

`escapeCell` in csv.ts doesn't strip CSV formula-injection prefixes

apps/platform/src/app/[locale]/(dashboard)/energia/_components/csv.ts

Cells starting with `=`, `+`, `-`, or `@` are not escaped. Safe today with hardcoded store names and numeric values, but a latent bug if `exportCsv` is ever called with user-supplied free-text strings.

Duplicate `shortMonth`/`monthLabel` in same `_lib/` — `shortMonth` has latent timezone bug

apps/platform/src/app/[locale]/(dashboard)/energia/comparativo/_lib/likeForLike.ts

`monthLabel` (new) and `shortMonth` in anomaly.ts produce the same `'Mmm YY'` es-MX format. `monthLabel` correctly adds `timeZone: 'UTC'` to prevent local-to-UTC day-1 rounding from mislabeling a month (e.g., 2024-11 → 'oct. 24' in UTC-5 before 05:00). Remove `shortMonth` from anomaly.ts and import `monthLabel` instead.

`cerrada` exclusion branch (t09 spike) has no test

apps/platform/src/app/[locale]/(dashboard)/energia/comparativo/_lib/__tests__/likeForLike.test.ts

The CLOSED_FRACTION=0.25 check in analyzeOne — which flags stores that opened/closed mid-window by detecting months below 25% of their median — is completely untested. t09 (Tienda Nuevo León 09) has a 343 kWh month against a ~3000 kWh typical, making it the obvious test fixture. A regression in median() or the fraction constant would go undetected.

`monthly` output shape and values not asserted

apps/platform/src/app/[locale]/(dashboard)/energia/comparativo/_lib/__tests__/likeForLike.test.ts

The test only asserts `res.monthly.length === 12`. It does not verify that each element has `{mes, actual, previo}` keys, that `mes` matches `res.window.cur[i]`, or that `actual` equals the sum of comparable store values for that index. A broken reduce (wrong index, wrong field) would silently produce a chart full of zeros.

`daysInMonth` leap-year boundary not tested

apps/platform/src/app/[locale]/(dashboard)/energia/comparativo/_lib/__tests__/likeForLike.test.ts

The indirect invariant test only covers months present in STORES (t01–t16 bimonthly bills don't land on February). A wrong `daysInMonth` for a leap February would mark 28 days as incomplete → never comparable. Add: `daysInMonth('2024-02') === 29` and `daysInMonth('2025-02') === 28`.

`addMonths` year-boundary not tested directly

apps/platform/src/app/[locale]/(dashboard)/energia/comparativo/_lib/__tests__/likeForLike.test.ts

JS `%` on a negative number returns a negative remainder. The current arithmetic is safe for realistic dates, but there's no direct assertion. Add: `addMonths('2025-01', -1) === '2024-12'` and `addMonths('2024-12', 1) === '2025-01'`.

`resolveWindow` boundary test missing: exactly MIN_STORES_FOR_WINDOW (3) stores

apps/platform/src/app/[locale]/(dashboard)/energia/comparativo/_lib/__tests__/likeForLike.test.ts

The filter is `n >= MIN_STORES_FOR_WINDOW`. There's no test asserting that exactly 3 stores with a complete month still produces a valid window. Catches a future `>` vs `>=` drift.

Bill supersession not tested with overlapping synthetic fixture

apps/platform/src/app/[locale]/(dashboard)/energia/comparativo/_lib/__tests__/likeForLike.test.ts

The algorithm's promise that a later bill overwrites the earlier one's days is exercised only implicitly via the invariant tests. A targeted synthetic store with two overlapping bills would pin the behavior explicitly.

`resolveWindow` with custom `months` param not tested

apps/platform/src/app/[locale]/(dashboard)/energia/comparativo/_lib/__tests__/likeForLike.test.ts

Only the default `months=12` is tested. Add a `months=6` case: `resolveWindow(covs, 6).cur.length === 6` and `prev[0]` is 12 months before `cur[0]`.

Double `Map.get` per month in `analyzeOne`

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

`cov.get(m)?.complete ? cov.get(m)!.value : null` calls Map.get twice and relies on a non-null assertion. Replace with `const entry = cov.get(m); return entry?.complete ? entry.value : null`.

Non-comparable `StoreYoY` rows carry misleading non-zero `cur`/`prev`

apps/platform/src/app/[locale]/(dashboard)/energia/comparativo/_lib/likeForLike.ts:155

The `sum` helper uses `?? 0` for null months, so excluded stores have non-zero `cur`/`prev` (the partial-year sum). These fields are never surfaced in the UI but could mislead future consumers of `StoreYoY`. Document that `cur`/`prev` are undefined when `comparable === false`, or zero them out.

Dynamic object keys in `yoyRows` make CSV column shape unit-dependent

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

`[unit === 'mxn' ? 'Actual ($)' : 'Actual (kWh)']` creates a different object shape per unit. If `exportCsv` uses `Object.keys(rows[0])` as headers, this is safe for now but fragile. Prefer fixed column names (`'Actual'`, `'Año previo'`) and reflect the unit in the filename only (already done).

`deltaPct` precision inconsistency: KPI `toFixed(1)` vs table `toFixed(0)`

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

The headline KPI shows '+2.3%' but the per-store table shows '+2%' for the same value. Align to `toFixed(1)` throughout for consistency.

`ExclusionReason = 'ok'` is redundant with the `comparable` boolean

apps/platform/src/app/[locale]/(dashboard)/energia/comparativo/_lib/likeForLike.ts:121

`comparable` is derived directly from `reason === 'ok'`, so both fields encode the same information and must be kept in sync. Either drop `'ok'` from `ExclusionReason` and use `ExclusionReason | null`, or drop the `comparable` field.

`deltaPct.toFixed(0)` in table vs `toFixed(1)` in KPI (also in correctness findings)

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

Cross-referenced with improvement finding above.