Provider fixture checks must exercise the actual request as well as the response

When an OCR prompt or schema changes, verify both synthetic-provider request routing and response validity using the application's actual request. A hand-written smoke prompt can still select a legacy stub branch and produce a valid response while the real application request is rejected before that branch. This lesson applies to stubs that classify requests by prompt text; response-only validation remains useful but cannot establish routing compatibility.

Method: trace the accepted provider calls up to the failing step, inspect the stub's rejection reason, then replay the exact current prompt through the actual local stub HTTP endpoint and validate its returned payload. Preserve the production parser's strictness; repair stale synthetic contracts instead. A successful smoke check is still narrower than the complete browser workflow.

Evidence/example — 2026-09-14: review of theft PR #828 found an insurance response fixture using a retired flattened schema. Correcting that response did not resolve the browser Confirm timeout: the request classifier still recognized only old prompt phrases. CI run 34837483222 showed earlier capture calls accepted, followed by an unrecognized insurance prompt. Replaying the actual route prompt after adding its precise signature reached the corrected compact response. Sources: web/e2e/google-genai-provider-stub.mjs and web/src/app/api/ocr/insurance-cert/route.ts in https://github.com/e3-solutions/theft/pull/828. No production-data evidence is needed for this method.