# RabbitMQ local integration evidence — 2026-09-18

> Historical record: this verifies the former tenant-queue `--consume --tenant-key` path, which F03 removed. It is not current runtime or protocol evidence; current local V3 evidence is [here](f03-local-task-runtime-v0.1.md). No external broker compatibility is implied.

## Scope

This is an isolated local Docker broker test only. It is not a SaaS broker,
production acceptance, or an authorization to connect to an external broker.
The container was removed by the test script on exit; credentials were
randomized and not recorded.

## Run

- command: `make mq-integration-local`
- image: `rabbitmq:4.1-management-alpine`
- local image ID: `sha256:fcc273cebb0880ec25845c9bfd97687122ac9cc391538f053cb5873f4181f35f`
- adapter: `OpenWithPrefetch(..., 1)`
- tests: `go test -tags=integration ./internal/mq ./internal/dispatcher`
- result: passed

The tests exercised a fresh tenant queue and its durable DLQ, publisher
confirm, routing-key preservation, manual ACK, permanent rejection/dead-letter
routing, and a second consumer after cancellation. The Dispatcher integration
case additionally delivered the contract fixture through the tenant queue,
persisted inbox/task/outbox state in SQLite, published the resulting event,
and verified `task_status=accepted` and `outbox_status=published`. Consumer
tags are unique and are explicitly cancelled so a stopped consumer cannot
retain later deliveries.
The broker readiness gate uses RabbitMQ's `check_running`; a ping alone is not
sufficient for application readiness.

## ECS candidate connection smoke

After the local test, the same pinned image digest
`sha256:fcc273cebb0880ec25845c9bfd97687122ac9cc391538f053cb5873f4181f35f`
was transferred to the owner-authorized Debian ECS because the host could not
pull Docker Hub directly. It was run as an isolated loopback-only disposable
broker with a randomized non-recorded credential and removed after the test.
The current candidate binary at
`/opt/sip-go-agent/sip-go-agent.269a0d2ad350544597a71d3b0869ceb57d57f86defb3fe560e64e75bc052edb6`
connected successfully:

- `dispatcher --mode mock --once` returned `0` and reported `published: 0`.
- `dispatcher --mode mock --consume --tenant-key deploy-smoke` connected and
  remained waiting for deliveries until the bounded 8-second smoke timeout
  (`124`); it emitted no connection or configuration error.
- A second bounded run published the approved contract fixture
  `examples/call.execute.json` through the broker management API. The broker
  returned `routed: true`; the deployed candidate consumed it with
  `tasks=1`, `inbox=1`, and `outbox=1`, then a separate deployed candidate
  `dispatcher --mode mock --once` returned `0` with `published: 1`.
- Final isolated SQLite state was `task_status=accepted` and
  `outbox_status=published` for one row. The disposable broker container and
  fixture were removed after the check; the randomized password was not
  recorded.

This proves candidate-to-broker TCP/AMQP authentication, tenant routing,
SQLite inbox/task/outbox handling, and candidate outbox publication on the ECS
against a disposable broker. It does not prove SaaS application receipt or an
approved production broker.

## Follow-up candidate: consume now flushes outbox

The first ECS receipt smoke exposed that the deployed `--consume` path only
accepted commands and required a separate `--once` process to flush outbox.
The command was corrected to run a bounded outbox flush loop while consuming,
with a regression test in `cmd/sip-go-agent/main_test.go`.

Candidate SHA-256:
`14d61e617df1c00a9a0ab372f8baf0b8a67e40cff75fcfb36fb1f9cfb27a0725`.
With only the candidate `dispatcher --consume` process running, the same
fixture was published to the isolated tenant queue. The broker returned
`routed: true`; within one second the candidate persisted `tasks=1`,
`inbox=1`, `outbox=1`, and `outbox_status=published`. No separate `--once`
flush process was run. A temporary SaaS-events queue bound to
`agent-call.events.v1` then received one `agent-call.command.result` message
(`payload_bytes=472`, `delivery_mode=2`, `content_type=application/json`). The
temporary broker, queue, and fixture were removed after the check.

## Remaining boundary

This proves only the local adapter/topology and an isolated ECS candidate
connection against a disposable RabbitMQ container. It does not prove the
approved broker version, production ACL/vhost, TLS, network policy, queue
limits, crash/commit recovery, multi-Dispatcher coordination, SaaS
application receipt, or P1 capacity/backpressure.