End-to-end test run — 5 September 2026

Two Android emulators (rider on emulator-5554, driver on emulator-5556) driven against the live stack at api.ridekit.dev, with the admin panel at demo.ridekit.dev. Not a seeded localhost, not mocks.

Every screen was driven by ELEMENT (resource-id / accessibility label) rather than by pixel coordinates, so a layout change breaks the run loudly instead of tapping the wrong thing and photographing the result. Screenshots are in docs/media/.

Verified working, end to end

Bugs found and fixed in this run

1. Drivers silently received no offers. Socket.IO does not auto-reconnect after io server disconnect, which is exactly how the gateway rejects an expired JWT. The UI still said "You're online". Four rides died as "no drivers available" with a driver 464 m away.
2. A live Google Maps key was committed in both apps' generated AndroidManifest.xml — it would have shipped in every buyer's zip.
3. In-app chat had never worked. The route both apps call was guarded by dispatcher permissions and stamped every message support; rider and driver each got 403 on send and history, and the apps rendered an empty thread.
4. Bike and Auto did not exist as vehicle types, while both apps advertised them. A driver could not register a bike; a rider tapping "Bike" got cars.
5. A verified driver could not upload a document — the only control routed to onboarding, which for them renders "You're verified!".
6. Quick-reply chips rendered as 500px capsules (horizontal ScrollView with no flexGrow: 0 / alignItems).
7. My own regressions, caught on device: a socket-triggered token refresh raced the HTTP one and logged users out; the raise panel was hidden at the dead end; and it printed "New total: ₹0.00" beside a ₹1,295 fare.

Known gaps, not yet addressed

• Registration never asks for a name. The rider greeting reads "Rider" and the driver sees the sender as literally "Sender".
• Fares render with paise (₹110.53). Indian ride-hailing rounds to whole rupees on screen.
• Destination search is not biased to the rider's city — typing "Bandra" in Mumbai returns Bandra in Bihar and Madhya Pradesh above local matches.
• A live parcel is not auto-resumed. A passenger ride resumes into tracking on launch; a parcel is only reachable via Menu → My packages.
• A demo ride has been "in progress" for 47 days (#b7288340) and shows in the dispatch console.
• SOS and crash/reboot resume were NOT driven to completion. Both need a live trip on two devices at once, and by that point the machine was at load 20-60 with two emulators running: the driver emulator's Android framework crashed once (Can't find service: activity, recovered by restarting it) and uiautomator dump began timing out at 60s. Blind coordinate taps were tried instead and repeatedly hit "Go offline", which is worse than not testing — it produces confident-looking results that mean nothing. Stopped rather than push a machine that had already been flagged as overloaded.
• The videos in media/video/ capture failed attempts, not a completed ride, for the same reason. They should be re-recorded on a quieter machine, one emulator at a time if necessary.

Not reachable with this account

• Business / corporate rides — the menu row is gated behind ownsCompany, which the test rider is not. Correct behaviour, not a defect.

How to re-run

scratchpad/ui.py   <device> dump|tap|wait|type   # drive by element
scratchpad/walk.py <device> <app> <steps-file>   # walk screens, verify each rendered
admin-capture.mjs                                # Playwright over the live admin

Constraints learned the hard way: boot emulators one at a time (both plus a gradle build pushes load past 20 on 8 cores and uiautomator starts timing out); the dispatch radius is 5 km; the offer TTL is 15 s, so a UI dump between booking and accepting eats most of it.