Replace Rides pairing with account-backed authentication and dispatch

[Landseer100]

Builds on #3; keep that hosted-service layer below this change.

Replaces native pairing with email/password registration and sign-in, persisted rider/driver profiles, Keychain sessions, and revocable sign-out. Account roles come from the database, and drivers supply vehicle details. Convex dispatch connects actual users, enforces exclusive assignment across riders, isolates histories and service-area offers, and retains durable request idempotency with bounded snapshots. Legacy room APIs remain compatible.

Removes customer-facing demo badges, invitation controls, fake ratings/balances, and visible test banners. Unavailable payments, payouts, GPS, calling, and identity verification stay explicit in their contextual screens. Revyl hooks register isolated database users rather than pairing invitations and keep private session values out of inherited launch settings. Eats behavior is unchanged.

Verification

• The existing production Convex project has the account/dispatch implementation deployed. All 120 backend tests, TypeScript checking, audit with zero vulnerabilities, six configuration-isolation tests, and eight account-setup tests pass.
• At 5f3de0b, Rides iOS CI executed 51 core tests in Debug, 47 in Release, and 52 arm64 simulator XCTest cases, including Keychain persistence; the log ends with TEST EXECUTE SUCCEEDED. All current CI check contexts pass. The final-head Rides Proof of Changes is Ready with no defects in its exercised single-rider account/request/cancellation flow. Password submission, cold-launch restoration, and two-phone dispatch are covered by the separate manual native checks below. Eats passed its regression flow but reports partial coverage of this Rides-focused diff.
• Seven production multi-client checks covered account authentication/revocation, database identity, subscriptions, fares/idempotency, exclusive acceptance, isolation/restoration, chat/lifecycle/rating/tip preference/cancellation, and sign-out.
• Two Uber-account iOS phones on build 30497455-5e81-4acf-bc28-5b277425095b verified requesting, acceptance, both clients' cold-launch restoration, two-way chat, arrival/start/completion, five stars and a $3 unpaid tip preference, persisted $21.40 totals, and rebooking/cancellation. Both phones were signed out and released; the driver was taken offline.
• Ordinary native rider signup exposed null optional vehicle fields being rejected. Six regressions reproduce the boundary, and the deployed fix accepts absent/null rider details while retaining driver validation. The same native signup then passed registration, cold launch, sign-out, and password sign-in.

Eats and Rides GitHub automation remains in Revyl Benchmarks by request. Both existing project/app configurations, Benchmarks resources, and the original API key are unchanged. The Uber Revyl account is not connected to GitHub, and that migration is no longer being pursued. The manual Uber-account validation builds did not move repository authorization or automation. Manual native verification is not an automatic account Proof of Changes verdict.

Native evidence

These screenshots are from the actual account-backed build; private emails, passwords, session values, and launch links are excluded.

Normal account sign-in

Rider home without pairing controls

Database-backed driver acceptance

Shared account chat

Persisted trip receipt

[revyl]

Preview builds

5f3de0b1

Project: uber-eats-clone

Managed via .revyl/config.yaml (config-as-code).

Build Target	Status	Details	Updated (UTC)
Uber Eats Clone iOS (iOS)	🟩 Ready · 1m 05s	Open preview · View logs	2026-10-19 19:18

---

Proof of changes

Target	Status	Details	Updated (UTC)
Uber Eats Clone iOS (iOS)	🟦 Partial coverage	View proof logs	2026-10-19 19:30

---

Findings

🟩 No defects found in the exercised changes.

Open this build in Atlas → Explore screenshots, findings, and resolution history.

---

iOS · Uber Eats Clone iOS

Verification confidence · 1/5

exercised the required Eats regression flow; account-backed Rides authentication and dispatch require the separate apps/rides target.

What this proof covered

Change	Result
Configured Eats session regression: bypassed Home launch	Opened Home with “Revyl sign-in accepted · Local buyer.”
Configured Eats cart/order regression	Selected a required size for Garlic Fries, added it to cart, opened cart/checkout, and confirmed the offline simulated order with no real payment or restaurant order.
Configured Eats navigation regression with cart contents	Home, Browse, Orders, and Account each remained reachable while the one-item cart stayed visible.

Out of reach

• Rides email/password registration, sign-in, Keychain session restoration/revocation, database roles, and driver vehicle details — this is the Eats iOS build; those screens live in the separate Rides target.
• Rides Convex dispatch, exclusive driver acceptance, rider/driver isolation, history, chat, lifecycle, ratings, tips, and cancellation — requires the Rides app plus separate rider/driver account state and service-area fixtures.
• Rides session-hook account setup and Rides CI/backend test coverage — scripts, server behavior, and CI have no visible result in this Eats device build.

To make this provable

• Start a Rides device from apps/rides/.revyl/config.yaml using its Rides build and the account-session hook; exercise registration/sign-in and cold-launch/sign-out flows there.
• Provide two isolated Rides sessions backed by a rider account and an online driver account in the same service area, then drive the dispatch lifecycle between them.
• Run the Rides backend/configuration test jobs in the repository CI (or present their results in the Rides proof) for the hook and server-only changes.

What we exercised

Pass — build ad42cd51-0298-44bc-b97c-1be8c93fc642, app commit 5f3de0b1e0eff8d76411a45cfb285b022256e1c7, iPhone 17 Pro Max (iOS 27.0). The configured Eats build bypassed onboarding to Home, kept a customized cart item while each tab remained reachable, and completed an offline simulated order. The diff’s product changes are Rides/Convex changes, so none of those changed behaviors are present in this Eats binary.

---

iOS · Uber Eats Clone iOS · Evidence

Full step-by-step report and session video — session 6c217af9-efee-4442-b7e3-6fb257d65f8e

Start state	Customization	Cart review
Demo order confirmed

_{Captured by Revyl · See how Revyl works →}

---

Project: apps/rides

Managed via apps/rides/.revyl/config.yaml (config-as-code).

Build Target	Status	Details	Updated (UTC)
Uber Rides Demo iOS (iOS)	🟩 Ready · 2m 14s	Open preview · View logs	2026-10-19 19:19

---

Proof of changes

Target	Status	Details	Updated (UTC)
Uber Rides Demo iOS (iOS)	🟩 Ready	View proof logs	2026-10-19 19:31

---

Findings

🟩 No defects found in the exercised changes.

Open this build in Atlas → Explore screenshots, findings, and resolution history.

---

iOS · Uber Rides Demo iOS

Verification confidence · 3/5

exercised the core single-rider account and cancellation paths; a second real driver and secure disposable credentials/backend harness were unavailable for multi-client dispatch and full credential-lifecycle coverage.

What this proof covered

Change	Result
Account-backed fresh session	Opened directly at normal Rider Home with no pairing, invitation, role-switch, or test-banner surface.
Account registration/sign-in UI	Inspected rider registration, sign-in, and driver registration; selecting Drive exposes Vehicle and License plate fields.
Revocable account sign-out	Sign out returned the active rider session to the email/password sign-in screen.
Hosted rider dispatch	Selected Jo's Coffee, UberX, and Cash preference; confirming pickup reached “Finding your ride” and remained waiting for a driver rather than fabricating acceptance.
Cancellation/history	Cancelled the pending ride; Activity showed Jo's Coffee as $0.00 · Cancelled.
Account, Services, Activity, saved places, wallet	All were reachable after cancellation; saved places displayed locally and Wallet clearly stated that payments are unavailable/not charged.

Out of reach

• New credential submission, password sign-in, and cold-launch Keychain restoration: this session supplied its account through the authenticated preview hook and no safe disposable credentials were supplied for a second login cycle.
• Driver availability/acceptance, chat, arrival, start, completion, receipt, rating, and tip preference: require a separate real database driver account on a second Rides device in the same service area.
• Cross-user exclusivity, service-area/history isolation, bounded dispatch snapshots, idempotency conflict handling, and legacy room API compatibility: backend/multi-client behavior has no visible single-phone result here.

To make this provable

• Provide a securely injected disposable rider email/password plus a cold-launch reset action in the preview so registration, password sign-in, session restoration, and post-sign-out revocation can be driven without exposing credentials.
• Provision a second Revyl iOS device with a separately registered driver account in the same isolated Austin service area and driver vehicle details, then take it online.
• Add a backend integration-proof target that creates two riders and two drivers in controlled areas and reports idempotency, exclusive acceptance, snapshot bounds, and legacy-room assertions.

What we exercised

Exercised the account-backed rider flow on iPhone 17 Pro Max (iOS 27.0) using build c57b85a8-9c3b-4f0d-bef4-e6a4c6a13096 at app commit 5f3de0b1e0eff8d76411a45cfb285b022256e1c7. Pass: the fresh authenticated Rider Home, account UI, request/cancel dispatch flow, $0 cancelled history, explicit payment limitation, saved places, and sign-out all behaved as observed; no rider-facing defect was reproduced.

---

iOS · Uber Rides Demo iOS · Evidence

Full step-by-step report and session video — session 707859df-145c-4d14-a626-3cc0fe4b1a3e

Driver fields	Payment limitation	Hosted request
Zero-charge cancellation	Signed out

_{Captured by Revyl · See how Revyl works →}