Documents rider Telegram flows and the API/events this client needs so the shared backend can consolidate later. Co-authored-by: Cursor <cursoragent@cursor.com>
2.0 KiB
Gishen Dispatch Bot
Telegram bot for drivers / riders. Replaces a dedicated rider mobile app for v1.
When Ops assigns a trip on the Admin Dispatch Board, this bot pushes the trip manifest to the driver’s Telegram chat, collects status updates via inline buttons, and captures proof of delivery (photo + recipient name). Status writes back to the shared backend so the Dispatch Board and customer order tracking stay in sync.
Docs
| Doc | Purpose |
|---|---|
| docs/FEATURE_BRIEF.md | What this bot does (acceptance inventory) |
| docs/BACKEND_SPEC.md | Living backend needs: events, endpoints, payloads, auth |
Standing rule — backend spec
Whenever we add or finalize anything in this repo (feature, flow change, scaffold, payload tweak), update docs/BACKEND_SPEC.md in the same change set and append a changelog entry. If there is no new backend need, record no backend delta for that change so the sheet stays the single source of truth.
Stack (intended)
| Layer | Choice |
|---|---|
| Runtime | Node.js |
| Bot framework | grammY |
| Transport | Telegram Bot API, webhook mode |
| Shared API | One platform backend (not implemented in this repo) |
Scaffolding comes after the backend spec sheet stabilizes with the other client repos.
In scope
- Trip / manifest push on assign
- Inline status: picked up → en route → arrived → delivered / failed
- Proof of delivery (photo + recipient name)
- Real-time status write-back (via shared backend)
- Driver identity = Telegram account, enrolled by Ops (no separate login)
Out of scope
- Admin Dispatch Board UI (Admin Console)
- Customer Telegram notifications / Mini App (Ecom)
- Health/medical modules, community, AI Phase 2+ (platform exclusions)
- Continuous live GPS heartbeat in v1 (poor fit for chat UX; see open items in the backend spec)
Remote
https://gitea.yaltopia.com/Gishen/Gishen-Dispatch-Bot.git