Fix CSR scheduling form losing in-progress quote on tab return

Objective

• CSR schedulers building a quote on /schedule must not lose in-progress work (services, property, contacts, required info, dispatch slot) when multitasking across Attik tabs or when the page remounts.
• Eliminate the failure where the scheduling form goes blank and the user must rebuild the quote from scratch because nothing was saved.

Background

• Courtney reported that during a quote, switching to another Attik tab to confirm drive times with calendar availability and returning to the original tab can crash or blank the order form. The draft is not saved and the quote must be started over. This has happened twice.
• Screen recording review (Jun 2026): The attached recording shows a fully populated quote (property, contacts, Essential Package bundle, dispatch slot, ~$1,138) followed by a full form reset — all sections return to empty defaults ($0.00 / 0 hrs) coinciding with "Loading drafts…" on remount. The same end state as tab-switch data loss; removing a bundle alone does not clear property/contacts in code, but presents the same user-visible wipe when the page remounts.
• Manual Save Draft exists but requires at least one contact and explicit user action; there is no auto-save or session persistence for in-progress form state today.
• BuildVersionGuard reloads the page on tab visibility when a newer frontend build is detected or on chunk-load errors, which destroys unsaved React state. In-app navigation within the same tab does not trigger this reload; browser tab switching can.
• Book in Attik (POST inspection/book-job) persists the job to the server and does not trigger a version-guard reload. This issue targets in-progress quotes before book or manual Save Draft.

Video showing content removed from scheduling form when bundle was removed.

Screen Recording 2026-06-16 at 12.08.32 PM.mov

Product Decisions

Locked

1. Problem type — Bug. Losing an in-progress CSR quote and having to re-enter all sections is not acceptable expected behavior.
2. Surface — Internal CSR scheduling form at /schedule (NewSchedulingForm), not the client-facing online scheduler.
3. Failure mode — Full form wipe (services, contacts, property, required info, dispatch) — not merely removing bundle line items while other sections remain.
4. Tab switch and form wipe — Switching Attik browser tabs during a live quote and the blank-form outcome shown in the recording are the same class of problem (unsaved state lost on remount/reload).
5. Persistence approach — Use browser session/local recovery for in-progress form state plus a reload warning when unsaved scheduling work exists. Do not implement auto-save server drafts as part of this fix.
6. Scope vs ATT-1333 — Fix data loss minimally here with session/local recovery. Auto-save server drafts (ATT-1333) is out of scope; ATT-1333 may be marked duplicate of this issue since the chosen approach does not use server auto-save.
7. BuildVersionGuard behavior — When unsaved scheduling form state exists, block stale-build and chunk-error reloads (do not silently refresh and wipe the form).
8. Reload-warning UX — When a blocked reload is attempted, show a warning with an option to Save Draft (existing manual save flow) so the user can persist work before refreshing. Also allow continuing without refresh or discarding and refreshing, as appropriate for the blocked-reload scenario.
9. Manual draft today — Existing manual Save Draft and resume-via-draft-banner behavior stays as-is. Save Draft still requires at least one contact per current validation in handleSaveDraft.
10. Booked jobs — Out of scope. Once Book in Attik succeeds, the inspection is persisted server-side regardless of form UI state.

Scope

Frontend

• In-progress quote state lives entirely in client React state in attik-frontend/src/components/scheduling/NewSchedulingForm.tsx. Only handleStartOver() clears all sections together; bundle removal (onSelectBundle(null) in ServicesSection.tsx) does not clear property or contacts.
• Session/local recovery — Persist in-progress scheduling form state in browser storage and restore on remount of /schedule (same CSR session). Out of scope per product decision: server-side auto-save drafts and auto-persistence thresholds tied to ATT-1333.
• Reload warning / blocked refresh — Extend BuildVersionGuard.tsx (mounted from globalProvider.tsx) to detect unsaved scheduling form state and block window.location.reload() on stale-build or chunk-error paths. Surface a user-facing warning that includes Save Draft (wired to existing handleSaveDraft in NewSchedulingForm.tsx) when the form meets Save Draft requirements (at least one contact).
• Manual draft save: handleSaveDraft in NewSchedulingForm.tsx. Draft list/resume: CSRDraftExpandableSection.tsx. Page entry: attik-frontend/src/app/tools/schedule/page.tsx.
• Booking flow unchanged: CreatingSpectoraJob.tsx → POST inspection/book-job via callServerAction; success does not reload the page.

Backend

• No backend change expected for this fix. Existing quote routes remain for manual Save Draft only (including Save Draft invoked from the reload-warning flow).

References

• Dialpad call recording (~5:15) — original Courtney repro context
• Slack thread (Featurebase intake)
• ATT-1333 — Auto Save Drafts on Scheduling Form (out of scope; candidate duplicate)
• ATT-151 — Save Draft in Internal Scheduler (Done; manual save shipped)
• ATT-1871 — BuildVersionGuard stale-client pattern (canceled; related guard behavior)