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

## Fork & rewrite status (2026-10-12)

- **Local modernized fork exists** at `~/projects/comuline-api` (branch `refactor/krl-current-api`): env token (`KAI_BEARER_TOKEN`), `/schedules` + configurable endpoints, hardened sync with per-station failure reports + station normalization, daily scheduling (GitHub Actions + systemd templates), freshness surfaced at `/status`. Verified locally including Postgres end-to-end (113 stations / 1,045 schedules, idempotent re-run). Evidence: `VERIFICATION.md` in the fork.
- **Private for now** — upstream has no license file; do not publish without permission.
- **User plans a full rewrite with a different system design** later; the fork is the working reference implementation until then.

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