# Analysis — how comuline works

## Pipeline

1. **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.
2. **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.
3. **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`).

## Data model (public API)

- **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.

## Observed state (2026-10-12)

- 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.

## Boundaries respected (deliberate limits)

- 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.

## Confidence

- **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.

## Artifacts

- 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`.