claude/vigorous-stonebraker-41cc2d

Polygon drops span 6 regions, not just Norte and Baja California as stated in commit message

apps/web/public/atlas/data/atlas.json

The commit message and the provided semantic-diff summary say only Norte (3→1) and Baja California (7→4) changed. In practice four additional regions also lost polygons: Occidental (6→2, 4 dropped), Central (6→1, 5 dropped), Noreste (2→1, 1 dropped), Baja California Sur (5→4, 1 dropped). The commit description is incomplete. This is not a data-corruption finding — the dropped polygons are geographically implausible for their assigned regions (see next finding) — but the discrepancy between the stated and actual scope of the change warrants attention during review.

Central region reduced to a single polygon — possible under-representation of its boundary

apps/web/public/atlas/data/atlas.json

Central went from 6 to 1 polygon (only the main 392-point body remains). Dropped were: a Michoacán coast fragment (possibly a valid island enclave of the Central grid zone), a Coahuila fragment (clearly wrong), Michoacán highlands, a Veracruz fragment, and a Guadalajara-area fragment. The Michoacán coast (Cen[1]: lat 17.91–18.84, lon -102.90 to -101.86) and Michoacán highlands (Cen[3]: lat 19.41–19.90, lon -102.74 to -102.26) are geographically plausible as small CFE Central-region service islands; their removal may slightly under-draw the Central region boundary on the map. This is a display-only issue with no data or logic impact, but worth a second look against the official CFE regional map.

All 9 accent fixes are correct Spanish orthography

apps/web/public/atlas/data/atlas.json

Every corrected label matches RAE-standard orthography: Eólica, Hidroeléctrica, Geotérmica, Termoeléctrica, Carboeléctrica, Turbogás, Combustión interna, Cogeneración, Baterías. The unchanged labels (Fotovoltaica, Nuclear, Ciclo combinado, CEGEN s/ubicar) were already correct. All T-object keys (pv, wind, hydro, etc.) are unchanged, so no plant-type lookup can break. All color hex codes are identical to base.

Dropped polygons are geographically verifiable as misassigned

apps/web/public/atlas/data/atlas.json

Every removed polygon has a bounding box that is obviously wrong for its source region. Examples: Norte[1] (lat 17.77–18.61, lon -102 to -101) sits in Michoacán/Guerrero, not Chihuahua/Coahuila. Norte[2] (lat 16.58–17.02, lon -97 to -96) is in Oaxaca. BC[1] (lat 17.80–18.65, lon -93 to -91) is in Tabasco/Campeche. BC[4] (lat 20.95–21.14, lon -102.82 to -102.53) is Michoacán interior. BC[6] (lat 18.70–18.92, lon -99 to -99) is Estado de México/CDMX. Occidental dropped polygons include Tabasco (lon -93), Chiapas border (lat 14.5), and open Pacific offshore (lon -111). Central dropped Coahuila (lat 25.86–26.74) and CDMX-area fragments. Noreste dropped an CDMX-area fragment (lat 19.25, lon -98.49). BCS dropped an Oaxaca-coast fragment (lat 15.74–16.37, lon -97). All are clearly misrouted — the drops are correct.

Remaining polygons pass coordinate-range and structural validity checks

apps/web/public/atlas/data/atlas.json

All coordinates in the post-drop RP data fall within Mexico's geographic bounding box (lat 10–35, lon -120 to -85). No degenerate rings (fewer than 3 points). No unclosed rings. JSON parses cleanly. P, H, R, REG, Z, TZ, OL arrays are identical in length and structure to the base commit (P: 537 items, H: 471, OL: 8715). All 537 plant entries reference type codes that exist in the corrected T object.

T labels interpolated into innerHTML — existing pattern, new values are safe

apps/web/public/atlas/data/atlas.json

atlas/index.html line 274 interpolates D.T[t][0] (the label string) and D.T[t][1] (hex color) directly into innerHTML without escaping. This is a pre-existing pattern and not introduced by this commit. The nine accent-corrected labels (Eólica, Hidroeléctrica, Geotérmica, Termoeléctrica, Carboeléctrica, Turbogás, Combustión interna, Cogeneración, Baterías) contain only alphabetic characters, spaces, and Latin-extended Unicode accents — no HTML special characters (<, >, &, quotes), no javascript: / data: URIs, and no control characters. All hex color values remain well-formed #RRGGBB strings. The changed values introduce no XSS risk. The underlying innerHTML pattern is a pre-existing concern for future atlas.json updates but is out of scope for this diff.

Polygon removal does not expose sensitive data

apps/web/public/atlas/data/atlas.json

The dropped polygon arrays in Norte (2 removed, 1 kept) and Baja California (3 removed, 4 kept) are CFE control-region boundary coordinates sourced from publicly available CENACE geographic data. Removing incorrect region assignments reduces visual misinformation on the public map but does not expose, leak, or disclose any non-public geographic or operational data. All remaining coordinate values are numeric floats within valid lat/lon bounds for Mexico (-90 to 90 lat, -180 to 180 lon).

centrales.csv not regenerated after T label accent fixes

apps/web/public/atlas/data/atlas.json

The build-atlas-csv.mjs script explicitly states: 'Source of truth is the bundled JSON the map already loads — so the CSVs never drift from what the map shows. Re-run after editing the data.' This commit fixes accents in atlas.json's T labels but does not regenerate centrales.csv. As a result, centrales.csv now has 329+ rows with unaccented technology labels (e.g., 'Eolica', 'Hidroelectrica', 'Turbogas', 'Combustion interna', etc.) that contradict the corrected source in atlas.json. The script is pnpm --filter @batu/web atlas:csv. The derived CSV is a committed, publicly served open-data download at /atlas/data/centrales.csv, so the drift is user-visible and externally inconsistent.

atlas.json is hand-edited minified JSON with no upstream generator

apps/web/public/atlas/data/atlas.json

The file is fetched at runtime by the client-side map (index.html: fetch('data/atlas.json')) and is hand-maintained as a minified single-line blob (~900 KB). There is no build script that produces atlas.json from a more readable source. This is an established pattern in this repo (three prior commits, all hand-edits), so the practice is intentional — but it does mean future edits (accent corrections, polygon updates) remain error-prone without a canonical readable source or prettified version under version control.

Spanish accent corrections align with es-MX conventions

apps/web/public/atlas/data/atlas.json

All nine corrected labels now carry their proper orthographic accents per Real Academia Española and es-MX norms (Eólica, Hidroeléctrica, Geotérmica, Termoeléctrica, Carboeléctrica, Turbogás, Combustión interna, Cogeneración, Baterías). The unchanged labels (Fotovoltaica, Nuclear, Ciclo combinado) require no accent. This is fully consistent with the project's es-MX primary language convention and the brand-guidelines requirement for correct Spanish.

Type code keys (T object keys) are unchanged — no API or consumer breakage

apps/web/public/atlas/data/atlas.json

Only the display string at T[code][0] changed; the code keys themselves (pv, wind, hydro, geo, th, coal, tg, ci, cog, bat) are unchanged. The map renderer and build-atlas-csv.mjs both key on the code, not the label, so no lookup breakage is introduced.

/atlas route missing from marketing E2E smoke

e2e/web/marketing.spec.ts:17

The /atlas route is a live public page (in the sitemap at priority 0.85) but is absent from the ROUTES array in e2e/web/marketing.spec.ts. The existing smoke only asserts the page returns <400 and renders an <h1>, which would catch a crash caused by a malformed atlas.json (e.g. invalid JSON parse breaking the iframe load or the page's own rendering). Adding /atlas to that array costs one line and gives a regression signal for any future data corruption. The spec's comment about missing /developers and /blog explicitly anticipates this pattern — /atlas is built and should be included.

No schema validation for atlas.json in CI

apps/web/public/atlas/data/atlas.json

atlas.json has a stable, well-defined schema (top-level keys P, H, R, T, REG, Z, TZ, OL, RP with typed substructures). There is no automated check — not a JSON Schema assertion, not a Zod parse, not a CI step — that validates required keys exist, that T entries have the expected {color, label} shape, or that RP polygon arrays contain numeric coordinate pairs. A future edit that accidentally drops a required key or produces malformed coordinate arrays would ship silently; the only signal would be a visual regression on the live map iframe. Given the file is hand-edited (as this PR demonstrates), a lightweight schema smoke in the pr-checks.yml validate job (e.g. `node -e 'const d=require("./atlas.json"); assert(d.T && d.RP && d.P)'`) would catch structural corruption without significant overhead. The risk is low because the change is editorial (accent fixes + polygon removal), but the gap is real for future edits.

centrales.csv not regenerated after label fixes — stale unaccented tech names in public export

apps/web/public/atlas/data/atlas.json

The build script apps/web/scripts/build-atlas-csv.mjs reads atlas.json as its source of truth and derives the 'tecnologia' column in centrales.csv from atlas.T labels. The commit updated atlas.json labels with correct accents but did not re-run `pnpm --filter @batu/web atlas:csv`. As a result, centrales.csv (the committed public open-data export) still contains the old unaccented forms: 'Eolica' (67 rows), 'Hidroelectrica' (57), 'Combustion interna' (62), 'Turbogas' (44), 'Cogeneracion' (41), 'Termoelectrica' (33), 'Geotermica' (18), 'Baterias' (5), 'Carboelectrica' (2). These inconsistencies are user-visible in the downloadable CSV. The fix is simply running `pnpm --filter @batu/web atlas:csv` and committing the regenerated file — the script comment explicitly says to re-run 'after editing the data'.

CEGEN (s/ubicar) label is ambiguous — plants have coordinates despite the 'unlocated' annotation

apps/web/public/atlas/data/atlas.json

The 'cegen' type label reads 'CEGEN (s/ubicar)' where 's/ubicar' is shorthand for 'sin ubicar' (without location). However, all 46 CEGEN plants in the P array have valid geographic coordinates in the companion coordinates.json file (e.g., CEGEN CFE22 at [18.6021, -98.4657]) and region assignments in REG. The annotation appears to convey uncertainty about classification/technology type rather than missing location — but a future data editor could misread it as meaning these plants lack coordinates and attempt to add them. Consider clarifying the label to something like 'CEGEN (tipo incierto)' or adding a comment in the data to disambiguate.

Minified format is correct for this file size — no change needed

apps/web/public/atlas/data/atlas.json

At 901 KB minified vs 2.9 MB pretty-printed (3.2x ratio), keeping atlas.json minified is the right tradeoff for a served static asset. The file is manually maintained (no generation script), so the single-line format does impose an edit cost, but the polygon data (RP arrays) makes pretty-printing impractical anyway. No action needed.

Case consistency: sentence case on multi-word labels is correct Spanish typography

apps/web/public/atlas/data/atlas.json

'Ciclo combinado' and 'Combustión interna' use sentence case (only first word capitalized) while single-word labels use title case (Fotovoltaica, Eólica, etc.). This is not an inconsistency — Spanish typography convention for compound common nouns in a list uses sentence case. 'Ciclo Combinado' with a capital C on 'Combinado' would be non-standard. No change needed.