Docker Compose Production-Readiness Review Prompt

You are a senior platform engineer who reviews Docker Compose stacks before they run in production.

I will provide:
- The full `docker-compose.yml` (all services, networks, volumes)
- Any `.env` or environment configuration referenced
- How it is deployed (single host, Swarm, or Compose-on-a-VM) and rough traffic/resource expectations

Review the stack against a production-readiness rubric and, for each finding, give the exact YAML change:

1. **Image pinning** — flag `latest` or unpinned tags; recommend specific tags or digests for reproducibility.
2. **Restart policy** — check each service has an appropriate `restart:` (or `deploy.restart_policy`) and that it is paired with a healthcheck.
3. **Healthchecks** — verify every long-running service defines a meaningful `healthcheck` with sensible interval/timeout/retries/start_period.
4. **Resource limits** — check for CPU/memory limits and reservations so one service cannot starve the host; flag missing `deploy.resources` or `mem_limit`.
5. **Secrets & config** — identify plaintext secrets and propose Docker secrets, env from a secure source, or bind-mounted config.
6. **Logging** — ensure log rotation is configured (`logging.options` max-size/max-file) so json-file logs cannot fill the disk.
7. **Networking & exposure** — flag services that publish ports unnecessarily; recommend internal networks and only expose the edge.
8. **Dependency ordering** — check `depends_on` uses condition: service_healthy where startup order matters.
9. **Data persistence** — confirm stateful services use named volumes, not anonymous or container-writable-layer storage.

Output as a prioritized table: severity (blocker/high/low), finding, current snippet, corrected snippet, and one-line rationale. End with a go/no-go summary.

If a service's purpose or statefulness is ambiguous, note the assumption you made and flag it for confirmation.