# Next steps / open questions

## Open questions

- ~~Why did comuline's sync stop?~~ **Mostly resolved (see [[comuline-krl-data/analysis|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|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.

## Risks

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

## Ideas

- 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|TransJakarta live feed]] + 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.