The Work Order Breakdown object from the backend serializes its keys
without JsonPropertyName, so they arrive lowercase (pm/emergency/reactive/
overdue/other). The mapper copied them straight into `status`, which the
card uses as both label and the `types` drill-down id, and
`workOrderTypeDrilldownSearch` only accepts canonical WOType values — so
every breakdown row rendered lowercase and was inert (SH-354). Route both
mapping branches through a normalizer that maps type keys back to their
canonical labels case-insensitively; `other` is not a WOType, so it stays a
labelled, non-drillable "Other" row, and unknown values (legacy array-shape
lifecycle labels) pass through unchanged.
Dispatcher Performance gated its drill-down on `completionRate > 0`, so a
dispatcher with assigned work but no completions yet was inert here while
drillable from Workload. The drill-down filters by dispatcher + range and
never uses the rate, so gate on identity instead.
Also mock useDashboardTrend in the dashboard page test so it no longer
issues a real request that failed quietly in jsdom.
The inline technician rows on the wizard's Vendor & time step had no
client-side phone check, so a number that does not normalize to ten digits
failed the roster PATCH and blocked the whole Create with the raw backend
message in a toast. Validate each staged phone with the same
isValidNorthAmericanPhone predicate the vendor roster schema uses, so the
inline path matches the modal path. A blank phone stays valid.
Selecting a work-order type on wizard step 1 only patched type and
severity, leaving pm, serviceId, extraServices, and the vendor filtered
by that service in the draft. Switching type (e.g. PM -> Reactive) then
submitted a serviceId that is not in the new type's registry list, which
backend ResolveServiceAsync (SH-187/#131) rejects as ServiceInvalid and
the create toast renders as the generic "Unable to create the work
order". Clear the service and its vendor whenever the type actually
changes; re-selecting the same type leaves the selection untouched.
The create mutation's onSuccess awaited saveCompanyNotes before calling
onOpenChange(false). Because isCreating is createMutation.isPending ||
isCheckingDuplicate, and isPending drops to false the moment the work-order
create resolves, the dialog stayed open with Create re-enabled and pointer
events unlocked for the length of the roster GET plus notes PATCH. A second
Create click ran handleCreate again; with a blank provisional WO number the
duplicate lookup short-circuits without an API call, so createMutation.mutate
fired a second time and created a duplicate work order.
Close the dialog first, then fire saveCompanyNotes unawaited. The save does
not need the dialog open: fetchCurrentBaseline reads the roster when the
baseline is missing, and the failure toast is raised from the mutation's
option-level onError, so it still surfaces after the dialog unmounts.
Swap the inline fontSize/color on the week-scope status label for the
text-(length:--text-xs) and text-muted-foreground classes already used
across the header, so it tracks future token changes. --text-xs is 11px
and text-muted-foreground resolves to --muted-foreground, so rendering is
unchanged.
