updates on the ui design and desing updates

src/pages/nearle/dispatch/CLAUDE.md

@@ -10,7 +10,7 @@ Rules for editing `Dispatch.js`, `Preview.js`, `CompareDataPanel.js`, and `dispa
 Dispatch.js defines the canonical batch hour ranges. `deliveries.js` mirrors them — **the two pages must agree on which batch a given row belongs to**, otherwise the same delivery shows up in one batch on one page and a different batch on the other.
 
 ```js
-// BATCH_OPTIONS — half-open [startHour, endHour) in LOCAL time, not UTC
+// BATCHES_DEFAULT_RAW — half-open [startHour, endHour) in LOCAL time, not UTC
 [
   { id: 'morning',   startHour: 0,  endHour: 8  },   // 12 AM – 8 AM
   { id: 'afternoon', startHour: 9,  endHour: 12.5 }, // 9 AM – 12:30 PM
@@ -21,11 +21,19 @@ Dispatch.js defines the canonical batch hour ranges. `deliveries.js` mirrors the
 **Gaps are intentional** (8–9 AM, 12 PM–4 PM, after 7 PM). Rows that fall in a gap belong to no batch — *not* to the nearest one.
 
 ### Time-field selection (`selectedTimeField`)
-Default `'assigned'` → bucket key is `['assigntime']`. Other options use other timestamp fields (`pickedtime`, `deliverytime`). If you add a new time field option, make sure `deliveries.js` is updated too — they read each other's bucketing.
+Default `'due'` → bucket key is `['expecteddeliverytime']` (the booking's promised delivery slot, `serviceoptions[0].estimateddeliveryat`). `deliveries.js` hardcodes the same key in `BATCH_TIME_KEYS`. If you change one, change both — they read each other's bucketing.
+
+### ⛔ Never bucket on `assigntime`
+It is **not** an assignment time. The Doormile bookings feed has no assignment timestamp, so `api.js` maps `assigntime` to the booking's `updatedat` — its last-modified column. Any status change, parcel scan, payment or pickup-complete re-stamps it.
+
+Bucketing on it (which both pages did until this was found) means an order silently leaves the batch it belongs to and joins whichever window contains the current clock time, so the same orders appear under Afternoon and then Evening on the same day. The Dispatch page's 15-second poll makes the counts move on their own.
+
+Displaying it as a "last updated" stamp is fine — that's all the reports use it for. The true assignment record lives on `bookingassignments`, reachable only per-booking via `GET /admin/bookings/:id/track` (`{ booking, assignments[], riders[] }`); its `assignments[]` has not been observed non-empty, so it is not a verified source yet. If the backend ever exposes an `assignedat` on the list feed, that becomes the correct bucket key.
 
 ### Don'ts
 - Don't bucket in UTC. Use `dayjs(t)` (local), not `dayjs(t).utc()`. The original deliveries page had a UTC bucketing bug that hid orders mid-day; the multi-line comment above `getRowBatchId` in `deliveries.js` (search for `getRowBatchId`) explains it. Don't reintroduce.
 - Don't bucket bare `YYYY-MM-DD` strings — they parse to midnight and mis-bucket into Morning. Skip them.
+- Don't bucket on a timestamp that the backend re-stamps. See above.
 - Don't add a 4th batch without updating both pages and confirming with the backend what the new boundary means for assignments.
 
 ---