Next steps / open questions

Open questions

~~Why did comuline's sync stop?~~ Mostly resolved (see comuline-krl-data/analysis timeline): operations stopped ~2025-03-30 — no in-repo automation existed to fail (external/manual runs ended), and upstream drift since (endpoint renames, yearly token rotation) went unmerged. Residual: whether the author revives it (contactable via comuline-krl-data/sources).
Current shape of the upstream partner API's data model (krl-station, schedule) — unverified; no credentialed call was made.
Live KRL tracking sources: community trackers claim ~30 s updates (trackmycommuter, krljakarta.com, botkita). Where do their positions come from? A dedicated audit would be its own subtopic (KRL realtime — likely a different upstream than schedules).
MRT Jakarta / LRT Jabodebek data sources (jakartamrt.co.id API was referenced by one community project) — candidates for umbrella subtopics.

Comuline API: frozen data; treat as reference only. Add freshness checks; do not build a "current timetable" product on it without another source.
Upstream partner API: authenticated; using the repo-published token is not acceptable use. Legitimate access = partner agreement.
Both are informal dependencies that can change or disappear without notice.

Freshness monitor for the comuline API (alert when data updates — would signal the project waking up or a re-sync).
Multi-modal view: join transjakarta-live-data/index + KRL schedules to prototype Jabodetabek trip planning.
If current KRL timetables are needed long-term: evaluate official channels (KAI Commuter app/website) or pursue partner access properly.