sozerong/genuel

Purpose and Entry Points

This is a browser-based seat-map application with geospatial and solar-position logic, backed by Seoul stop data. The primary client entry point is public/index.html, which loads the application code in public/app.js. Deployment/platform metadata is defined in apps-in-toss.config.ts, while the repository also contains a standalone Node proxy at server/proxy.mjs.

Client Application Shell

The static frontend is organized as a small JavaScript application rather than a framework project:

• public/index.html provides the document shell.

• public/app.js coordinates UI state and feature modules.

• public/style.css defines the application presentation.

• public/manifest.json and public/sw.js establish installability/offline-service-worker boundaries.

The public directory is the deployable browser asset boundary; it should not depend directly on server-local files at runtime.

Geospatial and Solar Computation

Location and sunlight calculations are separated into domain modules:

• public/geo.js

• public/solar.js

• public/app.js

geo.js likely owns coordinate, route, or directional calculations, while solar.js computes solar state from location/time. Their results feed the application’s seat-selection or visualization decisions rather than being embedded in UI markup. The corresponding correctness boundary is covered by test/solar-geo.test.mjs.

Seat Map Presentation

Seat layout and seat-level rendering are isolated from the broader application flow:

• public/seatmap.js

• public/app.js

• public/style.css

seatmap.js is the likely boundary between computed travel/sun context and interactive seat-map UI. app.js should orchestrate data acquisition, selected trip/location/time state, solar/geo evaluation, and updates to this visual component.

Seoul Stop Data Pipeline

The repository ships a generated/static local stop dataset:

• server/data/seoul-stops.json

• server/data/build-seoul-data.py

• server/proxy.mjs

build-seoul-data.py is a data-preparation stage that produces or refreshes the Seoul stops artifact. The browser should consume data through static hosting or the proxy/API boundary, not invoke the Python generator. The checked-in JSON allows the application to operate without requiring live stop-data generation.

Proxy and External-Service Boundary

Network access is centralized behind proxy implementations:

• server/proxy.mjs

• reference/proxy.mjs

• public/app.js

The Node proxy is the intended server-side integration boundary for any upstream service, insulating browser code from cross-origin, credential, or upstream-response concerns. reference/proxy.mjs and reference/prototype.html appear to preserve an earlier prototype/reference implementation rather than form the main runtime path.

Runtime and Deployment Shape

The system has two material runtimes:

• Browser runtime: static assets under public/, including service-worker support.

• Node runtime: server/proxy.mjs for proxied network/data access.

Package execution and dependency wiring are defined by package.json and package-lock.json. Platform-specific application packaging/deployment is represented by apps-in-toss.config.ts. Environment-dependent proxy configuration is indicated by .env.example, keeping secrets and upstream endpoint configuration outside client assets.