Fix misleading Preferred Inspectors behavior in online scheduler

Objective

• Stop the online scheduler from implying a client booked a specific inspector at a chosen time when they only filtered the calendar.
• Keep datetime, inspector assignment, confirmation UI, and the booking payload in sync so the inspector on the job matches what the client reasonably believed they selected.
• Reduce support friction and wrong-inspector assignments when agents use Preferred Inspectors after picking a time.

Background

• Product feedback and a demo recording show a confusing flow on the public scheduler Schedule step:

1. Client picks a time slot first.
2. Client then chooses an inspector in Preferred Inspectors.
3. The calendar updates to that inspector’s availability and the same time can remain highlighted.
4. The client believes they reserved that inspector at that time, but the booked job can assign someone else.

• Demo: this video
• Current behavior (confirmed in code):
• Preferred Inspectors (InspectorFilter) is a client-side calendar filter only. It narrows visible slots via selectedInspectorIdsForFilter in SlotsStep; it does not update the locked inspector after a time is already selected.
• Clicking a time sets selectedDateTime, selectedInspectorForSlot, and selectedSlotInspectorInfo in handleTimeSlotSelect. For multi-inspector slots with autoSelectTopInspector, the best-scoring inspector may be auto-assigned unless the per-slot Select Inspector picker is shown.
• Slot highlighting in CalendarView is datetime-only (isSelected = selectedDateTime === slot.datetime), so a filtered inspector’s slot at the same time can look selected even when assignment still points at another inspector.
• Booking sends inspectorAssignment: [selectedSlotInspectorInfo._id] from BookingJobLoader. When exactly one preferred inspector is filtered, requested is also sent — but that is a preference, not the assignment.
• Inspector-first flow works today: choosing Preferred Inspectors before clicking a time generally behaves as users expect.

Product Decisions

Locked

1. Problem type — This is a UX bug, not intended product behavior. Users should not be able to finish booking believing they selected inspector + time together when only the time (and a different assignment) was locked.
2. Primary surface — Online scheduler public Schedule step (/scheduler slots flow). Internal dispatch scheduling is out of scope unless the same components are shared and broken there too.
3. Repro order — The misleading case is time first, then Preferred Inspectors. Inspector-first selection is acceptable today and should remain supported.
4. Booking source of truth — selectedSlotInspectorInfo / selectedInspectorForSlot drive assignment today; any fix must keep confirmation UI, summary bar, quote/hold creation, and inspectorAssignment aligned.

Open

1. Fix approach — When Preferred Inspectors changes after a time is selected, should the product (a) re-bind assignment if the filtered inspector has a slot at that datetime, (b) clear the selected time and require re-pick, (c) block filter changes while a time is selected, or (d) require inspector-first ordering in the UI (copy + disabled states)? Options may be combined (e.g. re-bind when possible, clear when not).
2. Inspector unavailable at selected time — If the user filters to an inspector who does not have a slot at the already-selected datetime, should the time selection clear, show an inline error, or keep the time but show that the inspector is unavailable?
3. Per-slot inspector picker vs Preferred Inspectors — When Settings → Scheduling → Show inspector in online scheduler is on, multi-inspector slots already expose a Select Inspector list on slot click. How should that interact with Preferred Inspectors after a time is picked — one combined model or separate controls with clearer labels?
4. Multi-select preferred inspectors — The filter allows multiple inspectors. If two or more are selected after a time is chosen, what should assignment and confirmation show? (Today only a single filter triggers requested.)
5. Requested vs assigned — When a single preferred inspector is chosen, should the fix update assignment only, requested only, or both? Product should confirm whether online bookings should ever assign a non-filtered inspector when the user filtered to one person.
6. Quote / hold path — sendQuote.ts and SendQuoteLoader use the same slot/inspector state. Confirm whether quote sends and working holds must follow the same rules as live booking.
7. Coordination with ATT-1700 — Improve preferred inspector visibility in online scheduler targets discoverability/copy for the same control. Confirm whether ATT-1932 ships independently as a behavior fix or should be sequenced with ATT-1700.

Scope

Frontend (attik-frontend)

• Schedule step — src/app/scheduler/slots/SlotsStep.tsx owns selectedInspectorIdsForFilter, selectedInspectorForSlot, selectedSlotInspectorInfo, and handleTimeSlotSelect. Client-side slot filtering and the green Appointment Scheduled confirmation card (getSelectedInspector) live here.
• Preferred Inspectors control — src/app/scheduler/slots/InspectorFilter.tsx (label: Preferred Inspectors, multi-select).
• Calendar — src/app/scheduler/slots/CalendarView.tsx groups slots by datetime, highlights selection by datetime only, and optionally shows per-slot Select Inspector when scheduleSettings.showInspectorInOnlineScheduler is enabled.
• Shared scheduler state — src/app/scheduler/SchedulerContext.tsx persists filter and slot inspector state; step validation in src/app/scheduler/utils/useStepValidation.ts requires selectedInspectorForSlot[selectedDateTime] on the schedule and summary steps.
• Downstream surfaces — Inspector shown on SchedulerSummaryBar.tsx, summary/SummaryStep.tsx, summary/BookingJobLoader.tsx, and utils/sendQuote.ts / summary/SendQuoteLoader.tsx should stay consistent with whatever assignment model is chosen.
• Settings gate — showInspectorInOnlineScheduler in scheduling settings controls whether inspector names/avatars appear on slots and confirmation; behavior should be tested in both on and off states.

Backend (attik-backend)

• No backend change is required for the filter-vs-assignment mismatch itself; assignment is sent from the frontend via inspectorAssignment on inspection/book-job (and Spectora create-job for non-Attik booking). Revisit only if product decides requested semantics need server-side enforcement.

Out of scope

• Ranking algorithm changes, agent contact preference rules (ATT-1119), or ATT-1700 visibility/copy work unless explicitly pulled in.
• Internal office scheduler (DispatchSection, reschedule modals) unless the same bug reproduces there with shared components.

References

• Demo recording: https://youtu.be/2dCttC8Ho5w
• Related (discoverability, not this bug): ATT-1700 — Improve preferred inspector visibility in online scheduler
• Key entry points: attik-frontend/src/app/scheduler/slots/SlotsStep.tsx, attik-frontend/src/app/scheduler/slots/InspectorFilter.tsx, attik-frontend/src/app/scheduler/summary/BookingJobLoader.tsx