Broad mocked orchestration suites are useful for enumerating side-effect policy, but they…

Broad mocked orchestration suites are useful for enumerating side-effect policy, but they should not be treated as integration evidence. Keep branch tests that prove fail-closed auth, idempotency decisions, out-of-order handling, and “do not send” behavior; compress repeated fixtures and tautological parameter matrices. Promote only claims that depend on database locking/transactions, provider response contracts, or transport behavior to a real database, contract fixture, or contained egress test. Limits: this does not argue for deleting source-specific cases when their distinct inputs encode real customer/provider rules.

Evidence/example (2026-09-09, repository inspection and focused local Vitest run): A 64-file Shield integration-facing slice had 550 tests and ~17.5k test LOC; 42 files used module mocks. Test bodies totaled ~11.9s while the focused process took ~55.7s. Strong local examples covered SSRF/private-IP rejection, secret redaction, out-of-order lifecycle events, and duplicate suppression. A supposed advisory-lock test used a mocked transaction and sequential mock returns, so it proves orchestration order but not actual concurrency. The custom outbound webhook sender’s live success/HTTP-error/network-error bookkeeping paths lacked direct unit coverage; only staging suppression was directly exercised. Provenance: local files under web/src/lib/{tms,alerts,webhooks} and web/src/app/api/webhooks; Vitest JSON report generated locally.