Write an integration test plan for a multi-service flow, not just another mocked unit test

You are designing an integration test for a flow that spans more than one component in this system, where the point of the test is to catch failures that only show up when the real pieces talk to each other — not a unit test with every dependency mocked, which would miss exactly the class of bug this test needs to catch.

FLOW TO TEST
A user submits an order, which writes to the orders table, publishes an OrderCreated event to the queue, and the inventory service consumes that event to decrement stock.

DEPENDENCIES THAT MUST BE REAL, NOT MOCKED
Postgres (via a test database), the real RabbitMQ instance running in the test environment, and the actual inventory service — not a stub of it.

SPECIFIC FAILURE POINTS THIS SHOULD CATCH
The queue event was published before the database transaction committed, so the inventory service sometimes processed an order that didn't fully exist yet.

TEST ENVIRONMENT AVAILABLE
Testcontainers spins up Postgres and RabbitMQ per test run; the inventory service runs locally via docker-compose.test.yml.

PHASE 1 — CONFIRM WHAT 'INTEGRATION' MEANS FOR THIS FLOW
Before writing any test code, state back which components will be exercised for real versus which (if any) still need to be mocked because they're genuinely external to this system (a third-party payment processor sandbox, for example, might reasonably still be a mock or a recorded fixture) — and justify each mock against the failure points listed, so a mock is never added just because it's more convenient to write around.

PHASE 2 — SETUP AND TEARDOWN
Describe how the test environment gets into a known state before the test runs and back to clean afterward — using the test environment described above — since an integration test that leaves state behind will produce flaky, order-dependent failures in every test that runs after it, which is a worse outcome than not having the test at all.

PHASE 3 — THE TEST ITSELF
Write the test so it exercises the flow end to end through the real dependencies, asserting on outcomes that could only be wrong if the real integration between components broke — not on internal implementation details that a unit test would already cover. For each of the specific failure points listed, make sure there's an assertion that would actually fail if that specific failure happened; a passing integration test that wouldn't have caught the incident it was written in response to isn't accomplishing anything.

PHASE 4 — WHAT THIS TEST DELIBERATELY DOES NOT COVER
State explicitly what's still out of scope for this test (edge cases already handled by unit tests, load/concurrency behavior, etc.) so nobody mistakes this one test for full coverage of the flow.

OUTPUT FORMAT
1. Mock justification (Phase 1).
2. Setup/teardown code.
3. The integration test itself.
4. Explicit out-of-scope note (Phase 4).