Redesign: Poppins, a two-step destination, and a splash that says what the app does

The effort pass, end to end. Every screen was run through one test — if I
remove this sentence, does the customer make a worse decision? — and the parts
that failed it are gone.

The flow

  Home ▸ BOOK ▸ Where is it going? ▸ When shall we collect? ▸ details ▸ booked

BOOK opens a sheet, not a form. The destination is browsed state-then-district
because a flat list of every serviceable district survives twelve and not
sixty, and search cuts across states because somebody who knows they are
sending to Chennai should not have to know which state it is in. Districts
multi-select, but only where the server allows it: BookingLimits advertises
maxDestinations: 1 until the Miler build keys on consignmentid, and a sheet
that ignored that would sell a booking the network cannot complete.

The pickup window is now a step the customer answers rather than a slot chosen
for them. A pickup window is a promise about somebody's afternoon.

What the screens stopped saying

Home lost the orb caption for returning customers and a four-cell live card.
Send lost the city strip, both address fields, the optional disclosure and
three sentences about charging — the route, the packages and the button are
what is left. Tracking lost a radar with a bike in it, a Milers-in-your-zone
count, a "Step 2 of 7" and a sentence describing the screen you were looking
at. The window sheet lost "Fastest pickup", "4 Milers nearby" and "Relaxed
evening handover".

Type

Poppins, which has no variable release — four static cuts, and the sans styles
set fontWeight alone because fontVariations on a static font is ignored in
silence. Every weight dropped a step and the tracking went deeper: Poppins is
built on near-circles and carries more ink than the humanist faces before it.

Objects

One lit sphere on Home, and the primary button now takes its gradient and rim
because a committing action that is not lit like the hero reads as a different
material. The tracking rail's connector is crimson as far as the parcel has
come, so the line is the progress bar. Confirmation is a white tick on green:
crimson is this app's action colour and that screen has nothing left to do.

Bugs found on the way

The OTP screen dropped digits. Four fields passing focus along lose a keystroke
that arrives mid-transition, so "1234" became "124" and the screen answered
"That code did not match" — blaming the customer for its own race. One field
now, four boxes that only draw.

Nothing ever asked for the customer's location: detectPickupLocation was the
OTP screen's job, so a restored session or an auto-login never triggered the
permission prompt and the pickup map had nothing to centre on.

The launcher icon and both splash screens pointed at a house drawn as two
vector paths — a placeholder that shipped.

The splash clock started when the widget was built rather than when it was
visible, so the truck got 0.45s of a 1.8s beat behind Android's own splash.
It waits on waitUntilFirstFrameRasterized now, raced against a timeout so a
binding that never reports one cannot strand the app.

Also: design/screens/ holds all 19 screens under readable names, tool/ has the
scripts that refresh them and rebrand the Lottie, and DESIGN.md is current.

flutter analyze clean. 88 tests, 1 skipped.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01EqVJPB9B4QuieZnBAAKgYQ

README.md

@@ -170,7 +170,7 @@ Play does not filter the app off devices without it.
 ```bash
 flutter pub get
 flutter run                       # any connected device or simulator
-flutter test                      # 79 tests covering the whole flow
+flutter test                      # 88 tests covering the whole flow
 ```
 
 `flutter run` talks to `https://api.doormile.com/api/v1`. Point it somewhere
@@ -180,6 +180,25 @@ else with a define:
 flutter run --dart-define=DM_API_BASE=https://<staging-host>/api/v1
 ```
 
+### Which build am I in?
+
+Every debug launch prints it as its first line:
+
+```
+[BUILD] DEV DATA (offline) · staging · no network      ← the fake, any code works
+[BUILD] staging · https://api.doormile.com/api/v1      ← the real server
+```
+
+Check that line before anything else. The two builds are identical on screen,
+and the whole reason the first offline mode was deleted was that nobody could
+tell which one a handset was running. The Account screen says the same thing
+under **BUILD**, but a build that cannot get past the login screen cannot show
+you the Account screen — which is exactly when you need to know.
+
+**`[API] 401 …/auth/otp/verify · invalid_otp` means you are on the real server**
+and it refused the code. `1234` is not a real code; only the offline build
+accepts anything. See below.
+
 ### Signing in for development
 
 A shipping build has **one** API implementation, `LiveDoormileApi`, and it talks
@@ -194,10 +213,13 @@ in:
 
 ```bash
 flutter run --dart-define=DM_MOCK=true
-# login screen → 9876543210 → 1234 → in.
-# add --dart-define=DM_DEV_LOGIN=true to skip the login screen entirely.
 ```
 
+It opens **straight on Home**, already signed in as Joe Oommen — there is no
+server to refuse anybody, so stopping at a login screen would ask for a phone
+number and a code that mean nothing. Sign out and you get the real entrance,
+where any 10-digit number and **any 4-digit code** get you back in.
+
 This swaps in `DevDoormileApi`: in-memory serviceability, slots, fare and
 bookings, so you can walk signup → book → track without a backend. **A booking
 made here stays on the device — it reaches no server and no admin console.** The
@@ -212,6 +234,21 @@ flutter run --dart-define=DM_DEV_TOKEN=eyJ... \
             --dart-define=DM_DEV_REFRESH_TOKEN=...
 ```
 
+**Real sign-in, no login screen** — runs the actual OTP request and verify pair
+at launch, so what it ends up holding is a token the server issued and a
+booking it makes reaches `pickupbookings` and the admin console:
+
+```bash
+flutter run --dart-define=DM_LOGIN_AS=9876543210 \
+            --dart-define=DM_LOGIN_CODE=<a code the server will accept>
+```
+
+The code has to be one the server will take. Two ways to have one: set
+`CX_STAGING_OTP` on a non-production backend (a fixed code, refused outright
+when `ENV=production`), or read the code the backend logged — with no SMS
+gateway registered its `logSender` writes every code to the application log and
+reports the send as successful.
+
 ### Walking a booking through its stages
 
 Against dev data, the tracking screen's stepper walks the in-memory booking.