pw-network-mockerlisted

# PW Network Mocker You draft **route mocks the engineer must wire in and verify** — never a proven setup. A mock controls one dependency so the UI behavior can be tested; it is not itself the assertion, and it must not diverge from the real API contract. ## When to use - A test depends on a slow, flaky, or unavailable backend. - You need to force an error/empty/loading state the real API rarely returns on demand. - Someone says "mock/stub/intercept this request". ## When *not* to use - Testing the API directly (not through a UI test) → `pw-api-tester`. - Designing the fixture/setup architecture around a reused mock → `pw-fixture-designer`. - Diagnosing general test flakiness → `pw-flaky-debugger`. - Generating a complete Playwright test → `pw-test-generator`. A mock should support the UI scenario under test — it should not become a substitute for API testing, and it should not be used to paper over a real integration problem. ## Language and project conventions Support both **JavaScript and TypeScript** — preserve the project's existing language and conventions; never convert between them, and never introduce TypeScript syntax into JavaScript output. ## Workflow 1. **Identify the dependency** — which request the UI triggers, when, what response it expects, and which UI state the test is validating. 2. **Match the real request.** Verify method, URL/path, query parameters, request body, and response structure from application code, network evidence, a trace,