Current architecture and feature summary

MetroMove Current Architecture and Feature Summary

All ride-status transitions are written directly to the online application API. There is no local event queue, durable offline store, or reconnect synchronization. A failed request remains only in the current screen state and is lost if the application restarts.

SMS one-time-password onboarding is designed around a paid external messaging provider. The implementation has no email fallback, offline code, delivery-cost cap, or retry budget.

The driver profile contains a single isVerified boolean. Document submission, review states, reviewer assignment, rejection reasons, and verification audit history are not implemented.

Wallet records store the current balance and a latest-transaction description. They do not preserve immutable transaction events, adjustment reasons, actor identity, or a reconciliation ledger.

The rider interface exposes cancellation before driver matching. The service contract does not define permitted cancellation transitions after matching or after a driver starts toward pickup.

Support requests arrive in a shared email inbox. The product has no incident severity, escalation schedule, assigned incident owner, after-hours rotation, or response target.