Generated docker-compose .env not forwarded to engine; ${RABBITMQ_USER} unset at runtime

[rohitg00]

Summary

The generated docker-compose.yml does not forward the generated .env into the engine container, so ${VAR} placeholders in config.yaml (for example the RabbitMQ credentials) are unset at runtime and the engine fails to boot once a user switches a worker to a remote adapter.

Tested on Linux with engine 0.19.4.

Reproduction

1. iii project init --docker (generates .env with RABBITMQ_USER=iii / RABBITMQ_PASS=...).
2. Uncomment the rabbitmq service in docker-compose.yml and switch iii-queue to the rabbitmq adapter with amqp://${RABBITMQ_USER}:${RABBITMQ_PASS}@rabbitmq:5672 in config.yaml.
3. docker compose up.

Actual

Environment variable 'RABBITMQ_USER' not set

Expected

The credentials the generator wrote to .env should be available to the engine's ${VAR} expansion.

Root cause

• The generator writes .env with the RabbitMQ creds: engine/src/cli/project/mod.rs:390-402.
• ${VAR} in config.yaml is expanded by the engine process, so the variable must be in the container's environment.
• Docker Compose only uses .env to substitute the compose file itself; it does not inject those variables into the container unless the service declares env_file: (or an explicit environment: list). The generated iii service declares neither (templates in iii-hq/templates; mirrored at engine/tests/fixtures/templates/docker/docker-compose.yml).

Proposed fix

Add env_file: .env to the generated iii service in iii-hq/templates docker/docker-compose.yml (and the mirrored fixture). The generator always writes .env, so it is safe to reference.

Workaround (for users today)

Add to the iii service:

services:
  iii:
    env_file: .env