implemenation on the bot

src/pages/nearle/dispatch/CLAUDE.md

@@ -9,20 +9,30 @@ 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.
 
+**The windows live in `utils/batchBucket.js` now.** Dispatch derives `BATCHES_DEFAULT_RAW` from it and `deliveries.js` derives `BATCH_OPTIONS` from it, so the two pages cannot disagree by construction. Only presentation (colour, icon) is page-local.
+
 ```js
-// BATCHES_DEFAULT_RAW — half-open [startHour, endHour) in LOCAL time, not UTC
+// utils/batchBucket.js — 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
-  { id: 'evening',   startHour: 16, endHour: 19 }    // 4 PM – 7 PM
+  { id: 'morning',   startHour: 0,  endHour: 9  },   // 12 AM – 9 AM
+  { id: 'afternoon', startHour: 9,  endHour: 16 },   // 9 AM – 4 PM
+  { id: 'evening',   startHour: 16, endHour: 24 }    // After 4 PM
 ]
 ```
 
-**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.
+**They cover the whole day, and that is load-bearing.** They used to be 0–8 / 9–12.5 / 16–19 — 14.5 of 24 hours, with gaps at 8–9 AM, 12:30–4 PM and after 7 PM, documented here as intentional. They weren't wrong when they were written: they came from jupiter, where bucketing ran on `expecteddeliverytime` and they described **promised delivery slots**, which really did cluster.
+
+This app buckets on `orderdate` — when the order was *placed* — and orders are placed all day. A booking created at 2:43 PM landed in the 12:30–4 PM gap, belonged to no batch, and disappeared from every batch filter on both pages. On Dispatch, where batches are the primary navigation, that made the order invisible entirely. 40% of the clock was a black hole.
+
+Each window now runs to the start of the next. **Every start hour is unchanged, so the change is strictly additive** — verified exhaustively minute by minute: zero rows move between batches, 570 minutes that previously had no batch now have one, and no minute belongs to two.
+
+If you ever move bucketing back to a promised-delivery field, the clustered windows become correct again — but then re-read the table below first, because that field was already tried and rejected for a different reason.
 
 ### Time-field selection (`BATCH_TIME_FIELD`)
 Fixed at `'created'` → bucket key is `['orderdate']` (the booking's `createdat`). `deliveries.js` hardcodes the same key in `BATCH_TIME_KEYS`. If you change one, change both — they read each other's bucketing.
 
+Note the five `TIME_FIELDS` entries that are now inert: this backend emits only `createdat`, `updatedat` and the SLA estimate, so `acceptedtime` / `starttime` / `arrivaltime` / `pickuptime` / `deliverytime` are always undefined. They're harmless while `selectedTimeField` is a constant — but if the operator-facing dropdown is ever resurrected, five of its eight options would silently bucket nothing.
+
 This is a constant, not state. The operator-facing time-field dropdown and the slot-hour editor have both been **deleted** (they were commented-out dead JSX whose setters nothing called). Don't resurrect either without re-reading the ban below.
 
 **Three fields have been tried here. Two were wrong:**