Doormile/doormilxpress_astryx
2
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Milers rebrand, /doormile/home, and a set of console fixes

Browse Source 
Two bodies of work that arrived in one working tree and are intertwined in
four files, so they commit together rather than pretending to a split the
diffs do not have.

TEAM WORK (pre-existing in the tree, uncommitted)

- "Riders" -> "Milers" across en.json and ~20 pages. Done carefully:
  Deliveries.jsx checks BOTH prefixes ("Miler #" and "Rider #") so rows
  written before the rename still render, and routes and query keys stay
  rider*/riderssummary — renaming those would have broken bookmarks and
  cache keys.
- MileTruth assistant rework: rename from "Doormile AI", HStack composer,
  maximise/minimise/reset controls, open state persisted to localStorage.
- New /doormile/home landing page; / and /doormile now redirect there
  instead of /doormile/dispatch. AdminLayout nav restructured with icons
  and descriptions.

FIXES

Tab strip was unreachable (Deliveries: Delivered and Cancelled)
  The pill variant is one non-wrapping inline-flex row. Given less width
  than it needs, flex COMPRESSED it — 872px squeezed into 780px, truncating
  labels inside the buttons — and with nothing scrollable no gesture could
  recover the last two tabs. Four of six tab pages had each hand-rolled the
  same wrapper; Deliveries and CompetitiveIntel had not. Fixed in the
  component, so no page can forget it. Verified in a browser at the real
  content width: 102px of scroll range, "Cancelled" reachable. 11 tests.

Home.jsx crash: Cannot read properties of null (reading 'flow')
  Introduced by the change below, which made deriveVisualData return null.
  All 12 .flow/.table dereferences are now behind visual?. gates.

Home.jsx presented fabricated figures as live operations
  deriveVisualData keyword-matched the prompt and returned hardcoded values
  for whole topics — revenue as a flat Rs 48,650, a workforce of 46 with 38
  active, six named hubs, four booking numbers — ignoring the real result it
  had been handed. Those branches sat ABOVE the one reading res.stats, so
  the correct code was unreachable: asking about revenue could not return
  the real number because a literal answered first.

  Two were worse than wrong figures. The default branch returned a staffing
  table for ANY unmatched question. And the no-answer path built a
  sourceCalls entry claiming /admin/milers had been called, status
  "complete", "46 milers scanned" — forging the provenance trail that exists
  so an operator can check where a number came from. A fabricated figure is
  a bug; a fabricated citation defeats the mechanism for catching one.

  190 lines removed. Every branch now reads the result and returns null when
  there is nothing to draw. No-answer says so; errors report as errors.

  Found while verifying: 'Inactive'.includes('active') is true, so every hub
  counted as active — carried from the original, whose own sample data
  tripped it (six hubs, one Inactive, shown as 6/6). Now an explicit
  vocabulary match, with unknown treated as down: a hub wrongly shown
  offline gets investigated, one wrongly shown online hides an outage.

Home launcher tiles named pages that do not exist
  Every tile now names its destination. Task Board -> Tripsheets,
  Staff -> Milers, Availability -> Milers Summary (it pointed at the same
  page as the tile beside it), Compliance -> Exceptions,
  Invoices -> Bookings, Payroll -> Profitability,
  AI Reports -> Orders Summary. Group headings: WORKFORCE SUITE -> FLEET,
  FINANCE & CRM -> CLIENTS & REVENUE, AI TOOLS -> REPORTS & AI. "Invoices",
  "Payroll" and "CRM" named systems Doormile does not run.

  Four hardcoded badges removed (3, 38, 7, "New"). None was computed. A red
  badge means "this many things need you", and one that never changes
  teaches operators to ignore the real ones.

Navbar MileTruth control misaligned, hover dead
  One cause: a 36px image (h-9 w-9 max-w-none) inside a 32px button. It
  stood proud of the bell and avatar AND covered its own button, leaving
  hover:bg-surface-sunken nowhere to render. Now 20px.

Assistant dock 30% -> 20%, and responsive
  clamp(320px, 20vw, 460px) rather than max(): the cap is what makes a large
  monitor work, since 20vw is 768px at 4K. Verified across seven screen
  classes — 384px/20% at 1920, capped at 460px beyond 2300px, full-width
  overlay at or below 900px. At 1024px the 320px floor wins (31%), because
  20vw would be 205px and too narrow for the composer.

Suggestion chips took a third of the panel
  .dai-suggestions was flex-direction:column, overriding the component's own
  wrap="wrap", so four chips became four full rows. Row + wrap, trimmed
  padding, ellipsis on the text span where text-overflow can act. Measured
  at the 320px floor: 4 rows/177px -> 2 rows/84px, nothing clipped.

Pricing and Customers were unreachable on mobile
  Moving them off the nav bar into the account dropdown removed them from
  the phone entirely — the mobile sheet builds from NAV plus NAV_GROUPS and
  they were in neither. Both stayed routed, so only a typed URL reached
  them. Now one SETTINGS_NAV array that the dropdown and the sheet share.

calculateDrivingDistance was called and never imported
  CreateOrder.jsx:371 — a ReferenceError on every customer-pickup order with
  a pinned collection address, thrown synchronously inside a useEffect so
  the .catch() on that chain could never see it. Neither the build nor the
  lint config catches an unbound identifier in a .jsx file: eslint.config.js
  spreads pluginJs.configs.recommended and then declares its own rules
  object, which replaces the spread rules wholesale, so no-undef has never
  run. A repo-wide sweep with it enabled found this was the only instance.
  Pre-existing; found while auditing the coordinate changes.

Dead code and stale docs
  ALL_DESTINATIONS (declared, never read; its comment claimed it was what
  the mobile sheet renders). --dai-panel-width (declared twice, read
  nowhere) and the max-width:1279px block that only set it. AdminLayout's
  header comment said "three grouped menus (Fleet Ops, Reports, Settings)"
  when there are two, and Settings is a section in the account menu — that
  difference in routing is what caused the mobile gap above.

VERIFIED

878 tests across 26 suites, build clean, no new lint problems. The tab
strip, dock width, chip wrapping and navbar sizing were measured in a real
browser against the shipped stylesheet. deriveVisualData is module-private,
so it was extracted and driven through 16 logic checks.

NOT VERIFIED

/doormile/home has never been rendered in a browser, and the responsive
pass covers the assistant panel only — no page has been viewed at any
breakpoint. Both need a signed-in session. DataTable carries its own
overflow-x-auto and only two fixed widths above 390px exist in src/pages,
but that is grep, not eyes.

STILL OPEN

customerAppBookings.js lost its customerstatus/customerstage grouping in
49ee0c5 and has not been restored, so the Bookings tabs still read only the
operational status. The Status column (Bookings.jsx:98, :415) was never
stage-aware.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
dharaneesh-r
2026-09-18 19:21:21 +05:30
parent 05f08efc64
commit 1671a5f4b6
35 changed files with 2941 additions and 475 deletions
Download Patch File Download Diff File Expand all files Collapse all files

265
src/components/assistant/DoormileAI.css
View File

@@ -24,22 +24,41 @@
globalPolish.css, and an unprefixed name there is decided by bundle order.
--------------------------------------------------------------------------- */
:root {
/* 30vw, NOT 30%.
/* 20vw, NOT 20%.
The two consumers resolve a percentage against different boxes: the panel
is position:fixed, so `width: 30%` is 30% of the VIEWPORT, while
`padding-right: 30%` on the content container is 30% of ITS containing
block — which is narrower by the side nav. At 1440px that is 432px of
panel against 410px of reserved strip, and the page slides 22px underneath
the panel. A viewport unit resolves the same for both.
is position:fixed, so `width: 20%` is 20% of the VIEWPORT, while
`padding-right: 20%` on the content container is 20% of ITS containing
block — which is narrower by the side nav. The page would slide underneath
the panel by the difference. A viewport unit resolves the same for both.
max() rather than a separate min-width for the same reason: a min-width
that only the panel knows about would reintroduce the mismatch on narrow
screens. */
screens.
The floor matters more at 20vw than it did at 30vw: 20vw is 256px on a
1280px laptop, which is too narrow for the composer and a message thread.
320px is the floor, so below 1600px the panel stops shrinking and holds —
and the page keeps the rest. On a 1920px monitor 20vw is 384px.
Narrowed from 30vw on request. It is the reason the Deliveries tab strip
started overflowing, so the extra 10vw goes back to the page. */
/* Default = the NORMAL step. AIPanel overwrites this property on the
document element when the operator toggles the width, so the panel and
the page's reserved strip always read the same value. */
--dai-dock-width: max(300px, 25vw);
/* clamp, not max: the cap is what makes this work on a large monitor.
With `max(320px, 20vw)` the panel just kept growing — 20vw is 512px at
2560px and 768px at 4K, which is a chat column wider than most documents,
while the board beside it gets squeezed for no benefit. A conversation
does not read better past ~460px.
So three regimes, one expression:
< 1600px floor at 320px (20vw would be 256px on a 1280 laptop —
too narrow for the composer and the thread)
1600-2300 20vw (scales with the screen, as asked)
> 2300px cap at 460px (the page keeps everything above this) */
--dai-dock-width: clamp(320px, 20vw, 460px);
--dai-duration: 240ms;
--dai-ease: cubic-bezier(0.16, 1, 0.3, 1);
}
@@ -73,7 +92,10 @@
--dai-shadow: 0 8px 30px rgba(15, 23, 42, 0.1);
--dai-live: #10b981;
--dai-panel-width: 428px;
/* --dai-panel-width was declared here and at the 1279px breakpoint, and read
nowhere: the panel and the page's reserved strip both size from
--dai-dock-width. Removed so nobody tunes it expecting the panel to
change. */
--dai-inset: 12px;
--dai-duration: 240ms;
--dai-ease: cubic-bezier(0.16, 1, 0.3, 1);
@@ -119,22 +141,22 @@
seam has depth without the panel detaching. */
.dai-panel {
position: fixed;
/* Set from JS by AIPanel — Astryx does not publish a header-height token,
despite --appshell-header-height looking like one. */
top: var(--dai-dock-top, 57px);
right: 0;
bottom: 0;
/* Inset card geometry matching the reference design:
Floating cleanly off the top nav, bottom edge, and right edge with rounded corners. */
top: calc(var(--dai-dock-top, 57px) + 14px);
right: 16px;
bottom: 14px;
z-index: 1200;
width: var(--dai-dock-width);
width: calc(var(--dai-dock-width) - 24px);
display: flex;
flex-direction: column;
min-height: 0;
overflow: hidden;
background: var(--dai-surface);
border-left: 1px solid var(--dai-border);
border-radius: 0;
box-shadow: -6px 0 20px rgba(15, 23, 42, 0.05);
transform: translateX(100%);
background: #ffffff;
border: 1px solid #e2e8f0;
border-radius: 20px;
box-shadow: 0 4px 24px -2px rgba(15, 23, 42, 0.08), 0 1px 3px rgba(15, 23, 42, 0.04);
transform: translateX(calc(100% + 32px));
visibility: hidden;
transition:
transform var(--dai-duration) var(--dai-ease),
@@ -157,11 +179,15 @@
The transition sits on the container unconditionally so the page slides back
when the panel closes too — a rule that only exists while `.dai-docked` is
applied cannot animate its own removal. */
.dai-page,
.astryx-layout-content {
transition: padding-right var(--dai-duration) var(--dai-ease);
}
body.dai-docked .dai-page,
body.dai-docked .astryx-layout-content {
padding-right: var(--dai-dock-width);
/* Reserves the dock width plus a generous 20px gutter so the page content
(tables, cards) never collides with the sidebar and stays distinct. */
padding-right: calc(var(--dai-dock-width) + 16px);
}
/* ---- Mobile: there is no 30% worth having -------------------------------
@@ -171,10 +197,14 @@ body.dai-docked .astryx-layout-content {
@media (max-width: 900px) {
.dai-panel {
top: 0;
right: 0;
bottom: 0;
width: 100%;
z-index: 1301;
border-left: none;
border: none;
border-radius: 0;
box-shadow: var(--dai-shadow);
transform: translateX(100%);
}
.dai-scrim {
display: block;
@@ -182,6 +212,7 @@ body.dai-docked .astryx-layout-content {
.dai-scrim[data-open='true'] {
opacity: 1;
}
body.dai-docked .dai-page,
body.dai-docked .astryx-layout-content {
padding-right: 0;
}
@@ -194,20 +225,22 @@ body.dai-docked .astryx-layout-content {
-------------------------------------------------------------------------- */
.dai-root .dai-header {
flex: 0 0 auto;
padding: 14px 12px 12px 14px;
border-bottom: 1px solid var(--dai-border);
padding: 14px 16px;
border-bottom: 1px solid #f1f5f9;
background: #ffffff;
}
.dai-root .dai-title {
font-size: 15px;
font-weight: 650;
font-size: 16px;
font-weight: 700;
line-height: 1.2;
letter-spacing: -0.01em;
color: var(--dai-text);
color: #0f172a;
}
.dai-root .dai-subtitle {
font-size: 12px;
line-height: 1.3;
color: var(--dai-text-muted);
color: #64748b;
font-weight: 500;
}
/* The AI mark. A soft gradient orb — not a robot face. */
.dai-root .dai-spark {
@@ -215,8 +248,9 @@ body.dai-docked .astryx-layout-content {
align-items: center;
justify-content: center;
flex: 0 0 auto;
border-radius: 999px;
background: var(--dai-surface);
border-radius: 10px;
background: #fff1f2;
border: 1px solid #ffe4e6;
overflow: hidden;
}
/* The mark's own canvas is only 66.8% content — a third of every edge is
@@ -277,15 +311,7 @@ body.dai-docked .astryx-layout-content {
}
/* Page-context strip — "Orders · Today · All locations" */
.dai-root .dai-context {
flex: 0 0 auto;
padding: 7px 14px;
font-size: 11.5px;
color: var(--dai-text-muted);
background: var(--dai-surface-alt);
border-bottom: 1px solid var(--dai-border);
white-space: nowrap;
overflow: hidden;
text-overflow: ellipsis;
display: none;
}
/* --------------------------------------------------------------------------
Welcome state
@@ -360,61 +386,87 @@ body.dai-docked .astryx-layout-content {
They wrap, they never scroll. A horizontal scroller can always leave a chip
half-visible at the edge, and a half-visible button is a bug no amount of
fade masking fixes. */
.dai-root .dai-suggestions-bar .dai-section-label {
display: none;
}
.dai-root .dai-suggestions {
/* Row + wrap, which is what the comment above always claimed and what the
component asks for — SuggestionChips renders an HStack with wrap="wrap".
This rule said `column`, overriding it, so four chips became four full
rows and the strip ate a third of the panel before a single question had
been asked. Two short chips now share a row and only long ones take one to
themselves. */
width: 100%;
display: flex;
flex-direction: row;
flex-wrap: wrap;
gap: 8px;
align-items: flex-start;
align-content: flex-start;
}
.dai-suggestion {
display: inline-flex;
align-items: center;
gap: 6px;
gap: 8px;
max-width: 100%;
padding: 5px 10px;
/* Trimmed from 8px 18px. At the 320px floor the old horizontal padding put
36px of empty pill around every label, which is what stopped two chips
ever fitting side by side. */
padding: 7px 13px;
text-align: left;
/* A chip is one line. Without this the flex row can hand a chip a width
narrower than its label and the text wraps inside the pill, which is what
made the strip look ragged. The ellipsis itself is on
.dai-suggestion-text — see there. */
white-space: nowrap;
overflow: hidden;
font: inherit;
font-size: 12px;
line-height: 1.35;
font-size: 13px;
line-height: 1.4;
font-weight: 500;
color: var(--dai-text);
background: var(--dai-surface);
border: 1px solid var(--dai-border);
/* 14px, pinned — NOT 999px.
On a one-line chip a fully round radius already resolves to about 14px, so
these look identical. The difference shows on a chip whose question wraps
to two lines: 999px would resolve to half of ~46px and the chip stops
reading as a chip and starts reading as a card, so one long suggestion
would look like a different component from the nineteen beside it. */
border-radius: 14px;
color: #334155;
background: #ffffff;
border: 1px solid #e2e8f0;
border-radius: 9999px;
box-shadow: 0 1px 2px rgba(15, 23, 42, 0.03);
cursor: pointer;
transition:
background-color 140ms ease,
border-color 140ms ease,
color 140ms ease,
transform 140ms ease;
transition: all 140ms ease;
}
.dai-suggestion:hover {
background: var(--dai-surface-alt);
border-color: var(--dai-border-strong);
background: #f8fafc;
border-color: #cbd5e1;
color: #0f172a;
transform: translateY(-1px);
box-shadow: 0 2px 5px rgba(15, 23, 42, 0.06);
}
.dai-suggestion:active {
transform: translateY(0);
}
.dai-suggestion:focus-visible {
outline: 2px solid var(--dai-accent);
outline: 2px solid #0f172a;
outline-offset: 2px;
}
.dai-root .dai-suggestion-icon {
flex: 0 0 auto;
color: var(--dai-text-muted);
color: #64748b;
transition: color 140ms ease;
}
.dai-suggestion:hover .dai-suggestion-icon {
color: var(--dai-text-secondary);
color: #0f172a;
}
.dai-root .dai-suggestion-text {
/* The ellipsis lives here, not on the button: text-overflow needs the
element that actually holds the text, and the button is a flex container
whose children are the icon and this span. min-width:0 is what lets the
span shrink below its content width so the ellipsis can engage at all —
a flex item defaults to min-width:auto and would push the pill wider
instead. The button already carries title={item.text}, so the full
question is still available when a label is cut. */
min-width: 0;
overflow: hidden;
text-overflow: ellipsis;
white-space: nowrap;
}
/* Plain text link-button ("View more", "Sources") */
.dai-link {
@@ -695,26 +747,29 @@ body.dai-docked .astryx-layout-content {
-------------------------------------------------------------------------- */
.dai-root .dai-composer-wrap {
flex: 0 0 auto;
padding: 10px 12px calc(10px + env(safe-area-inset-bottom, 0px));
border-top: 1px solid var(--dai-border);
background: var(--dai-surface);
padding: 12px 16px calc(12px + env(safe-area-inset-bottom, 0px));
border-top: 1px solid #f1f5f9;
background: #ffffff;
}
.dai-root .dai-composer {
border: 1px solid var(--dai-border-strong);
/* 14px, the same corner the suggestion chips use. At 5px the input was the
one sharp-cornered thing in a panel of rounded surfaces, and it sat
directly beneath the chips where the mismatch was most visible. */
border-radius: 14px;
background: var(--dai-surface);
box-shadow: 0 1px 2px rgba(15, 23, 42, 0.04);
padding: 10px 10px 8px 14px;
border: 1px solid #e2e8f0;
border-radius: 9999px;
background: #f8fafc;
box-shadow: 0 1px 2px rgba(15, 23, 42, 0.03);
padding: 6px 6px 6px 16px;
display: flex;
align-items: center;
gap: 8px;
width: 100%;
transition:
border-color 140ms ease,
box-shadow 140ms ease;
box-shadow 140ms ease,
background-color 140ms ease;
}
.dai-root .dai-composer[data-focused='true'] {
border-color: var(--dai-accent);
box-shadow: 0 0 0 3px var(--dai-accent-ring);
background: #ffffff;
border-color: #cbd5e1;
box-shadow: 0 0 0 3px rgba(15, 23, 42, 0.05);
}
/* --------------------------------------------------------------------------
@@ -811,13 +866,13 @@ body.dai-docked .astryx-layout-content {
align-items: center;
justify-content: center;
flex: 0 0 auto;
width: 30px;
height: 30px;
width: 32px;
height: 32px;
padding: 0;
border: none;
border-radius: 50%;
background: var(--dai-accent);
color: var(--dai-accent-contrast);
background: #2563eb;
color: #ffffff;
cursor: pointer;
transition:
background-color 140ms ease,
@@ -825,29 +880,32 @@ body.dai-docked .astryx-layout-content {
transform 140ms ease;
}
.dai-root .dai-send:hover:not(:disabled) {
opacity: 0.86;
background: #1d4ed8;
transform: scale(1.05);
}
.dai-root .dai-send:active:not(:disabled) {
transform: scale(0.94);
transform: scale(0.96);
}
.dai-root .dai-send:focus-visible {
outline: 2px solid var(--dai-accent);
outline: 2px solid #2563eb;
outline-offset: 2px;
}
/* Disabled is the resting state until something is typed, so it has to read as
"not yet", not as "broken" — a filled grey circle, same shape and weight. */
.dai-root .dai-send:disabled {
background: var(--dai-surface-hover);
color: var(--dai-text-muted);
background: #f1f5f9;
color: #94a3b8;
cursor: default;
}
.dai-root .dai-composer textarea {
display: block;
flex: 1 1 auto;
width: 100%;
min-width: 0;
border: none;
outline: none;
resize: none;
padding: 0;
padding: 4px 0;
margin: 0;
font: inherit;
font-size: 13.5px;
@@ -914,15 +972,36 @@ body.dai-docked .astryx-layout-content {
/* --------------------------------------------------------------------------
Responsive
-------------------------------------------------------------------------- */
@media (max-width: 1279px) {
.dai-root {
--dai-panel-width: 396px;
/* Tablet and small laptop, 768-900px: the panel is a full-width overlay with a
scrim (see the max-width:900px block above), so the only thing left to do is
stop the suggestion strip from taking a third of a short screen — there is
much less height to spend here than on a desktop. */
@media (max-width: 900px) {
.dai-root .dai-suggestions-bar {
max-height: 26vh;
}
}
/* The block that used to sit here set `--dai-panel-width: 396px` at 1279px.
That variable is declared and never read — the panel sizes from
--dai-dock-width — so the rule had no effect on anything. Removed rather
than left looking load-bearing. */
@media (max-width: 767px) {
.dai-root {
--dai-inset: 0px;
}
/* Phone: chips get a touch target and room to breathe, and the strip is
capped harder still because the on-screen keyboard takes the bottom half
of the viewport the moment the composer is focused. */
.dai-root .dai-suggestions-bar {
max-height: 22vh;
padding: 8px 12px 6px;
}
.dai-suggestion {
padding: 9px 14px;
font-size: 13px;
}
.dai-panel {
width: 100vw;
max-width: 100vw;