What problem does it solve? Writing integration tests for CoreEx-based APIs requires coordinating database migration and seeding, cache clearing, outbox event expectations, ETag/concurrency semantics, and inter-domain HTTP mocks — a setup that is easy to get wrong and produces flaky or misleading tests when done ad hoc. ## Core Features & Use Cases - Structured test authoring: Guides creation of XxxReadTests/XxxMutateTests partial classes with one operation per file (Get/Query/Create/Update/Patch/Delete) over WithApiTester<{Solution}.Api.Program>. - Deterministic seeding and setup: Covers read-data.seed.yaml/mutate-data.seed.yaml conventions, ^N deterministic GUIDs, provider-specific casing (PostgreSQL snake_case vs SQL Server PascalCase), and one seed row per destructive test. - Correct assertion semantics: Encodes rules for 412 vs 409 vs 428 status codes, idempotent delete flows, provider-specific outbox event assertions (ExpectPostgresOutboxEvents/ExpectSqlServerOutboxEvents), and MockHttpClientFactory usage. - Use Case: After implementing a new Product endpoint, ask for its integration tests and receive a complete read/mutate test class pair with seed data, ETag concurrency tests, outbox event assertions, and .res.json resources. ## Quick Start Write the CoreEx API integration tests for the Product entity covering Get, Query, Create, Update, and Delete against a PostgreSQL database.