Analysis — how comuline works

Pipeline

Sync (daily cron, as designed): comuline/api/src/sync/station.ts fetches {KRL_ENDPOINT_BASE_URL}/krl-station; schedule.ts then iterates all stations in batches of 5 (5 s sleep between) — CORS OPTIONS preflight, then GET /schedule?stationid={id}&timefrom=00:00&timeto=23:00. Requests carry browser-like headers plus a hardcoded bearer token, because the upstream is an authenticated partner API.
Transform: stations → st_krl_<id> records (upstream WIL entries filtered; airport station BST manually added); schedules → sc_krl_<station>_<train> rows with origin/destination station IDs resolved by name, departs_at/arrives_at timestamps, and line color; upserted into Postgres.
Serve: Hono API on Cloudflare Workers (Neon Postgres + Upstash Redis per-station read cache) exposes clean JSON with an OpenAPI spec; web/native apps consume it.

KRL_ENDPOINT_BASE_URL = https://api-partner.krl.co.id/krl-webs/v1 (from the repo's .dev.example.vars).

Station: { uid, id (e.g. MRI), name, type (KRL|LOCAL), metadata.origin.{daop,fg_enable}, active }
Schedule row: { id, station_id, station_origin_id, station_destination_id, train_id (e.g. 1448B), line ("COMMUTER LINE BOGOR"), route ("JAKARTAKOTA-DEPOK"), departs_at, arrives_at, metadata.origin.color }
Route view (/v1/route/{train_id}): ordered stop sequence (station name + departure time) for one train.

API live; 113 stations served. Row counts sampled: MRI 1,045 · DP 730 · CLT 683 · JAKK 367 · BOO 341 · TNG 84 · BEK 0 (station present, no schedule rows).
Freshness: the newest updated_at values are bulk 2024-11-13 and partial re-sync 2025-03-30; nothing newer. Repo activity stops the same month (api last push 2025-03-30). Conclusion: the daily cron is not currently running; the data is a frozen snapshot (~18 months old as of this audit).
Scope of that staleness — comuline's replicated copy only: the official upstream API (api-partner.krl.co.id) was not freshness-assessed (no credentialed access, by design). A frozen replica does not imply a broken upstream. Timeline note: the hardcoded token remained valid until 2025-08-02, so token expiry does not explain the ~2025-03-30 sync stop; comuline's own sync mechanism stopping does (inferred cause — external scheduler/manual runs; no cron trigger exists in the repo's worker config or workflows).
No realtime tracking: no position/GPS data in the bundle or API. The product is schedule lookup with locally saved stations.

Upstream api-partner.krl.co.id was probed once without credentials (returned 404) to characterize the auth wall.
No calls were made using the token published in the public repo. The token is not reproduced in this vault.
No attempts to bypass auth, rate limits, or access controls.

Established: pipeline structure and architecture (public source + live API); coverage counts; staleness timestamps; absence of live tracking; upstream URL and auth wall.
Inferred: why the sync stopped (project dormancy vs token expiry vs upstream change — not observable from outside); whether the upstream data model changed since.

Evidence archive: workspace/comuline-captures/ — page HTML + headers, web bundle, live API samples (stations.json, sched_MRI.json, openapi.json), sync sources (bearer token REDACTED in the archive copy), dev.example.vars.