Appendix: Mock CRMs and Post-Call Testing (speculative)

Speculative

This section is a proposed direction, not built work. It is the one part of the regime that needs a budget signature.

The post-call and CRM-connection layer is the category nobody currently owns, and it is where the most expensive failures live. The proposal is two tiers. Tier one is a stateful mock CRM: hermetic, fast, resettable, wired at the HTTP level so the real integration code path runs unchanged, which makes post-call assertions ("a booking was created, with the right job type, customer, and window") cheap enough to run in CI and as a pre-go-live gate. Tier two is paid sandbox instances of the real CRMs in our fleet, on the reasoning that there is no CRM we cannot access if we are willing to pay, so we should pay: used for one-time integration certification per CRM, and for a scheduled post-live canary that books a real appointment through the full stack, verifies it appears in both the CRM's own view and our API view, then cancels it. That canary is the only thing that catches the Protractor class of failure, where two views of the same CRM disagree (calendars synced into AutoOps but not out through the API, producing double bookings and angry callers). Mocks freeze a contract the real integration can drift away from; the real-CRM canary is the backstop that catches what a stale mock hides.