claude/vigorous-stonebraker-41cc2d

Approx array length mismatch risk — no bounds guard

apps/web/public/atlas/index.html

If C.approx exists with fewer than 537 entries (partially generated JSON), C.approx[i] returns undefined for out-of-bounds indices — silently treating those plants as non-approximate. Current data has 537 entries matching plants, so this is not a present bug, but a truncated approx array would go undetected.

approx stored as 1/0 integer, popup tests truthiness — consistent

apps/web/public/atlas/index.html

Feature property is coerced to 1/0. MapLibre expression ['==',['get','approx'],1] correctly checks integer 1. Popup uses p.approx which is truthy for 1 and falsy for 0. Both access paths consistent with stored type — no bug.

Boolean encoded as 0/1 int in JSON data file (intentional)

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

The approx array uses 0/1 integers rather than native JSON booleans. This is intentional to satisfy MapLibre's == expression which compares against integer literal 1. The JSON and consuming JS agree — no action needed unless the data file is consumed by other tooling expecting booleans.

Null/missing approx array edge case is untested but correctly guarded

apps/web/public/atlas/index.html

The expression (C.approx && C.approx[i]) ? 1 : 0 correctly handles C.approx being undefined/null. If a Playwright smoke test for the atlas page is ever added, verifying the page renders without JS errors when approx is absent would be a useful regression guard.

No test framework exists for the atlas static HTML file

apps/web/public/atlas/index.html

The atlas is a standalone static HTML/JS file with no module system. The repo uses Vitest (unit) and Playwright (E2E) but neither covers this file. Inline <script> blocks cannot be imported by a test runner without significant scaffolding. Consistent with how the rest of the atlas has been maintained.

Atlas route not covered by existing E2E marketing smoke test

The marketing smoke spec covers /, /calculator, /contacto, /demo. The atlas at /atlas/index.html (static file, not a Next.js route) is not included. A simple Playwright navigation check that the atlas loads without JS console errors would catch inline-script regressions. Pre-existing gap.

Parallel top-level array vs. inline property increases fragility

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

The approx flags live in a separate top-level array indexed in lockstep with plants. If plants are ever reordered or a plant inserted mid-list, the arrays silently desync. Embedding approx directly on each plant object ({lat, lng, approx: true}) would make data self-consistent and remove the index-coupling assumption. Tradeoff: ~147 extra JSON fields (negligible for a static file).

Redundant double-guard on approx lookup

apps/web/public/atlas/index.html

The expression (C.approx&&C.approx[i])?1:0 checks C.approx twice. Since C.approx is a fixed top-level array, a single optional-chain C.approx?.[i]?1:0 is cleaner and equivalent.

Boolean stored as 0/1 rather than native boolean with MapLibre boolean expression

apps/web/public/atlas/index.html

MapLibre GL supports ['boolean',['get','approx'],false] natively. Storing the value as a boolean (!!C.approx?.[i]) and using ['boolean',['get','approx'],false] in the expression would eliminate the int coercion step and make intent clearer.