docker-compose.yml

# =========================================================================
# Mantra Core Technologies
# Product: ALOVIDA Health Ecosystem
# Footprint: Infrastructure Configuration (desarrollo local)
# -------------------------------------------------------------------------
# Portabilidad (Mac / Windows / Linux):
#   - Todas las credenciales y puertos salen de .env (copiar de .env.example).
#     Postgres se siembra con las MISMAS variables que usa la app (DB_*), así
#     no hay dos juegos de credenciales que mantener sincronizados.
#   - La persistencia usa VOLÚMENES NOMBRADOS gestionados por Docker: funcionan
#     igual en cualquier SO y evitan los problemas de permisos/rutas de los
#     bind-mounts de base de datos en Windows/macOS. Los datos sobreviven a
#     `docker compose down` y a reinicios. Para borrarlos: `docker compose down -v`.
#     Para relocalizar a una carpeta del host, ver el bloque comentado al final.
#   - Los scripts de docker/db-init/*.sh DEBEN quedar con fin de línea LF; eso lo
#     garantiza .gitattributes (`*.sh text eol=lf`) para los que trabajan en Windows.
#   - Arranque recomendado: `yarn docker:up` (no `docker compose up -d` a
#     secas). Purga sola la caché de build vieja antes de levantar el stack
#     (`scripts/docker-prune.sh`, idempotente y sin costo si no hay nada que
#     purgar) — así ninguna máquina que corra el proyecto acumula los ~20 GB
#     de caché muerta que se juntaron acá. Reconstruir la imagen de la API
#     pasa por el mismo filtro con `yarn docker:api:refresh`.
# =========================================================================
name: ${COMPOSE_PROJECT_NAME:-mantra-redesa}

# Entorno compartido por la API y los 21 procesos worker (un dominio cada
# uno — ver `PLAN-CORRECCION-WORKERS-2026-07-28.md`). `x-app-env` es una
# extension field (Compose la ignora como servicio; solo sirve de ancla YAML)
# para no repetir 21 veces el mismo bloque. Los host/puerto son los nombres de
# servicio DENTRO de la red de compose (no los `*_PORT` expuestos al host, que
# son solo para conectarse desde fuera de Docker).
x-app-env: &app-env
  # Este compose es el de DESARROLLO LOCAL (ver la cabecera del archivo): monta
  # el emulador de proveedores, publica puertos en el host y siembra la base con
  # credenciales de ejemplo. Declararlo como `production` era una contradicción
  # con lo que el archivo realmente levanta, y además activa las restricciones
  # pensadas para un despliegue real —`JWT_SECRET` obligatorio, prohibición del
  # emulador de proveedores— que este entorno deliberadamente no satisface.
  # Producción usa manifiestos propios, no este archivo.
  NODE_ENV: ${NODE_ENV:-development}
  PORT: "3000"
  # Barrido de vencimientos de las admisiones de profesionales (worker-profiles).
  ADMISSIONS_EXPIRE_SWEEP_ENABLED: ${ADMISSIONS_EXPIRE_SWEEP_ENABLED:-true}
  ADMISSIONS_EXPIRE_SWEEP_CRON: "${ADMISSIONS_EXPIRE_SWEEP_CRON:-0 * * * *}"
  # Conexión a datos: se lee del `.env` del host, con los nombres de servicio
  # del compose como default. Así el mismo archivo sirve para las dos formas
  # de correr: contra Postgres/Mongo gestionados (Neon, Atlas — el `.env`
  # trae host, credenciales y `DB_SSL=true`; los contenedores locales de base
  # ni se levantan, ver el perfil `local-db`) o contra los contenedores del
  # propio compose (`.env` sin `DB_HOST`/`MONGODB_URI`, o con los nombres de
  # servicio). Ojo con el híbrido «API en contenedor + base local»: el `.env`
  # de `.env.example` dice `DB_HOST=localhost`, que dentro del contenedor no
  # existe; ahí hay que pasar `DB_HOST=postgres DB_PORT=5432` al `up`.
  DB_HOST: ${DB_HOST:-postgres}
  DB_PORT: ${DB_PORT:-5432}
  DB_USER: ${DB_USER:-${POSTGRES_USER}}
  DB_PASSWORD: ${DB_PASSWORD:-${POSTGRES_PASSWORD}}
  DB_NAME: ${DB_NAME:-${POSTGRES_DB}}
  # Obligatorio contra un Postgres gestionado: sin esto `orm.env.ts` cae a su
  # default `false`, y Neon corta el `startup` en claro. No estaba declarado
  # en este bloque, así que el `.env` no podía activarlo dentro del contenedor.
  DB_SSL: ${DB_SSL:-false}
  MONGODB_URI: ${MONGODB_URI:-mongodb://mongodb:27017/mantra_redesa_health_document_store}
  MONGO_DB: ${MONGO_DB:-mantra_redesa_health_document_store}
  REDIS_HOST: redis
  REDIS_PORT: "6379"
  OPENSEARCH_NODE: http://opensearch:9200
  MINIO_ENDPOINT: minio
  MINIO_PORT: "9000"
  MINIO_ACCESS_KEY: ${MINIO_ACCESS_KEY}
  MINIO_SECRET_KEY: ${MINIO_SECRET_KEY}
  MINIO_BUCKET: ${MINIO_BUCKET:-mantra-redesa-health-files}
  FILE_STORAGE_ADAPTER: ${FILE_STORAGE_ADAPTER:-local}
  FILE_STORAGE_LOCAL_DIR: ${FILE_STORAGE_LOCAL_DIR:-./storage/uploads}
  FILE_STORAGE_MAX_SIZE_BYTES: ${FILE_STORAGE_MAX_SIZE_BYTES:-10485760}
  FILE_STORAGE_S3_BUCKET: ${FILE_STORAGE_S3_BUCKET:-mantra-redesa-health-files}
  FILE_STORAGE_S3_REGION: ${FILE_STORAGE_S3_REGION:-us-east-1}
  # Sin parametrizar, como `DB_HOST` o `REDIS_HOST`: el `.env` de este repo está
  # escrito para correr la API en el host —`http://localhost:9002`, el puerto
  # publicado de MinIO— y ese valor se colaba a los contenedores, donde no
  # existe. El síntoma era `ECONNREFUSED 127.0.0.1:9002` en todo contenedor que
  # tocara almacenamiento (audio, y ahora el escaneo antimalware), con la API
  # respondiendo bien desde el host. Un despliegue real apunta a su S3 con sus
  # propios manifiestos, no con este archivo.
  FILE_STORAGE_S3_ENDPOINT: http://minio:9000
  FILE_STORAGE_S3_FORCE_PATH_STYLE: ${FILE_STORAGE_S3_FORCE_PATH_STYLE:-true}
  # Prefijo propio de los archivos; `audio-assets` es el del módulo de audio (TX-34).
  FILE_STORAGE_S3_PREFIX: ${FILE_STORAGE_S3_PREFIX:-uploads}
  FILE_STORAGE_S3_ACCESS_KEY_ID: ${FILE_STORAGE_S3_ACCESS_KEY_ID:-}
  FILE_STORAGE_S3_SECRET_ACCESS_KEY: ${FILE_STORAGE_S3_SECRET_ACCESS_KEY:-}
  AUDIO_TTS_ENABLED: ${AUDIO_TTS_ENABLED:-false}
  AUDIO_TTS_PROVIDER: ${AUDIO_TTS_PROVIDER:-disabled}
  AUDIO_TTS_DEFAULT_LANGUAGE: ${AUDIO_TTS_DEFAULT_LANGUAGE:-es-419}
  AUDIO_TTS_DEFAULT_FORMAT: ${AUDIO_TTS_DEFAULT_FORMAT:-mp3_44100_128}
  AUDIO_TTS_SAMPLE_RATE: ${AUDIO_TTS_SAMPLE_RATE:-44100}
  AUDIO_TTS_VOICE_PROFILE: ${AUDIO_TTS_VOICE_PROFILE:-brand_es_latam_v1}
  AUDIO_TTS_VOICE_VERSION: ${AUDIO_TTS_VOICE_VERSION:-1}
  AUDIO_TTS_MODEL: ${AUDIO_TTS_MODEL:-eleven_v3}
  AUDIO_TTS_ALLOW_RUNTIME_GENERATION: ${AUDIO_TTS_ALLOW_RUNTIME_GENERATION:-false}
  AUDIO_TTS_MONTHLY_BUDGET_UNITS: ${AUDIO_TTS_MONTHLY_BUDGET_UNITS:-10000}
  AUDIO_TTS_SAFETY_RESERVE_UNITS: ${AUDIO_TTS_SAFETY_RESERVE_UNITS:-1000}
  AUDIO_TTS_REQUEST_TIMEOUT_MS: ${AUDIO_TTS_REQUEST_TIMEOUT_MS:-10000}
  AUDIO_TTS_MAX_RETRIES: ${AUDIO_TTS_MAX_RETRIES:-3}
  AUDIO_TTS_RETRY_BASE_MS: ${AUDIO_TTS_RETRY_BASE_MS:-500}
  AUDIO_TTS_PROD_LICENSE_CONFIRMED: ${AUDIO_TTS_PROD_LICENSE_CONFIRMED:-false}
  AUDIO_TTS_DATA_KEY: ${AUDIO_TTS_DATA_KEY:-dev-only-audio-data-key-change-before-production}
  AUDIO_TTS_CB_FAILURE_THRESHOLD: ${AUDIO_TTS_CB_FAILURE_THRESHOLD:-5}
  AUDIO_TTS_CB_OPEN_MS: ${AUDIO_TTS_CB_OPEN_MS:-30000}
  AUDIO_TTS_CB_HALF_OPEN_MAX_CALLS: ${AUDIO_TTS_CB_HALF_OPEN_MAX_CALLS:-1}
  AUDIO_TTS_MAX_CONCURRENCY: ${AUDIO_TTS_MAX_CONCURRENCY:-2}
  AUDIO_TTS_MAX_REQUESTS_PER_SECOND: ${AUDIO_TTS_MAX_REQUESTS_PER_SECOND:-2}
  AUDIO_TTS_CROSS_TEMPLATE_DEDUP: ${AUDIO_TTS_CROSS_TEMPLATE_DEDUP:-true}
  # Estas cuatro las lee el código y no las declaraba NINGÚN compose, así que
  # dentro de un contenedor corrían con su valor compilado y no había forma de
  # ajustarlas. La primera es la que más pesa: es el tope de generaciones de
  # pago por actor y día, o sea el freno que impide que una sola cuenta agote
  # el presupuesto del mes.
  AUDIO_TTS_RUNTIME_GENERATIONS_PER_ACTOR_DAY: ${AUDIO_TTS_RUNTIME_GENERATIONS_PER_ACTOR_DAY:-0}
  AUDIO_TTS_HTTP_MAX_RETRIES: ${AUDIO_TTS_HTTP_MAX_RETRIES:-0}
  AUDIO_TTS_GLOBAL_FALLBACK_TEMPLATE: ${AUDIO_TTS_GLOBAL_FALLBACK_TEMPLATE:-onboarding.fallback.generic}
  AUDIO_TTS_GC_RETENTION_DAYS: ${AUDIO_TTS_GC_RETENTION_DAYS:-90}
  ELEVENLABS_API_KEY: ${ELEVENLABS_API_KEY:-}
  ELEVENLABS_BASE_URL: ${ELEVENLABS_BASE_URL:-https://api.elevenlabs.io}
  ELEVENLABS_VOICE_ID: ${ELEVENLABS_VOICE_ID:-}
  ELEVENLABS_MODEL_ID: ${ELEVENLABS_MODEL_ID:-eleven_v3}
  ELEVENLABS_OUTPUT_FORMAT: ${ELEVENLABS_OUTPUT_FORMAT:-mp3_44100_128}
  JWT_SECRET: ${JWT_SECRET}
  JWT_ACCESS_TTL: ${JWT_ACCESS_TTL:-15m}
  JWT_REFRESH_TTL_DAYS: ${JWT_REFRESH_TTL_DAYS:-30}
  ACCOUNT_LOCK_THRESHOLD: ${ACCOUNT_LOCK_THRESHOLD:-5}
  MFA_ENCRYPTION_KEY: ${MFA_ENCRYPTION_KEY}
  # Los otros dos secretos que `appSecurityEnvSchema` exige. Faltaban en esta
  # lista, y el hueco solo se ve en un despliegue real: fuera de producción los
  # tres caen a su valor de desarrollo y nadie los echa de menos, pero con
  # `NODE_ENV=production` el esquema los declara `required()` y el contenedor
  # muere en el arranque con «"WEBHOOK_SIGNING_KEY" is required» — sin ninguna
  # pista de por qué en la máquina de al lado sí arrancaba. Declararlos aquí
  # también hace que el compose de desarrollo y el de despliegue
  # (`docker-compose.coolify.yml`) enumeren el mismo entorno.
  WEBHOOK_SIGNING_KEY: ${WEBHOOK_SIGNING_KEY:-}
  DOWNLOAD_URL_SECRET: ${DOWNLOAD_URL_SECRET:-}
  # Saltos de proxy de confianza para `req.ip`. En local no hay ninguno; en un
  # despliegue detrás de balanceador es lo que evita que el limitador de tasa
  # meta a todos los clientes en el mismo cubo. Ver `main.ts`.
  TRUST_PROXY_HOPS: ${TRUST_PROXY_HOPS:-0}
  # Primer administrador del arranque en frío. Mismo caso que `ORM_SCHEMA_SYNC`
  # más abajo: Compose usa el `.env` para sustituir `${VARIABLE}` en este YAML,
  # pero NO lo inyecta dentro de los contenedores. Mientras estas tres no
  # figuraran aquí, descomentarlas en el `.env` no tenía ningún efecto sobre la
  # API dockerizada: arrancaba sin ninguna cuenta con SECURITY_ADMIN y `POST
  # /iam/users` -que exige ese rol- quedaba inalcanzable, así que no había forma
  # de crear el primer administrador por API. Sólo funcionaba para quien corría
  # la API en el host con `yarn start:dev`.
  #
  # El default vacío conserva el opt-in: sin ambas variables el seed no hace
  # nada (`BootstrapAdminSeedService.checkGate` -> 'not-configured'), que es el
  # comportamiento que debe tener un compose que alguien copie sin leer.
  BOOTSTRAP_ADMIN_EMAIL: ${BOOTSTRAP_ADMIN_EMAIL:-}
  BOOTSTRAP_ADMIN_PASSWORD: ${BOOTSTRAP_ADMIN_PASSWORD:-}
  # Cuentas de demostración de los socios comerciales (farmacia, laboratorio,
  # imagen, aseguradora). Sin esta variable el seed no crea ninguna.
  SEED_DEMO_PASSWORD: ${SEED_DEMO_PASSWORD:-}
  SEED_DEMO_ALLOW_PRODUCTION: ${SEED_DEMO_ALLOW_PRODUCTION:-}
  BOOTSTRAP_ADMIN_ALLOW_PRODUCTION: ${BOOTSTRAP_ADMIN_ALLOW_PRODUCTION:-false}
  # Entrega del refresh token como cookie httpOnly. Apagado por defecto: cambia
  # el contrato del cliente (deja de venir en el cuerpo) y exige la allowlist de
  # CORS con `credentials: true`. Ver `src/common/auth/README.md`.
  AUTH_REFRESH_COOKIE_ENABLED: ${AUTH_REFRESH_COOKIE_ENABLED:-false}
  AUTH_REFRESH_COOKIE_SECURE: ${AUTH_REFRESH_COOKIE_SECURE:-}
  RLS_ENFORCE: ${RLS_ENFORCE:-false}
  MIKRO_ORM_DEBUG: ${MIKRO_ORM_DEBUG:-false}
  # Materialización del esquema. ESTA VARIABLE TIENE QUE ESTAR AQUÍ.
  #
  # Compose usa el `.env` solo para sustituir `${VARIABLE}` dentro de este YAML;
  # NO lo inyecta dentro de los contenedores. Una variable que no figure en este
  # bloque, el contenedor no la ve por más que esté en el `.env`. Mientras
  # `ORM_SCHEMA_SYNC` no estuvo listada, la API dockerizada caía al default del
  # código (`'safe'` en `src/orm/config/orm.env.ts`) y aplicaba DDL aditivo por
  # su cuenta al arrancar: exactamente la dirección de cambio que el protocolo
  # de 4 capas (.puml -> SQL/ -> BD -> ORM) prohíbe, y el mecanismo por el que
  # llegaron a la base tablas que el modelo canónico no declara. Fijar
  # `ORM_SCHEMA_SYNC=off` en el `.env` local NO cubría este camino: solo protege
  # a quien corre la API en el host con `yarn start:dev`.
  #
  # El default del contenedor es `dry-run` y no `off` a propósito: con `off`,
  # `onApplicationBootstrap` retorna antes de llamar a `run()` y el chequeo de
  # fidelidad tampoco corre, así que se pierde la red de seguridad. `dry-run` no
  # toca la base -registra el DDL que habría aplicado y sigue- y sí verifica
  # fidelidad. Quien quiera otro modo lo declara en su `.env`, que gana sobre
  # este default.
  ORM_SCHEMA_SYNC: ${ORM_SCHEMA_SYNC:-dry-run}
  # La verificación de fidelidad solo compara y registra advertencias; nunca
  # lanza ni aborta el arranque (`SchemaFidelityService.verifyAndReport`).
  ORM_VERIFY_FIDELITY: ${ORM_VERIFY_FIDELITY:-true}
  # Bypass de verificación DEV/TEST. Tiene que estar declarado ACÁ, no solo en
  # el `.env`: este ancla es una enumeración explícita y no hay `env_file:` en
  # ningún servicio, así que una variable que no figure en la lista sencillamente
  # no existe dentro del contenedor (ver la advertencia de más abajo sobre qué
  # hace y qué no hace el `.env` con Compose). Faltaba, y por eso el bypass era
  # inerte en Docker: la Guía de profesionales seguía filtrando por verificado
  # aunque el `.env` dijera lo contrario. El esquema Joi de la aplicación aborta
  # el arranque si esto llega en `true` con NODE_ENV=production.
  DEV_VERIFICATION_BYPASS: ${DEV_VERIFICATION_BYPASS:-false}
  # Mismo motivo: sin esta línea el interruptor de siembra no llega al
  # contenedor y no habría forma de apagarla en el stack dockerizado.
  SEED_ON_BOOT: ${SEED_ON_BOOT:-true}
  # Los 21 workers llaman la API por el nombre del servicio, no localhost.
  WORKER_API_BASE_URL: http://api:3000
  WORKER_HTTP_TIMEOUT_MS: ${WORKER_HTTP_TIMEOUT_MS:-30000}
  # Sonda HTTP de cada worker (`/health`, `/readiness`, `/status`). El mismo
  # puerto en los 20 no colisiona: cada uno corre en su propio contenedor.
  # `0` la deshabilita. Ver `src/worker/worker-health.server.ts`.
  WORKER_HEALTH_PORT: ${WORKER_HEALTH_PORT:-9100}
  # Plazo de un tick, y umbral a partir del cual un tick en vuelo se declara
  # atascado y la liveness falla para que Docker reinicie el contenedor. El
  # segundo es mayor que el primero a propósito: superarlo significa que ni
  # siquiera el aborto del plazo surtió efecto.
  WORKER_TICK_TIMEOUT_MS: ${WORKER_TICK_TIMEOUT_MS:-300000}
  WORKER_STUCK_TICK_MS: ${WORKER_STUCK_TICK_MS:-600000}
  # Drenaje y apagado. `WORKER_SHUTDOWN_TIMEOUT_MS` debe quedar por DEBAJO del
  # `stop_grace_period` de cada servicio worker, o quien fuerza la salida es un
  # SIGKILL mudo y se pierde el diagnóstico de qué seguía pendiente.
  WORKER_DRAIN_TIMEOUT_MS: ${WORKER_DRAIN_TIMEOUT_MS:-20000}
  WORKER_SHUTDOWN_TIMEOUT_MS: ${WORKER_SHUTDOWN_TIMEOUT_MS:-30000}
  # Protección del cliente HTTP del worker contra la API: reintento de
  # lecturas y techo de llamadas en vuelo por proceso.
  WORKER_HTTP_RETRY_ATTEMPTS: ${WORKER_HTTP_RETRY_ATTEMPTS:-3}
  WORKER_HTTP_MAX_CONCURRENT: ${WORKER_HTTP_MAX_CONCURRENT:-16}
  # Plazo total del apagado de la API, por debajo de su `stop_grace_period`.
  API_SHUTDOWN_TIMEOUT_MS: ${API_SHUTDOWN_TIMEOUT_MS:-30000}
  # Plazos del servidor HTTP. `keepAlive` debe superar el idle timeout del
  # balanceador que haya delante, o aparecen 502 esporádicos sin causa visible
  # en los logs de la aplicación.
  HTTP_KEEPALIVE_TIMEOUT_MS: ${HTTP_KEEPALIVE_TIMEOUT_MS:-65000}
  HTTP_HEADERS_TIMEOUT_MS: ${HTTP_HEADERS_TIMEOUT_MS:-70000}
  HTTP_REQUEST_TIMEOUT_MS: ${HTTP_REQUEST_TIMEOUT_MS:-120000}
  MESSAGING_QUEUE_CODES: ${MESSAGING_QUEUE_CODES:-}
  TS_COMPRESSION_OLDER_THAN: ${TS_COMPRESSION_OLDER_THAN:-7 days}
  TS_ROLLUP_REFRESH_WINDOW_HOURS: ${TS_ROLLUP_REFRESH_WINDOW_HOURS:-2}
  # Vacío por defecto a propósito: retención de time_series es opt-in por
  # tabla (ver `apply-retention.job.ts`). Formato: "tabla=intervalo,..."
  TS_RETENTION_POLICIES: ${TS_RETENTION_POLICIES:-}
  # Emulador standalone (`../mock-provider-server`) de los proveedores
  # externos que el backend no conecta de verdad todavía: mensajería,
  # borrado cross-store y embeddings. Configurado por DEFECTO (no opt-in):
  # el adapter real de cada job cae solo al stub "PROVIDER_NOT_CONFIGURED"
  # si esta URL queda vacía. Ver `worker/worker.env.ts` y
  # `mock-provider-server/README.md`.
  MOCK_PROVIDER_BASE_URL: ${MOCK_PROVIDER_BASE_URL:-http://mock-provider-server:4100}
  MOCK_PROVIDER_API_KEY: ${MOCK_PROVIDER_API_KEY:-}
  # Proveedor REAL de email (Gmail API). `GoogleProviderWiringService` sustituye
  # el adapter del `NotificationDeliveryJob` sólo si `isConfigured()` da true, o
  # sea si las CUATRO tienen valor; si falta una, retorna temprano y el worker se
  # queda con el emulador de arriba SIN emitir ningún error. Vacías por defecto:
  # este compose es de desarrollo local y no debe exigir credenciales de Google.
  # Se obtienen con `node tools/google-oauth/get-refresh-token.mjs` (ver
  # `.env.example`). El remitente tiene que ser la misma cuenta que dio el
  # consentimiento — lo exige `GoogleEmailClient`.
  GOOGLE_OAUTH_CLIENT_ID: ${GOOGLE_OAUTH_CLIENT_ID:-}
  GOOGLE_OAUTH_CLIENT_SECRET: ${GOOGLE_OAUTH_CLIENT_SECRET:-}
  GOOGLE_OAUTH_REFRESH_TOKEN: ${GOOGLE_OAUTH_REFRESH_TOKEN:-}
  GOOGLE_SENDER_EMAIL: ${GOOGLE_SENDER_EMAIL:-}
  # Trazas distribuidas. Apagadas por defecto; se activan con OTEL_ENABLED=true
  # en el `.env` DESPUÉS de levantar Jaeger (`yarn jaeger:up`), que se une a
  # esta misma red y por eso se alcanza por su nombre de servicio y no por
  # localhost. `OTEL_SERVICE_NAME` NO se declara aquí a propósito: cada
  # contenedor deriva el suyo del entrypoint que ejecuta
  # (`alovida-api`, `alovida-worker-messaging`, …); fijarlo aquí haría que los 21
  # procesos exportaran bajo el mismo nombre. Ver `docs/observability/`.
  # Medición de peticiones HTTP para el portal de superadministración. Apagada por
  # defecto en el código; el `.env.example` de desarrollo la enciende. Ver
  # `src/observability/http-sli/`.
  OBSERVABILITY_HTTP_SLI_ENABLED: ${OBSERVABILITY_HTTP_SLI_ENABLED:-false}
  OBSERVABILITY_HTTP_SLI_FLUSH_SECONDS: ${OBSERVABILITY_HTTP_SLI_FLUSH_SECONDS:-60}
  OTEL_ENABLED: ${OTEL_ENABLED:-false}
  OTEL_SERVICE_NAMESPACE: ${OTEL_SERVICE_NAMESPACE:-alovida}
  OTEL_SERVICE_VERSION: ${OTEL_SERVICE_VERSION:-}
  OTEL_DEPLOYMENT_ENVIRONMENT: ${OTEL_DEPLOYMENT_ENVIRONMENT:-}
  OTEL_EXPORTER_OTLP_PROTOCOL: ${OTEL_EXPORTER_OTLP_PROTOCOL:-http/protobuf}
  OTEL_EXPORTER_OTLP_TRACES_ENDPOINT: ${OTEL_EXPORTER_OTLP_TRACES_ENDPOINT_DOCKER:-http://jaeger:4318/v1/traces}
  OTEL_EXPORT_TIMEOUT_MS: ${OTEL_EXPORT_TIMEOUT_MS:-10000}
  OTEL_TRACES_SAMPLER: ${OTEL_TRACES_SAMPLER:-parentbased_traceidratio}
  OTEL_TRACES_SAMPLER_ARG: ${OTEL_TRACES_SAMPLER_ARG:-1.0}
  OTEL_PROPAGATORS: ${OTEL_PROPAGATORS:-tracecontext,baggage}
  OTEL_DIAG_LOG_LEVEL: ${OTEL_DIAG_LOG_LEVEL:-ERROR}
  OTEL_TRACE_RESPONSE_HEADER: ${OTEL_TRACE_RESPONSE_HEADER:-true}

# Límites de recursos: sin esto, un proceso Node con un memory leak o un tick
# de worker atascado puede consumir toda la RAM del host sin que nada lo
# frene. Son defaults conservadores para desarrollo/staging, no una medición
# de carga real de producción — ajustar con datos reales antes de operar así.
x-api-resources: &api-resources
  limits:
    cpus: "2.0"
    memory: 1536M
x-worker-resources: &worker-resources
  limits:
    cpus: "0.5"
    memory: 512M

# Healthcheck de los 21 workers. Hasta ahora no tenían ninguno, y eso dejaba a
# Docker con una sola señal: si el PID existe. Un worker con el tick colgado
# pasa esa comprobación indefinidamente —`docker ps` dice `Up 6 hours` con cero
# trabajo hecho—, que es exactamente el modo de fallo "worker zombi".
#
# `/health` responde 503 cuando un tick lleva más de `WORKER_STUCK_TICK_MS` en
# vuelo. Con `restart: always`, el contenedor se reinicia solo: el único remedio
# real a un bloqueo que el proceso no puede cancelar desde dentro.
#
# Deliberadamente NO se usa `/readiness` aquí: un cortacircuitos abierto lo
# pone en 503 y reiniciar por eso perdería el estado del circuito y volvería a
# castigar a la dependencia que se está recuperando — el bucle de reinicios
# clásico durante un incidente. Ver `worker-health.registry.ts`.
x-worker-healthcheck: &worker-healthcheck
  test:
    [
      "CMD",
      "node",
      "-e",
      "fetch('http://localhost:9100/health').then(r => process.exit(r.ok ? 0 : 1)).catch(() => process.exit(1))",
    ]
  interval: 15s
  timeout: 5s
  retries: 3
  start_period: 30s

services:
  # --- Bases de datos LOCALES: perfil opcional `local-db` --------------------
  # Desde 2026-09-05 el entorno de desarrollo apunta a Postgres y Mongo
  # gestionados (NeonDB y Atlas, ver `.env`), así que estos cuatro servicios
  # —los más pesados del stack— ya no se levantan con `docker compose up`.
  # Quien quiera la base en la máquina los activa explícitamente:
  #   docker compose --profile local-db up -d postgres postgres-init mongodb mongo-init
  # y apunta el `.env` a ellos (`DB_HOST=postgres` desde un contenedor,
  # `localhost:5433` desde el host). La API ya no espera por ellos (ver su
  # `depends_on`): con el perfil activo hay que dejar terminar `postgres-init`
  # antes de arrancarla, o arranca contra una base sin tablas.
  # El DDL que aplican los `*-init` sale por defecto de `database/SQL` y
  # `database/NoSQL` (la copia versionada de este repo); para aplicar el
  # modelo en caliente se exportan SQL_MODEL_DIR/NOSQL_MODEL_DIR apuntando al
  # repositorio hermano.
  postgres:
    profiles: ["local-db"]
    image: timescale/timescaledb-ha:pg18
    restart: always
    environment:
      # Variables nativas del contenedor. Deben coincidir con DB_* que usa la app.
      POSTGRES_DB: ${POSTGRES_DB}
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    ports:
      - "${POSTGRES_PORT:-5433}:5432"
    volumes:
      # timescaledb-ha usa PGDATA=/home/postgres/pgdata/data, no la ruta de la
      # imagen oficial de postgres. Montar en /var/lib/postgresql/data dejaba el
      # volumen vacío y los datos en la capa efímera del contenedor.
      - postgres_data:/home/postgres/pgdata
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U $${POSTGRES_USER} -d $${POSTGRES_DB}"]
      interval: 5s
      timeout: 5s
      retries: 5
    networks:
      - mantra-redesa-network

  # One-shot: aplica SQL/ (apply_all → apply_deferred) y los stores PG de
  # NoSQL/ (58 TimescaleDB, 59 pgvector) solo si las tablas no existen.
  postgres-init:
    profiles: ["local-db"]
    image: timescale/timescaledb-ha:pg18
    restart: "no"
    entrypoint: ["bash", "/init/bin/init-postgres.sh"]
    environment:
      POSTGRES_DB: ${POSTGRES_DB}
      POSTGRES_USER: ${POSTGRES_USER}
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      # Por defecto se aplica la copia versionada del DDL (`database/SQL` y
      # `database/NoSQL`, regenerada desde el modelo con `yarn db:vendor`).
      # Quien edita el modelo en caliente exporta SQL_MODEL_DIR/NOSQL_MODEL_DIR
      # apuntando al repositorio hermano para que el contenedor los vea sin
      # pasar por `db:vendor` (ver `database/README.md`).
      - ${SQL_MODEL_DIR:-./database/SQL}:/init/SQL:ro
      - ${NOSQL_MODEL_DIR:-./database/NoSQL}:/init/NoSQL:ro
      - ./docker/db-init:/init/bin:ro
    depends_on:
      postgres:
        condition: service_healthy
    networks:
      - mantra-redesa-network

  mongodb:
    profiles: ["local-db"]
    # 8.2.12: mongod 8.0.x aborta al arrancar en kernels >= 6.19 (SERVER-121912).
    # Este equipo corre 7.0, por eso el contenedor entraba en crash-loop.
    image: mongo:8.2.12
    restart: always
    ports:
      - "${MONGO_PORT:-27018}:27017"
    volumes:
      - mongodb_data:/data/db
    healthcheck:
      # El timeout mide el arranque de `mongosh`, no la salud de mongod.
      #
      # `mongosh` es un binario Node: su arranque en frío cuesta ~1s con la
      # máquina ociosa, pero medimos ~24s con load ~20 (la que deja `yarn smoke`,
      # que levanta la app entera y trunca las tablas). Con timeout de 5s el
      # healthcheck expiraba mientras mongod respondía `ping → ok:1` sin
      # problema, y como los 20 workers dependen de `service_healthy`, un Mongo
      # perfectamente sano bloqueaba el `docker compose start` de todos ellos.
      #
      # Se ensancha el timeout en vez de aligerar la sonda: la imagen no trae
      # otro cliente, y comprobar solo el puerto TCP daría "healthy" mientras
      # mongod aún no acepta consultas — justo lo que `depends_on` debe evitar.
      test: ["CMD-SHELL", "mongosh --eval 'db.runCommand(\"ping\").ok' --quiet"]
      interval: 10s
      timeout: 30s
      retries: 5
      start_period: 30s
    networks:
      - mantra-redesa-network

  # One-shot: crea las colecciones del módulo 55 document_store
  # (validadores $jsonSchema + índices) solo si no existen.
  mongo-init:
    profiles: ["local-db"]
    # Debe coincidir con la version de `mongodb` (ver nota alli).
    image: mongo:8.2.12
    restart: "no"
    entrypoint: ["bash", "/init/bin/init-mongo.sh"]
    environment:
      MONGO_DB: ${MONGO_DB:-salud_document_store}
    volumes:
      - ${NOSQL_MODEL_DIR:-./database/NoSQL}/55_document_store_mongodb:/init/mongo:ro
      - ./docker/db-init:/init/bin:ro
    depends_on:
      mongodb:
        condition: service_healthy
    networks:
      - mantra-redesa-network

  redis:
    image: redis:8.10-alpine
    restart: always
    command: redis-server --save 60 1 --loglevel notice
    ports:
      - "${REDIS_PORT:-6380}:6379"
    volumes:
      - redis_data:/data
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 5s
      timeout: 5s
      retries: 5
    networks:
      - mantra-redesa-network

  opensearch:
    image: opensearchproject/opensearch:3.8.0
    restart: always
    environment:
      - cluster.name=mantra-redesa-cluster
      - node.name=mantra-redesa-node1
      - discovery.type=single-node
      - bootstrap.memory_lock=true
      - "OPENSEARCH_JAVA_OPTS=-Xms512m -Xmx512m"
      - DISABLE_INSTALL_DEMO_CONFIG=true
      - DISABLE_SECURITY_PLUGIN=true
    ulimits:
      memlock:
        soft: -1
        hard: -1
      nofile:
        soft: 65536
        hard: 65536
    ports:
      - "${OPENSEARCH_PORT:-9201}:9200"
      - "${OPENSEARCH_MONITOR_PORT:-9601}:9600"
    volumes:
      - opensearch_data:/usr/share/opensearch/data
    healthcheck:
      test: ["CMD-SHELL", "curl -s http://localhost:9200 || exit 1"]
      interval: 10s
      timeout: 5s
      retries: 10
    networks:
      - mantra-redesa-network

  # One-shot: crea los índices del módulo 57 search_platform desde los
  # *.mapping.json solo si no existen.
  opensearch-init:
    image: curlimages/curl:8.21.0
    restart: "no"
    entrypoint: ["/bin/sh", "/init/bin/init-opensearch.sh"]
    volumes:
      - ${NOSQL_MODEL_DIR:-./database/NoSQL}/57_search_platform_opensearch:/init/os:ro
      - ./docker/db-init:/init/bin:ro
    depends_on:
      opensearch:
        condition: service_healthy
    networks:
      - mantra-redesa-network

  minio:
    # RustFS 1.0.1 es S3-compatible y publica imagen multi-arquitectura.
    # El nombre del servicio y los puertos siguen estables para los clientes S3 locales.
    image: rustfs/rustfs:1.0.1
    restart: always
    environment:
      RUSTFS_VOLUMES: /data
      RUSTFS_ADDRESS: "0.0.0.0:9000"
      RUSTFS_CONSOLE_ADDRESS: "0.0.0.0:9001"
      RUSTFS_CONSOLE_ENABLE: "true"
      RUSTFS_ACCESS_KEY: ${MINIO_ACCESS_KEY}
      RUSTFS_SECRET_KEY: ${MINIO_SECRET_KEY}
    ports:
      - "${MINIO_PORT:-9002}:9000"
      - "${MINIO_CONSOLE_PORT:-9003}:9001"
    volumes:
      - minio_data:/data
    healthcheck:
      test: ["CMD", "curl", "-fsS", "http://127.0.0.1:9000/health/ready"]
      interval: 5s
      timeout: 5s
      retries: 12
      start_period: 20s
    networks:
      - mantra-redesa-network

  # -----------------------------------------------------------------------
  # Motor antimalware. `common.file_versions.malware_scan_status_concept_id` y
  # el callback `POST /internal/files/versions/:vid/scan-result` existían desde
  # el principio y **no había nada que escaneara**: toda versión quedaba en
  # `SCAN_PENDING` para siempre, y la descarga servía contenido que nadie había
  # mirado. Este es el motor que faltaba; quien lo usa es `worker-files`.
  # -----------------------------------------------------------------------
  clamav:
    image: clamav/clamav:1.4
    restart: always
    # Opt-in: `docker compose up`/`yarn docker:up` normales NO lo levantan.
    # ~1 GB de RAM y ~300s de arranque para cargar firmas es caro para el
    # día a día de dev cuando la mayoría de las sesiones no tocan subida de
    # archivos. Para probar ese camino: `docker compose --profile
    # malware-scan up -d worker-files` (arrastra a clamav por depends_on).
    profiles: ["malware-scan"]
    environment:
      # El contenedor trae la base de firmas horneada; freshclam la actualiza
      # después, en segundo plano. Sin esto, el primer arranque se queda
      # esperando la descarga y el healthcheck expira.
      CLAMAV_NO_FRESHCLAMD: "false"
    volumes:
      - clamav_data:/var/lib/clamav
    healthcheck:
      # `clamdcheck` habla el mismo protocolo que el worker: si responde, el
      # demonio está cargado y listo para escanear, no sólo el puerto abierto.
      # El arranque carga ~9 millones de firmas a memoria y tarda minutos en un
      # equipo modesto: por eso el `start_period` es largo.
      test: ["CMD-SHELL", "clamdcheck.sh || exit 1"]
      interval: 30s
      timeout: 30s
      retries: 10
      start_period: 300s
    networks:
      - mantra-redesa-network

  # -----------------------------------------------------------------------
  # Emulador standalone de proveedores externos (proyecto NestJS
  # independiente en `../mock-provider-server`, sin código ni dependencias
  # compartidas con el backend principal). `messaging`, `cross_store_consistency`
  # y `vector_rag` le apuntan por defecto vía `MOCK_PROVIDER_BASE_URL` (arriba)
  # para poder ejercitar sus workers de punta a punta sin credenciales reales
  # de vendor. Se puede levantar también suelto (`yarn start:dev` dentro de
  # esa carpeta) sin este compose — ver su README.
  # -----------------------------------------------------------------------
  mock-provider-server:
    image: mantra-redesa-mock-provider-server:local
    build:
      context: ./mock-provider-server
      dockerfile: Dockerfile
    restart: always
    environment:
      PORT: "4100"
      MOCK_API_KEY: ${MOCK_PROVIDER_API_KEY:-}
      NOTIFICATIONS_FAILURE_RATE: ${MOCK_NOTIFICATIONS_FAILURE_RATE:-0.1}
      DELETIONS_FAILURE_RATE: ${MOCK_DELETIONS_FAILURE_RATE:-0.05}
      SIMULATED_LATENCY_MS: ${MOCK_SIMULATED_LATENCY_MS:-50}
      # Verificación de identidad. Estas dos NO estaban declaradas y por eso el
      # comportamiento por defecto -aceptar TODA verificación- solo se podía
      # descubrir leyendo el código del emulador. Con la tasa en 0, el documento
      # de identidad de un paciente y la matrícula de un médico salen ACCEPTED
      # por igual; subirla es cómo se prueba el camino de rechazo.
      IDENTITY_VERIFICATION_REJECTION_RATE: ${MOCK_IDENTITY_REJECTION_RATE:-0}
      # Retardo del veredicto: la autoridad acepta la solicitud al instante y
      # tarda en resolverla. Es lo que ejercita el bucle de espera del worker.
      IDENTITY_VERIFICATION_DELAY_MS: ${MOCK_IDENTITY_DELAY_MS:-10000}
    ports:
      - "${MOCK_PROVIDER_PORT:-4100}:4100"
    healthcheck:
      test: ["CMD-SHELL", "wget -qO- http://localhost:4100/health || exit 1"]
      interval: 5s
      timeout: 5s
      retries: 5
    networks:
      - mantra-redesa-network

  # -----------------------------------------------------------------------
  # API + workers. Misma imagen para los 21 workers (build una sola vez; el
  # `command` es lo único que cambia). Cada worker es SU PROPIO proceso/
  # contenedor — no un único monolito con los 21 dominios adentro — para que
  # un fallo o un pico de carga en uno no toque a los demás, y cada uno
  # escale por separado. Ver `PLAN-CORRECCION-WORKERS-2026-07-28.md`.
  # -----------------------------------------------------------------------
  api:
    image: mantra-redesa-api:local
    build:
      context: .
      dockerfile: Dockerfile
      # Se pasan desde el entorno para que el arranque pueda decir qué código
      # corre. Vacíos quedan en "desconocido"; para llenarlos:
      #   GIT_COMMIT=$(git rev-parse HEAD) BUILD_TIME=$(date -Iseconds) docker compose build api
      args:
        GIT_COMMIT: ${GIT_COMMIT:-desconocido}
        BUILD_TIME: ${BUILD_TIME:-desconocido}
        APP_VERSION: ${APP_VERSION:-desconocido}
    restart: always
    command: ["node", "dist/src/main.js"]
    environment:
      <<: *app-env
    deploy:
      resources: *api-resources
    ports:
      - "${PORT:-3000}:3000"
    volumes:
      - api_storage:/app/storage
    # Por encima de API_SHUTDOWN_TIMEOUT_MS (30 s): el drenaje de las peticiones
    # en vuelo debe poder terminar antes del SIGKILL.
    stop_grace_period: 45s
    healthcheck:
      # Sin curl/wget en `node:24-bookworm-slim`: se usa el `fetch` nativo de
      # Node en vez de instalar un paquete extra sólo para el healthcheck.
      test:
        [
          "CMD",
          "node",
          "-e",
          "fetch('http://localhost:3000/health').then(r => process.exit(r.ok ? 0 : 1)).catch(() => process.exit(1))",
        ]
      interval: 10s
      timeout: 5s
      retries: 5
      start_period: 120s
    depends_on:
      # Postgres y Mongo ya NO figuran acá: viven fuera del compose (Neon y
      # Atlas, con el esquema y los seeds aplicados desde `salud-db/`) y los
      # contenedores locales quedaron bajo el perfil `local-db`. Un `depends_on`
      # sobre un servicio de otro perfil lo arrastraría al `up` de todos los
      # días, que es justo lo que se quiere evitar. El precio, sólo para quien
      # active el perfil: arrancar `postgres-init`/`mongo-init` antes que la
      # API — `TerminologySeedService` corre en `onApplicationBootstrap` y
      # necesita el esquema ya aplicado, o arranca contra una base sin tablas.
      # OpenSearch y Redis siguen siendo locales y sí se esperan:
      # search_platform asume sus índices creados por `opensearch-init`.
      opensearch:
        condition: service_healthy
      opensearch-init:
        condition: service_completed_successfully
      redis:
        condition: service_healthy
    networks:
      - mantra-redesa-network

  # Escaneo antimalware de las versiones subidas: descubre el lote pendiente,
  # lee los bytes por el adaptador de almacenamiento —el mismo que la API— y los
  # pasa por clamd. Apagado por defecto (`MALWARE_SCAN_ENABLED`), porque sin un
  # motor detrás sería un proceso dando vueltas sin escanear.
  worker-files:
    image: mantra-redesa-api:local
    build:
      context: .
      dockerfile: Dockerfile
    restart: always
    # Mismo profile que `clamav` (ver su comentario): sin este worker nadie
    # escanea, pero eso es exactamente lo que hace `MALWARE_SCAN_ENABLED=false`
    # en el resto de la app -las versiones quedan en SCAN_PENDING, no rompe
    # nada-, así que no hace falta pagar el arranque de clamav para el dev
    # de todos los días.
    profiles: ["malware-scan"]
    command: ["node", "dist/src/worker-files.js"]
    environment:
      <<: *app-env
      # El default acá DEBE coincidir con `malware-scan.env.ts` (false):
      # estaba en `true`, contradiciendo tanto el código como `.env.example`,
      # y forzaba a levantar clamav siempre aunque nadie fuera a escanear
      # nada.
      MALWARE_SCAN_ENABLED: ${MALWARE_SCAN_ENABLED:-false}
      CLAMD_HOST: ${CLAMD_HOST:-clamav}
      CLAMD_PORT: ${CLAMD_PORT:-3310}
    deploy:
      resources: *worker-resources
    healthcheck: *worker-healthcheck
    stop_grace_period: 45s
    depends_on:
      api:
        condition: service_healthy
      clamav:
        condition: service_healthy
    networks:
      - mantra-redesa-network

  worker-billing:
    image: mantra-redesa-api:local
    build:
      context: .
      dockerfile: Dockerfile
    restart: always
    command: ["node", "dist/src/worker-billing.js"]
    environment:
      <<: *app-env
    deploy:
      resources: *worker-resources
    healthcheck: *worker-healthcheck
    # Por encima de WORKER_SHUTDOWN_TIMEOUT_MS (30 s) para que el drenaje de los
    # ticks en vuelo termine antes de que Docker mande SIGKILL. Con el default
    # de 10 s, cada despliegue cortaría lotes a la mitad.
    stop_grace_period: 45s
    depends_on:
      api:
        condition: service_healthy
    networks:
      - mantra-redesa-network

  worker-automation:
    image: mantra-redesa-api:local
    build:
      context: .
      dockerfile: Dockerfile
    restart: always
    command: ["node", "dist/src/worker-automation.js"]
    environment:
      <<: *app-env
    deploy:
      resources: *worker-resources
    healthcheck: *worker-healthcheck
    # Por encima de WORKER_SHUTDOWN_TIMEOUT_MS (30 s) para que el drenaje de los
    # ticks en vuelo termine antes de que Docker mande SIGKILL. Con el default
    # de 10 s, cada despliegue cortaría lotes a la mitad.
    stop_grace_period: 45s
    depends_on:
      api:
        condition: service_healthy
    networks:
      - mantra-redesa-network

  worker-consent:
    image: mantra-redesa-api:local
    build:
      context: .
      dockerfile: Dockerfile
    restart: always
    command: ["node", "dist/src/worker-consent.js"]
    environment:
      <<: *app-env
    deploy:
      resources: *worker-resources
    healthcheck: *worker-healthcheck
    # Por encima de WORKER_SHUTDOWN_TIMEOUT_MS (30 s) para que el drenaje de los
    # ticks en vuelo termine antes de que Docker mande SIGKILL. Con el default
    # de 10 s, cada despliegue cortaría lotes a la mitad.
    stop_grace_period: 45s
    depends_on:
      api:
        condition: service_healthy
    networks:
      - mantra-redesa-network

  worker-cross_store_consistency:
    image: mantra-redesa-api:local
    build:
      context: .
      dockerfile: Dockerfile
    restart: always
    command: ["node", "dist/src/worker-cross_store_consistency.js"]
    environment:
      <<: *app-env
    deploy:
      resources: *worker-resources
    healthcheck: *worker-healthcheck
    # Por encima de WORKER_SHUTDOWN_TIMEOUT_MS (30 s) para que el drenaje de los
    # ticks en vuelo termine antes de que Docker mande SIGKILL. Con el default
    # de 10 s, cada despliegue cortaría lotes a la mitad.
    stop_grace_period: 45s
    depends_on:
      api:
        condition: service_healthy
      mock-provider-server:
        condition: service_healthy
    networks:
      - mantra-redesa-network

  worker-delegated_access:
    image: mantra-redesa-api:local
    build:
      context: .
      dockerfile: Dockerfile
    restart: always
    command: ["node", "dist/src/worker-delegated_access.js"]
    environment:
      <<: *app-env
    deploy:
      resources: *worker-resources
    healthcheck: *worker-healthcheck
    # Por encima de WORKER_SHUTDOWN_TIMEOUT_MS (30 s) para que el drenaje de los
    # ticks en vuelo termine antes de que Docker mande SIGKILL. Con el default
    # de 10 s, cada despliegue cortaría lotes a la mitad.
    stop_grace_period: 45s
    depends_on:
      api:
        condition: service_healthy
    networks:
      - mantra-redesa-network

  worker-health_context:
    image: mantra-redesa-api:local
    build:
      context: .
      dockerfile: Dockerfile
    restart: always
    command: ["node", "dist/src/worker-health_context.js"]
    environment:
      <<: *app-env
    deploy:
      resources: *worker-resources
    healthcheck: *worker-healthcheck
    # Por encima de WORKER_SHUTDOWN_TIMEOUT_MS (30 s) para que el drenaje de los
    # ticks en vuelo termine antes de que Docker mande SIGKILL. Con el default
    # de 10 s, cada despliegue cortaría lotes a la mitad.
    stop_grace_period: 45s
    depends_on:
      api:
        condition: service_healthy
    networks:
      - mantra-redesa-network

  worker-identity_assurance:
    image: mantra-redesa-api:local
    build:
      context: .
      dockerfile: Dockerfile
    restart: always
    command: ["node", "dist/src/worker-identity_assurance.js"]
    environment:
      <<: *app-env
    deploy:
      resources: *worker-resources
    healthcheck: *worker-healthcheck
    # Por encima de WORKER_SHUTDOWN_TIMEOUT_MS (30 s) para que el drenaje de los
    # ticks en vuelo termine antes de que Docker mande SIGKILL. Con el default
    # de 10 s, cada despliegue cortaría lotes a la mitad.
    stop_grace_period: 45s
    depends_on:
      api:
        condition: service_healthy
    networks:
      - mantra-redesa-network

  worker-integrations:
    image: mantra-redesa-api:local
    build:
      context: .
      dockerfile: Dockerfile
    restart: always
    command: ["node", "dist/src/worker-integrations.js"]
    environment:
      <<: *app-env
    deploy:
      resources: *worker-resources
    healthcheck: *worker-healthcheck
    # Por encima de WORKER_SHUTDOWN_TIMEOUT_MS (30 s) para que el drenaje de los
    # ticks en vuelo termine antes de que Docker mande SIGKILL. Con el default
    # de 10 s, cada despliegue cortaría lotes a la mitad.
    stop_grace_period: 45s
    depends_on:
      api:
        condition: service_healthy
    networks:
      - mantra-redesa-network

  worker-audio-assets:
    image: mantra-redesa-api:local
    build:
      context: .
      dockerfile: Dockerfile
    restart: always
    command: ["node", "dist/src/worker-audio-assets.js"]
    environment:
      <<: *app-env
      MESSAGING_QUEUE_CODES: audio-generation
    volumes:
      - api_storage:/app/storage
    deploy:
      resources: *worker-resources
    healthcheck: *worker-healthcheck
    stop_grace_period: 45s
    depends_on:
      api:
        condition: service_healthy
    networks:
      - mantra-redesa-network

  worker-messaging:
    image: mantra-redesa-api:local
    build:
      context: .
      dockerfile: Dockerfile
    restart: always
    command: ["node", "dist/src/worker-messaging.js"]
    environment:
      <<: *app-env
    deploy:
      resources: *worker-resources
    healthcheck: *worker-healthcheck
    # Por encima de WORKER_SHUTDOWN_TIMEOUT_MS (30 s) para que el drenaje de los
    # ticks en vuelo termine antes de que Docker mande SIGKILL. Con el default
    # de 10 s, cada despliegue cortaría lotes a la mitad.
    stop_grace_period: 45s
    depends_on:
      api:
        condition: service_healthy
      mock-provider-server:
        condition: service_healthy
    networks:
      - mantra-redesa-network

  worker-pharmacy_inventory:
    image: mantra-redesa-api:local
    build:
      context: .
      dockerfile: Dockerfile
    restart: always
    command: ["node", "dist/src/worker-pharmacy_inventory.js"]
    environment:
      <<: *app-env
    deploy:
      resources: *worker-resources
    healthcheck: *worker-healthcheck
    # Por encima de WORKER_SHUTDOWN_TIMEOUT_MS (30 s) para que el drenaje de los
    # ticks en vuelo termine antes de que Docker mande SIGKILL. Con el default
    # de 10 s, cada despliegue cortaría lotes a la mitad.
    stop_grace_period: 45s
    depends_on:
      api:
        condition: service_healthy
    networks:
      - mantra-redesa-network

  worker-promotions:
    image: mantra-redesa-api:local
    build:
      context: .
      dockerfile: Dockerfile
    restart: always
    command: ["node", "dist/src/worker-promotions.js"]
    environment:
      <<: *app-env
    deploy:
      resources: *worker-resources
    healthcheck: *worker-healthcheck
    # Por encima de WORKER_SHUTDOWN_TIMEOUT_MS (30 s) para que el drenaje de los
    # ticks en vuelo termine antes de que Docker mande SIGKILL. Con el default
    # de 10 s, cada despliegue cortaría lotes a la mitad.
    stop_grace_period: 45s
    depends_on:
      api:
        condition: service_healthy
    networks:
      - mantra-redesa-network

  worker-data_catalog:
    image: mantra-redesa-api:local
    build:
      context: .
      dockerfile: Dockerfile
    restart: always
    command: ["node", "dist/src/worker-data_catalog.js"]
    environment:
      <<: *app-env
    deploy:
      resources: *worker-resources
    healthcheck: *worker-healthcheck
    stop_grace_period: 45s
    depends_on:
      api:
        condition: service_healthy
    networks:
      - mantra-redesa-network

  worker-qa_lab:
    image: mantra-redesa-api:local
    build:
      context: .
      dockerfile: Dockerfile
    restart: always
    command: ["node", "dist/src/worker-qa_lab.js"]
    environment:
      <<: *app-env
    deploy:
      resources: *worker-resources
    healthcheck: *worker-healthcheck
    # Por encima de WORKER_SHUTDOWN_TIMEOUT_MS (30 s) para que el drenaje de los
    # ticks en vuelo termine antes de que Docker mande SIGKILL. Con el default
    # de 10 s, cada despliegue cortaría lotes a la mitad.
    stop_grace_period: 45s
    depends_on:
      api:
        condition: service_healthy
    networks:
      - mantra-redesa-network

  worker-community:
    image: mantra-redesa-api:local
    build:
      context: .
      dockerfile: Dockerfile
    restart: always
    command: ["node", "dist/src/worker-community.js"]
    environment:
      <<: *app-env
    deploy:
      resources: *worker-resources
    healthcheck: *worker-healthcheck
    # Por encima de WORKER_SHUTDOWN_TIMEOUT_MS (30 s), igual que el resto: el
    # fan-out en vuelo tiene que terminar antes de que Docker mande SIGKILL.
    stop_grace_period: 45s
    depends_on:
      api:
        condition: service_healthy
    networks:
      - mantra-redesa-network

  # Barrido de vencimientos y abandonos de las admisiones de profesionales.
  # Cadencia: ADMISSIONS_EXPIRE_SWEEP_CRON (por defecto, cada hora en punto);
  # apagarlo: ADMISSIONS_EXPIRE_SWEEP_ENABLED=false. Dos réplicas son inocuas: el
  # cerrojo está en la API (`POST /admissions/expire-sweep`).
  worker-profiles:
    image: mantra-redesa-api:local
    build:
      context: .
      dockerfile: Dockerfile
    restart: always
    command: ["node", "dist/src/worker-profiles.js"]
    environment:
      <<: *app-env
    deploy:
      resources: *worker-resources
    healthcheck: *worker-healthcheck
    # Por encima de WORKER_SHUTDOWN_TIMEOUT_MS (30 s), igual que el resto: un
    # barrido en vuelo termina antes de que Docker mande SIGKILL.
    stop_grace_period: 45s
    depends_on:
      api:
        condition: service_healthy
    networks:
      - mantra-redesa-network

  worker-read_models:
    image: mantra-redesa-api:local
    build:
      context: .
      dockerfile: Dockerfile
    restart: always
    command: ["node", "dist/src/worker-read_models.js"]
    environment:
      <<: *app-env
    deploy:
      resources: *worker-resources
    healthcheck: *worker-healthcheck
    # Por encima de WORKER_SHUTDOWN_TIMEOUT_MS (30 s) para que el drenaje de los
    # ticks en vuelo termine antes de que Docker mande SIGKILL. Con el default
    # de 10 s, cada despliegue cortaría lotes a la mitad.
    stop_grace_period: 45s
    depends_on:
      api:
        condition: service_healthy
    networks:
      - mantra-redesa-network

  worker-reporting:
    image: mantra-redesa-api:local
    build:
      context: .
      dockerfile: Dockerfile
    restart: always
    command: ["node", "dist/src/worker-reporting.js"]
    environment:
      <<: *app-env
    deploy:
      resources: *worker-resources
    healthcheck: *worker-healthcheck
    # Por encima de WORKER_SHUTDOWN_TIMEOUT_MS (30 s) para que el drenaje de los
    # ticks en vuelo termine antes de que Docker mande SIGKILL. Con el default
    # de 10 s, cada despliegue cortaría lotes a la mitad.
    stop_grace_period: 45s
    depends_on:
      api:
        condition: service_healthy
    networks:
      - mantra-redesa-network

  worker-scheduling:
    image: mantra-redesa-api:local
    build:
      context: .
      dockerfile: Dockerfile
    restart: always
    command: ["node", "dist/src/worker-scheduling.js"]
    environment:
      <<: *app-env
    deploy:
      resources: *worker-resources
    healthcheck: *worker-healthcheck
    # Por encima de WORKER_SHUTDOWN_TIMEOUT_MS (30 s) para que el drenaje de los
    # ticks en vuelo termine antes de que Docker mande SIGKILL. Con el default
    # de 10 s, cada despliegue cortaría lotes a la mitad.
    stop_grace_period: 45s
    depends_on:
      api:
        condition: service_healthy
    networks:
      - mantra-redesa-network

  worker-tracking:
    image: mantra-redesa-api:local
    build:
      context: .
      dockerfile: Dockerfile
    restart: always
    command: ["node", "dist/src/worker-tracking.js"]
    environment:
      <<: *app-env
    deploy:
      resources: *worker-resources
    healthcheck: *worker-healthcheck
    # Por encima de WORKER_SHUTDOWN_TIMEOUT_MS (30 s) para que el drenaje de los
    # ticks en vuelo termine antes de que Docker mande SIGKILL. Con el default
    # de 10 s, cada despliegue cortaría lotes a la mitad.
    stop_grace_period: 45s
    depends_on:
      api:
        condition: service_healthy
    networks:
      - mantra-redesa-network

  worker-workflow:
    image: mantra-redesa-api:local
    build:
      context: .
      dockerfile: Dockerfile
    restart: always
    command: ["node", "dist/src/worker-workflow.js"]
    environment:
      <<: *app-env
    deploy:
      resources: *worker-resources
    healthcheck: *worker-healthcheck
    # Por encima de WORKER_SHUTDOWN_TIMEOUT_MS (30 s) para que el drenaje de los
    # ticks en vuelo termine antes de que Docker mande SIGKILL. Con el default
    # de 10 s, cada despliegue cortaría lotes a la mitad.
    stop_grace_period: 45s
    depends_on:
      api:
        condition: service_healthy
    networks:
      - mantra-redesa-network

  worker-vector_rag:
    image: mantra-redesa-api:local
    build:
      context: .
      dockerfile: Dockerfile
    restart: always
    command: ["node", "dist/src/worker-vector_rag.js"]
    environment:
      <<: *app-env
    deploy:
      resources: *worker-resources
    healthcheck: *worker-healthcheck
    # Por encima de WORKER_SHUTDOWN_TIMEOUT_MS (30 s) para que el drenaje de los
    # ticks en vuelo termine antes de que Docker mande SIGKILL. Con el default
    # de 10 s, cada despliegue cortaría lotes a la mitad.
    stop_grace_period: 45s
    depends_on:
      api:
        condition: service_healthy
      mock-provider-server:
        condition: service_healthy
    networks:
      - mantra-redesa-network

  worker-lakehouse:
    image: mantra-redesa-api:local
    build:
      context: .
      dockerfile: Dockerfile
    restart: always
    command: ["node", "dist/src/worker-lakehouse.js"]
    environment:
      <<: *app-env
    deploy:
      resources: *worker-resources
    healthcheck: *worker-healthcheck
    # Por encima de WORKER_SHUTDOWN_TIMEOUT_MS (30 s) para que el drenaje de los
    # ticks en vuelo termine antes de que Docker mande SIGKILL. Con el default
    # de 10 s, cada despliegue cortaría lotes a la mitad.
    stop_grace_period: 45s
    depends_on:
      api:
        condition: service_healthy
    networks:
      - mantra-redesa-network

  worker-time_series:
    image: mantra-redesa-api:local
    build:
      context: .
      dockerfile: Dockerfile
    restart: always
    command: ["node", "dist/src/worker-time_series.js"]
    environment:
      <<: *app-env
    deploy:
      resources: *worker-resources
    healthcheck: *worker-healthcheck
    # Por encima de WORKER_SHUTDOWN_TIMEOUT_MS (30 s) para que el drenaje de los
    # ticks en vuelo termine antes de que Docker mande SIGKILL. Con el default
    # de 10 s, cada despliegue cortaría lotes a la mitad.
    stop_grace_period: 45s
    depends_on:
      api:
        condition: service_healthy
    networks:
      - mantra-redesa-network

# -------------------------------------------------------------------------
# Volúmenes de datos (persistentes, gestionados por Docker).
# Los nombres llevan el prefijo del proyecto para no colisionar con otros
# stacks en la misma máquina. Para inspeccionar: `docker volume ls`.
#
# ¿Quieres los datos en una carpeta concreta del host en lugar del área de
# Docker? Descomenta driver/driver_opts en el volumen deseado y crea la carpeta
# (en Windows usa una ruta tipo //c/Users/tu-usuario/alovida-data/postgres):
#
#   postgres_data:
#     name: ${COMPOSE_PROJECT_NAME:-mantra-redesa}_postgres_data
#     driver: local
#     driver_opts:
#       type: none
#       o: bind
#       device: ${POSTGRES_DATA_DIR:-./data/postgres}
# -------------------------------------------------------------------------
volumes:
  # `FileStorageModule` sólo tiene el adaptador local en disco hoy (MinIO está
  # provisionado pero sin un `S3FileStorageAdapter` que lo use — ver
  # `src/common/storage/README.md`); hasta que exista ese adaptador, sin este
  # volumen cada `docker compose up`/redeploy recrea el contenedor `api` con
  # `storage/uploads` vacío y los archivos subidos se pierden.
  api_storage:
    name: ${COMPOSE_PROJECT_NAME:-mantra-redesa}_api_storage
  postgres_data:
    name: ${COMPOSE_PROJECT_NAME:-mantra-redesa}_postgres_data
  mongodb_data:
    name: ${COMPOSE_PROJECT_NAME:-mantra-redesa}_mongodb_data
  # Base de firmas de ClamAV: sin volumen, cada recreación del contenedor
  # vuelve a descargar ~300 MiB antes de poder escanear nada.
  clamav_data:
    name: ${COMPOSE_PROJECT_NAME:-mantra-redesa}_clamav_data
  redis_data:
    name: ${COMPOSE_PROJECT_NAME:-mantra-redesa}_redis_data
  opensearch_data:
    name: ${COMPOSE_PROJECT_NAME:-mantra-redesa}_opensearch_data
  minio_data:
    name: ${COMPOSE_PROJECT_NAME:-mantra-redesa}_minio_data

networks:
  mantra-redesa-network:
    name: ${COMPOSE_PROJECT_NAME:-mantra-redesa}-network