Assistant — assign:
- Order step is a dropdown, not a typed booking number. Exact bookingid /
bookingno matches now win across the whole list before any substring
fallback; row order previously decided the winner, so a short numeric id
could substring-match a different booking than the one on screen.
- Rider step resolves by id or name, so answering by typing no longer
leaves __rider undefined and throws inside executeAssign.
- notified now reflects whether the push actually went out. It was
Boolean(rider.milerprofileid) — "has an id, assume they were told" — so a
notify returning 400 still reported "The rider has been notified."
- Batch assign removed. /hub/bookings/batch-assign is a hub-console
endpoint; an admin JWT is refused (403 on an empty body, so the gate is
on identity). It read as the fast path and could never run.
Assistant — repeat runs:
- Bulk create response is read at data.results, the shape the live endpoint
returns. Only the two flatter shapes were checked, so every bookingid was
discarded while the count came out right by accident.
- Repeat carries each order's previous rider and re-assigns on create, one
admin call per order, one push per rider. Confirm cards say so.
- Message ids are clock-seeded and healed on load; the counter restarted at
1 each session and overwrote itself, giving duplicate React keys.
- Successful writes invalidate the query cache, so the page behind the panel
stops serving rows cached before the write.
Date range picker:
- Fields seed from the range already in force instead of opening blank on a
filtered table.
- Start field takes max={end}; only the end had a bound, so an inverted
range could be emitted and filtered to nothing.
UI:
- Deliveries filters moved outside the table card.
- Side nav keeps one hairline; the border and box-shadow stacked into a
heavy edge.
- KPI gloss lines removed across orders, riders, tenants, customers, hubs,
vehicles, exceptions, app users, orders summary/details, riders summary
and profitability.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Both were found while re-checking the branch, not from a failing build —
each fails quietly and would have looked like "the bot just doesn't know".
riderLookup read `status`, `phonenumber` and `vehicletype` off a miler.
None of those fields exist: api.js documents the confirmed live shape as
`availabilitystatus`, `phone` and `defaultvehicletype`, and states outright
that no `status` field is present. So "where is rider Kumar" always rendered
"status unknown" with no phone and no vehicle. Now reads the real names and
adds the hub.
correctTypos could rewrite a named entity into a vocabulary word. It runs
before matching, and orderQuery extracts tenant/rider names from the
corrected text, so a tenant called "Partnerz" (one edit from "partners") or
"Ordero" (one from "orders") was silently renamed and then failed to
resolve — with no indication that a filter had been dropped. Words
following rider/tenant/hub/vehicle/customer/partner/named/called/for are
now protected from correction; genuine keyword typos still get fixed.
The comment above correctTypos already claimed names were never touched.
Nothing enforced it. The L2 composite-query work made the gap matter,
because before it entity names barely reached the matcher.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
CLAUDE.md for the assistant folder, plus the capability roadmap.
The rules worth reading before editing either file:
- `truncated` is not optional to handle; an intent that reads scan.rows and
ignores it reintroduces the silent under-reporting this replaced.
- Order status comes from utils/orderStatusGroups.js, not api.js's
Deliveries taxonomy, and the two must not be merged.
- State questions ("how many are assigned") must not default to today;
flow questions ("how many orders today") still do.
- orderQuery must not widen to claim single-dimension questions.
- Never put a React element in message state — localStorage round-trips it.
ROADMAP.md carries the analysis and the L0-L8 capability ladder, including
what is deliberately still out of scope: write actions pending a confirm
gate, and any LLM step pending a decision on where its key would live.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Data-layer work on the assistant, in the order it mattered.
Correctness first:
- getBookingsPage keeps the envelope's `total`/`page`. getBookings threw
them away, so no caller could tell a full result from a truncated one.
- Every booking read now drains pages up to a budget instead of taking page
one at the API's 1000-row cap. Past 1000 lifetime bookings, every count
and sum in this file silently under-reported while the source line beside
it still read "complete". Row order is detected per call, so a backend
that stops returning newest-first degrades to a full scan rather than to
a wrong answer.
- A capped scan now says "At least N", appends what it scanned versus the
total, and marks its source call as failed.
- Revenue excludes cancelled orders, sums every service option rather than
the first, and is labelled estimated — it is a quote, not settled money.
- A strong order reference that isn't found is answered "I couldn't find
it" instead of falling through to a broader intent, which used to answer
"142 orders created today" to a question about one order.
Then agreement with the Orders page:
- utils/orderStatusGroups.js is now the single definition of which raw
booking enums make up each status; orders.js builds its tabs from it and
the assistant matches against it. The assistant had been using api.js's
Deliveries taxonomy, which keeps miler_assigned on `pending`, so the
Orders page showed 19 Assigned while the bot answered 0. The two
taxonomies stay separate on purpose — Orders tracks the operator's
action, Deliveries tracks the rider's.
- A status question with no date named is no longer scoped to today. "How
many orders are assigned" describes the queue right now, which is what
the Orders page's tabs show; they apply no date filter either.
- The Orders header said "Today" over counts that were never date-filtered.
Corrected the label rather than adding a filter, since filtering would
hide currently-visible rows — a product decision, not a bug fix.
Then capability:
- delayedOrders answers "which orders are delayed" from the promised
delivery time. deliveries.js and Dispatch.js both rejected that field for
batch bucketing because an ETA is not the wave an order belongs to; that
reasoning does not carry over to lateness, where a promise that never
gets re-stamped is exactly the right baseline. If no order carries an
ETA it says so rather than reporting a reassuring "0 delayed".
- orderQuery composes status x batch x tenant x rider, plus rankings. It
claims a question only when two or more of those are present, so
single-dimension questions keep their proven intents. A date is not
counted as a dimension — counting it re-routed four working questions.
- An unresolved tenant/rider name falls through instead of having its
filter silently dropped, which was the original defect.
- orderLookup resolves the rider's name and reads the tracking trail
defensively, since that endpoint's response shape is undocumented.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Renames the operator assistant to "Doormile AI / Operations Copilot" and
moves it from a header Popover to a portalled slide-over panel.
- DoormileAI/ — trigger, panel, welcome, message, composer and shared
primitives. Assistant turns are deliberately NOT bubbles; that is what
keeps this reading as part of the dashboard rather than a bolted-on
chatbot.
- pageContext.js — route-aware suggested questions. Every suggestion is a
phrasing the matcher actually resolves; a chip that returns "I can't
answer that" is worse than no chip.
- DoormileAI.css — panel styling, animation, responsive and reduced-motion.
Selectors that style an Astryx Stack are written `.dai-root .x` because
`padding={0}` emits a StyleX atomic at the same specificity as a bare
class, so a single class can lose on stylesheet order.
- Messages are JSON round-tripped through localStorage, so icons are
referenced by key rather than stored as React elements — an element does
not survive the trip and the rehydrated value crashes the next render.
- Errors now render a polished state and log the real error to the console,
instead of surfacing raw API messages in a toast.
The route, sidebar entry and i18n key for the old standalone Assistant page
are removed with it — this is a header surface, not a page.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Hubs, Vehicles, App Users, Tripsheets, Exceptions, and Competitive Intel
had full CRUD support in doormileApi.js but no UI anywhere in the console.
B2C Customers had neither. Field bindings for Pricing/Vehicles/Tripsheets/
Exceptions/Customers are confirmed against live read-only API responses;
App Users' write body and both Competitive Intel resources (no documented
schema at all for competitor-branches/carrier-pricing) are still best-effort
guesses and unverified against a real write.
Routed under a new "Fleet & Ops" sidebar group except Customers, which sits
at the top level next to Pricing.
Retires REACT_APP_URL/URL2/URL3 in favor of REACT_APP_DOORMILE_URL across
every page (orders, deliveries, riders, tenants, pricing, profile, reports,
dispatch). Fixes several field-mapping and envelope-check bugs found along
the way, most notably that /admin/milers/:id routes (block, assign-vehicle,
edit, notify) key off milerprofileid, not userid, and that a miler's real
fields are phone/availabilitystatus/displayname, not contactno/status/
firstname+lastname (confirmed against a live read-only session).
Also fixes several silent-failure bugs uncovered during that audit: order
creation and order cancellation showed a success toast but gave no feedback
at all on failure (createorder1.js had a dead notifyadmin() call that left
the loading spinner stuck forever on every failed submit), and Tenants.js's
pricing/profile updates never surfaced a failed response to the operator.
The AI dispatch optimiser (routes.workolik.com/routemate.workolik.com) and
its jupiter.nearle.app delivery-commit call remain untouched by design —
separate solver service with no equivalent in the new API.
