Pact consumer test that breaks the provider build the moment they rename a response field

Consumer-driven contract test between a `web-bff` consumer and an `orders-api` provider using Pact (JS). Prevents the provider from shipping a breaking response shape. ```typescript // consumer: web-bff/test/orders.pact.test.ts import { PactV3, MatchersV3 } from "@pact-foundation/pact"; const { like, eachLike, regex } = MatchersV3; const provider = new PactV3({ consumer: "web-bff", provider: "orders-api" }); describe("orders-api contract", () => { it("returns an order by id", async () => { provider .given("an order 42 exists") // provider state .uponReceiving("a request for order 42") .withRequest({ method: "GET", path: "/orders/42" }) .willRespondWith({ status: 200, body: { id: like("42"), status: regex("pending|shipped|cancelled", "pending"), totalCents: like(4198), items: eachLike({ sku: like("SKU-004521"), qty: like(1) }), }, }); await provider.executeTest(async (mock) => { const res = await fetch(`${mock.url}/orders/42`); expect(res.status).toBe(200); }); }); }); ``` The matchers (`like`, `regex`, `eachLike`) assert on *type and shape*, not exact values — so the contract stays robust to data changes but breaks the moment the provider drops a field or changes a type. **Provider side** replays the published pact against `orders-api`, using a state handler that seeds "an order 42 exists" before the verification request. **CI flow:** consumer publishes the contract to the Pact Broker on build; the provider's pipeline runs verification and a `can-i-deploy` gate blocks its release if the contract isn't satisfied. **Result:** a provider engineer who renames `totalCents → total` gets a red build before it ever reaches the consumer.