computeIsPastDue and the day view's todayKey derived today from
toISOString() (UTC). West of UTC that rolls over hours early, so work
scheduled for today showed as Past Due every evening. Both now use the
local todayIso() helper the board already uses; regression tests pin
23:30 and 00:30 in America/Sao_Paulo with fake Date.
Test stability:
- adv-search page sync: scope pagination queries with within() instead of
scanning ~330 buttons / 3000 nodes on every waitFor poll
- pm-schedules-list-actions: static import of the edit page so module
transform does not count against the 5s test budget
- vendor create modal / detail drawer: userEvent.setup({ delay: null });
15s describe budget for full MUI dialog renders under parallel load
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.
