# JNPF 全栈一键启动 = 微服务 + 基础设施（Redis/PG）+ 前端 cx-web，本地/服务器同一份编排
# （RocketMQ 已于 2026-08-10 移除，事件总线改 Redis pub/sub，见补丁 #10）
#
# 地址拓扑三层规则（详见 docs/docker-compose-guide.md）：
#   配置/发现（补丁 #8 起）：镜像烧入 config/shared 静态配置 + SimpleDiscoveryClient 静态实例列表，
#     无独立注册/配置中心容器；Dubbo LogProvider 改 registry-less 直连 dubbo://cx-platform:20880（原 cx-system，2026-08-11 聚合）
#   数据面（业务→PG/Redis）：本地与交付一致=服务名直连
#     cx-postgres:5432 等（release-checklist §0.10）
#   对外宣告（ApiDomain）：cx-infra（浏览器+后端双消费方；本地 hosts + 容器 extra_hosts 双侧解析）
#
# 前提：
#   1. 宿主 /etc/hosts 含「127.0.0.1 cx-infra」（本机代理软件须加 cx-infra 直连规则，L026）
#   2. 构建前先打包：mvn clean package -DskipTests
#   3. 库在哪由 .env 的 CUSTOMER_DB_HOST 决定，两种形态：
#      远端客户库（开发机/测试环境，CUSTOMER_DB_HOST=YOUR_DB_HOST）：本机不起 PG，什么都不用准备
#      栈内 PG（交付/正式，CUSTOMER_DB_HOST=cx-postgres）：.env 设 COMPOSE_PROFILES=localdb，
#        且全新机器先 docker volume create postgres_pgdata 并灌数据（见 docker/postgres/migration/）
#   4. 宿主上不能有同端口进程（旧 nohup 服务 / Homebrew redis 均须停）
#
# 基础设施镜像统一 linux/amd64 + 华为云 SWR 源（swr.cn-north-4.myhuaweicloud.com/ddn-k8s/...）：
#   本地 Apple Silicon 经 Rosetta 跑，x86 服务器原生；一份 compose 两侧零差异
#
# ⚠️ 第三方基础设施镜像在本文件里用**短名**（cx-redis 等），
#   它们是 `make pull-infra` 从上述 SWR 长名 retag 出来的本地别名（docker tag 只挂别名、
#   不复制数据）。**因此裸 `docker compose pull` 拉不到它们**——本地没有这些 tag 时
#   Docker 会去 docker.io 找不存在的 library/cx-redis。起栈一律走 `make up`
#   （其 images 目标已含 pull-infra）或离线包的 `make load`。preflight 会在 up 前拦截缺失。
#
# 端口策略（Backlog A 安全加固，2026-07-17；Backlog F 增 80）：
#   本文件=交付基线，发布 cx-web 80（页面入口）+ gateway 30000（API/ApiDomain 直连口）；
#   其余端口（PG/Redis/引擎/业务调试口）在 docker-compose.override.yml（本地开发用，compose 自动合并，交付包不含）。
#   交付环境数据面服务名直连（见 docs/release-checklist.md §0），不依赖 hairpin 发布端口。
#
# 凭据策略：密码/密钥一律经 .env 注入（${VAR:?} 必填，缺失时 compose 直接报错），仓库只留 .env.example 占位。
#
# 用法：
#   cp .env.example .env                           # 首次；本地默认值可直接用，交付必须改值
#   docker compose build && docker compose up -d   # 冷启动自动串行：PG → 业务
#   docker compose --profile extra up -d           # 附带 scheduletask（app 已并入 cx-platform）

name: cx

# 公共环境变量（单独成锚点，便于某服务只覆盖个别变量而不丢其余：
#   environment:
#     <<: *cx-env
#     JAVA_TOOL_OPTIONS: -Xms512m -Xmx1536m
# ）
x-cx-env: &cx-env
  # 官方 Dockerfile ENTRYPOINT 无 $JAVA_OPTS 透传，堆参数走 JVM 自动拾取的 JAVA_TOOL_OPTIONS
  # stdout/stderr.encoding（2026-08-11）：JDK 19+ 起 System.out 的编码由 stdout.encoding 决定，
  # 与 Dockerfile 里已有的 -Dfile.encoding=utf8 **无关**；rocky 基础镜像没设 locale
  # （native encoding = ANSI_X3.4-1968），于是中文 println 逐字变 `?`——gateway 的
  # 「网关启动成功」在日志里就是那行 `??????`。走 JAVA_TOOL_OPTIONS 而不是改 Dockerfile，
  # 是为了零重建、且一处覆盖全部服务。
  JAVA_TOOL_OPTIONS: -Xms256m -Xmx768m -Dstdout.encoding=UTF-8 -Dstderr.encoding=UTF-8
  # Spring Boot 的 ASCII banner：容器日志里没人看，白占 8 行。
  # 🔴 引号不能省：YAML 1.1 里裸 off 会被解析成布尔 false，compose 拒绝布尔型 environment 值。
  SPRING_MAIN_BANNER_MODE: "off"
  # 日志落盘根目录（2026-08-11）：config/shared/logger.yaml 的 log.path 占位符消费，
  # 与下方 x-cx 的 volumes 那行**成对**——改一个必须改另一个，否则日志又回到容器可写层。
  # 各服务自动写 /data/jnpf-logs/<spring.application.name>/ 子目录，故一个挂载点够全部服务用。
  JNPF_LOG_DIR: /data/jnpf-logs
  # resources.yaml: storage-path ${JNPF_FILE_DIR:/Users/Shared/}（容器内路径），
  # 文件落 <根>/jnpf-resources/
  JNPF_FILE_DIR: /data/jnpf-files/
  # 补丁 #8：域名四键（system-config.yaml 占位符消费；默认值即本机开发形态，交付在 .env 设真值）
  JNPF_API_DOMAIN: ${JNPF_API_DOMAIN:-http://cx-infra:30000}
  JNPF_FRONT_DOMAIN: ${JNPF_FRONT_DOMAIN:-http://localhost/}
  JNPF_APP_DOMAIN: ${JNPF_APP_DOMAIN:-http://localhost/}
  JNPF_FLOW_DOMAIN: ${JNPF_FLOW_DOMAIN:-http://cx-flow-engine:31000}
  # 🔴 Dubbo LogProvider 消费端直连地址（2026-08-11 平台聚合必须加）。
  # 消费方是 jnpf-common-springaop 的 RequestLogAspect / ResultException，它们的
  # @DubboReference 默认值**硬编码为 dubbo://cx-system:20880**——而 cx-system 已并入
  # cx-platform、容器不复存在，不覆盖就每分钟刷 UnknownHostException: cx-system。
  # 宿主栈（start-all.sh）设的是 dubbo://127.0.0.1:20880，不含服务名，故宿主形态**测不出**
  # 这个问题；它只在容器形态暴露。改服务名时这里必须跟着改。
  # 遗留优化项：聚合后 provider 与 consumer 同处一个 JVM，本可用 injvm 走进程内直调，
  # 省掉这一跳本地 TCP 与重连定时器；但那要改平台代码的 injvm=false，另案评估。
  JNPF_LOG_PROVIDER_URL: ${JNPF_LOG_PROVIDER_URL:-dubbo://cx-platform:20880}
  # 客户坐标（adr-multi-customer-db-isolation §3）：业务库经 config/shared/datasource.yaml 的
  # ${CUSTOMER_DB_HOST}/${CUSTOMER_DB_PORT} 占位符消费，故必须透传进业务容器。
  # 与下方 cx-flow-engine 的 FLOW_DB_URL 同源——两库要么一起切要么一起不切。
  CUSTOMER_DB_HOST: ${CUSTOMER_DB_HOST:-cx-postgres}
  CUSTOMER_DB_PORT: ${CUSTOMER_DB_PORT:-5432}
  # 业务库账号也透传：config/shared/datasource.yaml 的 username/password 同样是占位符，
  # 否则每切一个客户就得改这份文件的默认值，「单一开关」就名存实亡了。
  JNPF_APP_DB_USER: ${JNPF_APP_DB_USER:-jnpf_app}
  JNPF_APP_DB_PASSWORD: ${JNPF_APP_DB_PASSWORD:?缺 JNPF_APP_DB_PASSWORD，见 .env.example}
  # Redis 密码透传给业务服务（datasource.yaml 的 spring.redis.password 占位符消费）。
  # 此前业务侧读的是 yaml 明文字面值、仅 cx-redis 容器自己吃这个 env——两边靠碰巧同值工作；
  # 参数化后交付环境改 .env 一处即可轮换（2026-08-06 用户指出后收口）。
  JNPF_REDIS_PASSWORD: ${JNPF_REDIS_PASSWORD:?缺 JNPF_REDIS_PASSWORD，见 .env.example}
  # Redis 坐标透传（datasource.yaml 的 spring.redis.host/port 占位符消费）。
  # JNPF_DOCKER_REDIS_* 是容器侧专用覆盖：宿主 JVM 可继续使用 127.0.0.1，容器则通过
  # cx-infra(host-gateway) 访问宿主 Redis。未设置专用覆盖时沿用 JNPF_REDIS_*，兼容远端 Redis。
  # 两组都不设 = 栈内 cx-redis（交付/本机容器形态，见 .env.example §5）。
  # 🔴 必须写 ${VAR:-默认值} 而非裸 ${VAR}：宿主未设时裸形式注入空串，会把 yaml 里的默认值静默清空。
  JNPF_REDIS_HOST: ${JNPF_DOCKER_REDIS_HOST:-${JNPF_REDIS_HOST:-cx-redis}}
  JNPF_REDIS_PORT: ${JNPF_DOCKER_REDIS_PORT:-${JNPF_REDIS_PORT:-6379}}

x-cx: &cx
  # 业务镜像当前以 /bin/sh -c 启动 Java；用 init 转发停止信号并回收子进程，
  # 避免 compose 重建时 PID 变成 zombie 后无法停止旧容器。
  init: true
  restart: unless-stopped
  networks: [cx]
  extra_hosts:
    - "cx-infra:host-gateway"
  environment: *cx-env
  # 冷启动排队（C4 补齐强依赖；补丁 #8 起业务改显式依赖 PG）：
  # PG healthy 才放业务（C2 深化后=业务/流程引擎库真就绪，L022 重连空转窗口同样适用）；
  # Redis=会话/缓存**兼事件总线**（2026-08-10 起，见 config/shared/system-config.yaml），
  # 起在依赖前只会刷错重连。
  # MQ namesrv 已移除：RocketMQ 于 2026-08-10 随事件总线切 Redis 一并退栈。
  depends_on:
    cx-postgres:
      condition: service_healthy
      # 连远端客户库时本机不起 PG（cx-postgres 在 localdb profile 内，见其服务块注释）。
      # required:false = 该服务不在本次启动集合里就跳过、且不自动把它的 profile 拉进来；
      # 在集合里（COMPOSE_PROFILES=localdb）则照旧等它 healthy——两种形态共用这一份编排。
      required: false
    cx-redis:
      condition: service_healthy
  volumes:
    # 与宿主进程共享同一文件存储根（混合调试两侧看到同一批文件）；
    # 跨平台：宿主侧根目录用 JNPF_DATA_DIR 参数化，Win/Linux 在仓库根 .env 里
    # 设 JNPF_DATA_DIR=D:/jnpf-data 或 /data/jnpf 即可，本机 Mac 默认 /Users/Shared
    - ${JNPF_DATA_DIR:-/Users/Shared}/jnpf-resources:/data/jnpf-files/jnpf-resources
    # 应用日志落宿主（2026-08-11）：与 x-cx-env 的 JNPF_LOG_DIR 成对。
    # 此前日志写在容器可写层，容器 recreate 即全丢、且不占可见磁盘配额。
    # 宿主侧长成 logs/<服务名>/log_{error,warn,info,debug,total}.log，直接 tail -f 即可；
    # 滚动归档（按天+满 10MB，保留 7 天）进 <服务名>/{error,info,warn,total}/YYYY-MM-DD/，同样在宿主上。
    # 🔴 冒号左边 = 宿主机目录（改这个），右边 = 容器内目录（由 JNPF_LOG_DIR 固定，别改）。
    # 交付现场若不想写进部署目录，在 .env 设 JNPF_LOG_DIR_HOST=/var/log/jnpf 这类宿主绝对路径。
    # ⚠️ Linux 上该目录由容器内 root 创建，非 root 用户读日志需要 sudo。
    - ${JNPF_LOG_DIR_HOST:-./logs}:/data/jnpf-logs
  logging:
    # 容器 stdout 的 json-file 轮转上限；查看用 docker compose logs -f <svc>
    # （注意这份和上面的文件日志是两套：stdout 走 json-file 存 /var/lib/docker，
    #  容器删除即消失；要留存的日志看挂出来的 logs/ 目录）
    options:
      max-size: "50m"
      max-file: "3"

# 基础设施公共模板（无业务 env、无文件存储卷）
x-infra: &infra
  restart: unless-stopped
  networks: [cx]
  extra_hosts:
    - "cx-infra:host-gateway"
  logging:
    options:
      max-size: "50m"
      max-file: "3"

services:
  # ================= 基础设施（M2 收编；调试端口见 docker-compose.override.yml） =================

  cx-postgres:
    <<: *infra
    container_name: cx-postgres
    # 「栈内 PG」只是两种库形态之一，故收进 profile，默认不启动（2026-08-07）：
    #   开发机 / 测试环境：CUSTOMER_DB_HOST 指向 CVM 上的客户实例，本机这个 PG 是多余的
    #     （起它还会因 external 卷 postgres_pgdata 不存在而直接把整栈拦下）
    #   交付 / 正式：本机 PG 就是唯一库，须在 .env 设 COMPOSE_PROFILES=localdb 才会起
    # 谁该设这个开关有唯一判据：CUSTOMER_DB_HOST=cx-postgres 就必须设，preflight 会核对。
    # 构建与离线打包不受 profile 影响（Makefile images / assemble-offline-package.sh 显式带上），
    # 否则交付包会缺 PG 镜像。
    profiles: ["localdb"]
    # 定义自 docker/postgres/docker-compose.yml 平移（该文件已废弃）；镜像本地已构建，交付走 tar
    image: cx/postgres:18.4
    build: docker/postgres
    platform: linux/amd64
    shm_size: 1g
    # 端口不在基线发布（宿主 psql 走 override 的 127.0.0.1:5433，或 docker exec cx-postgres psql）
    environment:
      TZ: Asia/Shanghai
      POSTGRES_USER: postgres
      # 仅 initdb 时生效；既有 pgdata 卷改密码须 ALTER USER（见 release-checklist §0）
      POSTGRES_PASSWORD: ${JNPF_PG_PASSWORD:?缺 JNPF_PG_PASSWORD，先 cp .env.example .env}
      # PG18 官方镜像 PGDATA 迁至 /var/lib/postgresql/18/docker，volume 挂父目录
      POSTGRES_INITDB_ARGS: "--locale=C.UTF-8 --encoding=UTF8"
    volumes:
      - pgdata:/var/lib/postgresql
    command:
      - postgres
      - -c
      - shared_preload_libraries=pg_stat_statements,auto_explain
      - -c
      - pg_stat_statements.track=all
      - -c
      - auto_explain.log_min_duration=1s
      - -c
      - timezone=Asia/Shanghai
      # 9 个业务服务 Druid 池稳态 ~98 连接，默认 100 在真实页面流量下打满（2026-07-17 回归实测）
      - -c
      - max_connections=200
    healthcheck:
      # C2 深化：pg_isready 只验"接受连接"，空卷/漏灌的 PG 照样 healthy（全新机器静默失败根源）。
      # 追加两库连得上 + 关键表在：坏库不放行，下游（业务/流程引擎 service_healthy）等真就绪。
      # 实现要点：连上目标库本身即证明"库存在且接受连接"（pg_isready 冗余，省掉）；
      # jnpf_xxljob 无关键表，用 1/count 除零技巧并入首个连接；共 2 次 psql——冷启动 13 个 JVM
      # 打满 CPU 时（本地 Rosetta）每个进程 spawn 都慢，多进程版实测超 5s timeout 误判 unhealthy。
      # 只读校验走容器内 socket=trust，与密码无关（L030 不适用）。
      # 补丁 #8：去掉第三库探活——原注册/配置中心的库仍在 PG 里（未删，见
      # tasks/jnpf-platform-patches.md 补丁 #8），但栈内无服务再消费它，健康检查不必再等它。
      test:
        - CMD-SHELL
        - >-
          psql -qU postgres -d jnpf_init -v ON_ERROR_STOP=1
          -c 'SELECT 1 FROM base_user LIMIT 0'
          -c "SELECT 1/count(*) FROM pg_database WHERE datname='jnpf_xxljob'" >/dev/null &&
          psql -qU postgres -d jnpf_flow -v ON_ERROR_STOP=1 -c 'SELECT 1 FROM act_ru_task LIMIT 0' >/dev/null
      interval: 15s
      # 冷启动 CPU 饱和窗口进程 spawn 慢（上）；稳态 <1s，20s 只是兜底
      timeout: 20s
      retries: 5
      # 大卷 crash recovery 可能远超 5×15s，放宽到 120s：start_period 内失败不计 retries、
      # 一旦成功立即 healthy（不拖慢正常冷启动），只延后"真坏"的 unhealthy 判定
      start_period: 120s

  cx-redis:
    <<: *infra
    container_name: cx-redis
    image: cx-redis:8.4.0-alpine
    platform: linux/amd64
    # requirepass 经 .env 注入（config/shared/datasource.yaml 的 spring.redis.password 须同值）。
    #
    # 🔴 2026-08-10 起开持久化（此前是 `--save ""` 不落盘不挂卷）。
    # 原来的理由是「纯缓存/会话，数据可丢，反正 jnpf-oauth 每次启动会清全库」——
    # **那个理由不成立**：JnpfListener 的清库被 `"false".equals(getTestVersion())` 门控，
    # 而 test-version 全仓库未配置 → null → 条件为 false → 清库从不执行。
    # 实测（CVM 客户A）：唯一无 TTL 的 key 是 `idgenerator_Index:`（ID 生成器索引，值已到 174），
    # 丢了会让雪花 workerId 复用 → 主键冲突/跳号。详见 docs/release-checklist.md §2.2。
    # 注意：事件总线走 pub/sub，**不是**开持久化的理由（在途消息落盘也救不回）。
    command:
      - redis-server
      - --protected-mode
      - "yes"
      - --requirepass
      - ${JNPF_REDIS_PASSWORD:?缺 JNPF_REDIS_PASSWORD，先 cp .env.example .env}
      # AOF 为主（everysec：最多丢 1 秒），RDB 兜底便于整卷搬迁
      - --appendonly
      - "yes"
      - --appendfsync
      - everysec
      - --save
      - "900 1"
      # 🔴 交付基线此前**既无 maxmemory 也无 mem_limit**——Redis 可以吃光整台机器。
      # 512mb 是给中小客户的保守起步值；正式环境应按实测定，方法见
      # docs/release-checklist.md §2.2「容量与告警」。
      # 不变式：若给容器加 mem_limit，必须 ≥ 2 × maxmemory + 64M（AOF rewrite 的 COW 峰值）。
      - --maxmemory
      - 512mb
      # 保持 noeviction：会话/缓存以外还有无 TTL 的 idgenerator_Index:，
      # LRU 静默逐出会变成跳号/主键冲突这类诡异故障；打满报错反而立刻暴露问题。
      # 代价是打满 = 写入全失败，所以**必须配 70% 告警**，别等撞墙。
      - --maxmemory-policy
      - noeviction
    volumes:
      - redisdata:/data
    environment:
      # redis-cli 自动读取，healthcheck 免显式 -a（避免密码出现在进程参数）
      REDISCLI_AUTH: ${JNPF_REDIS_PASSWORD}
    healthcheck:
      test: ["CMD", "redis-cli", "ping"]
      interval: 10s
      timeout: 5s
      retries: 5

  # ── RocketMQ（cx-mq-namesrv / cx-mq-store-init / cx-mq-broker）已于 2026-08-10 整体移除 ──
  # 事件总线改用 Redis pub/sub（config/shared/system-config.yaml 的 event.event-publish-type: redis），
  # binder 依赖也已从 jnpf-common-springaop 排除。要回滚见 tasks/jnpf-platform-patches.md 补丁 #10。

  cx-flow-engine:
    <<: *infra
    container_name: cx-flow-engine
    # 独立流程引擎（官方 Flowable 7.0.1 + JNPF 定制层，自有源码工程 jnpf-flow-engine/，详见 docker/flow-engine/README.md）；
    # cx-flowable(30004) 经 FlowDomain=http://cx-flow-engine:31000 服务名直连调用（§0.10 数据面规则）。
    # 构建前置：mvn -f jnpf-flow-engine/pom.xml package + ./docker/flow-engine/prepare-context.sh（jar 不入 git）
    image: cx/flow-engine:${CX_VERSION:-1.0.0}
    build: docker/flow-engine
    platform: linux/amd64
    # Dockerfile ENTRYPOINT 是 sh -c 形式（PID 1 不收割子进程），曾出僵尸进程导致容器停不掉（L031）
    init: true
    # 数据源 = PG 的 jnpf_flow 库（随 pgdata 卷，Flowable 7 同版本 schema）；
    # 连库账号经 env 注入（conf/application-dev.yml 只留占位），A4 起用专用角色 jnpf_flow_app
    environment:
      # URL 用 :- 带默认值：默认容器网直连；
      # 开发机连测试环境共享库时在 .env 覆盖（docs/adr-single-db-topology.md §5.2）
      # 引擎库与业务库共用同一对坐标变量 → 物理上不可能半切（adr-multi-customer-db-isolation §4）。
      # JNPF_FLOW_DB_URL 保留为逃生口（整串覆盖），日常不要用——用它就重新引入了半切风险。
      FLOW_DB_URL: ${JNPF_FLOW_DB_URL:-jdbc:postgresql://${CUSTOMER_DB_HOST:-cx-postgres}:${CUSTOMER_DB_PORT:-5432}/jnpf_flow}
      FLOW_DB_USER: ${JNPF_FLOW_DB_USER:-postgres}
      FLOW_DB_PASSWORD: ${JNPF_FLOW_DB_PASSWORD:?缺 JNPF_FLOW_DB_PASSWORD，先 cp .env.example .env}
    depends_on:
      cx-postgres:
        condition: service_healthy
        # 同 x-cx 的说明：栈内 PG 在 localdb profile 内，不在启动集合时跳过而非报错
        required: false
    healthcheck:
      # 无 actuator，用 springdoc 文档端点探活
      test: ["CMD-SHELL", "curl -fsS -o /dev/null http://127.0.0.1:31000/v3/api-docs"]
      interval: 15s
      timeout: 5s
      start_period: 90s
      retries: 5

  cx-onlyoffice:
    <<: *infra
    container_name: cx-onlyoffice
    # OnlyOffice Document Server 社区版：Office 文档在线预览/编辑，由 cx-biz-common 的
    # onlyoffice 能力模块驱动（方案见 tasks/onlyoffice-integration-plan.md）。
    # 用 *infra 而非 *cx：它不是 JNPF JVM，不需要 JNPF_* 环境变量与 PG/Redis/MQ 依赖。
    #
    # ⚠️ 版本必须固定：9.4.0.1 是 Docker Hub 当前 latest（Hub manifest list digest
    #   sha256:3ab6ebc7c605e5a32b7ae3ff19daed4925090245acc8100ce2230bd766c88212）；
    #   tag 9.4.0 / 9.4 是更早的另一个 digest，不要混用。
    #
    # 🔴 2026-08-19：由 Docker Hub 长名改为短名 cx-onlyoffice，与 cx-redis 同机制——
    #   国内网络 `docker.io/onlyoffice/documentserver` 拉取超时（registry-1.docker.io:443
    #   连不上，Windows 测试环境实测）。短名由 `make pull-infra` 从 SWR 长名
    #   $SWR/onlyoffice/documentserver:9.4.0.1 retag 而来，故裸 `docker compose pull`
    #   同样拉不到它（详见本文件顶部 §短名约定与 docs/docker-compose-guide.md §11.1）。
    #   SWR 侧是已解开的 amd64 单架构 manifest（digest
    #   sha256:66e06b404e11d532832501acf5a78bc759940c58859a80676330f71aedb1ef99，
    #   config sha256:4934c364adccc2898d0998951fb09d455496454de417cce2a74b7b1e808daab0），
    #   与上面 Hub 的 manifest-list digest 天然不同，**不能据此判断内容不一致**。
    #   ✅ 2026-08-19 已实证两源内容同一（digest 比不了：本机连不通 Hub，且本地 Hub tag
    #   在 containerd image store 下只剩 index 引用，inspect 出来 Architecture 空、
    #   RootFS.Layers=0，无从取层）。改在容器内比，两侧完全一致：
    #     · dpkg 包版本   onlyoffice-documentserver 9.4.0-129（amd64）
    #     · 核心二进制    server/DocService/docservice
    #                     sha256:556df4aab7b1a87123046a4459baee34e60f57deaf7bcd189bccd6f271bd8fcb
    #   并且 SWR 镜像单起容器 20s 内跑通官方 /healthcheck。
    image: cx-onlyoffice:9.4.0.1
    platform: linux/amd64
    environment:
      # JWT 是 DS 与后端之间的唯一信任凭据：后端签发编辑器 config、DS 签发保存回调，
      # 两侧共用同一 secret。与 config/shared/jnpf-biz-common.yaml 的
      # onlyoffice.jwt-secret 同源（都读 .env 的 ONLYOFFICE_JWT_SECRET）——
      # 两边不一致的表现是编辑器一直转圈或回调静默失败，且日志不明显。
      JWT_ENABLED: "true"
      JWT_SECRET: ${ONLYOFFICE_JWT_SECRET:?缺 ONLYOFFICE_JWT_SECRET，先 cp .env.example .env}
    volumes:
      # DS 内置 PostgreSQL 存文档缓存与编辑状态，不挂卷则重启丢失（表现为编辑中的
      # 文档回到上一个保存点）。字体不挂载——镜像自带 22 个中文字体已够用（实测）。
      - onlyoffice-data:/var/www/onlyoffice/Data
      - onlyoffice-log:/var/log/onlyoffice
      - onlyoffice-db:/var/lib/postgresql
    healthcheck:
      # DS 官方探活端点，就绪时返回字面量 true
      test: ["CMD-SHELL", "curl -fsS http://127.0.0.1/healthcheck | grep -q true"]
      interval: 15s
      timeout: 10s
      retries: 5
      # 首次启动要初始化内置 PG + 生成字体索引，Rosetta 上偏慢
      start_period: 90s

  # ================= JNPF 业务服务（M1） =================
  cx-gateway:
    <<: *cx
    container_name: cx-gateway
    image: cx/gateway:${CX_VERSION:-1.0.0}
    build: { context: ., dockerfile: dockerfile/gateway/Dockerfile, args: { BASE_IMAGE: "${BASE_IMAGE:-bellsoft/liberica-openjre-rocky:21}" } }
    ports: ["30000:30000"]
    # 说明：2026-08-11 一度在这里加过 -Dlogging.level.jnpf.util.Ip2RegionUtil=OFF 来压
    # 「ip2region xdb 找不到」的两条 ERROR。补丁 #15 从根上解决后（gateway 自带同包替身类
    # jnpf/util/Ip2RegionUtil.java，见该文件注释）已撤掉——压噪配置留着会掩盖真问题，
    # 也会让人误以为那两条错误还在。本服务现在完全走 x-cx-env 的公共环境变量。
    healthcheck: &hc-30000
      test: ["CMD-SHELL", "exec 3<>/dev/tcp/127.0.0.1/30000"]
      interval: 30s
      # 冷启动 CPU 饱和下业务真实启动 4-6 分钟，180s 会经历"瞬时 unhealthy 再自愈"的误导态
      # （三轮冷启动实测）；start_period 内失败不计 retries、成功立即 healthy，放宽无副作用（L034）
      start_period: 300s
      retries: 3

  # ================= 平台聚合服务（2026-08-11）=================
  # system / permission / oauth / visualdev / visualdata / message / file / app / flowable
  # 九个模块合一个 JVM，取代下面九个已注释的 cx-* 容器。
  # 实测：RSS 约 1.07GB（对比九个独立容器约 6.7GB），fat jar 328MB（对比九个各 198MB）。
  # 服务名不变——config/shared/discovery.yaml 里九个 jnpf-* 名字全部别名到 cx-platform:30002，
  # 网关 router.yaml 与 60 个 @FeignClient 一行未改。
  cx-platform:
    <<: *cx
    container_name: cx-platform
    image: cx/platform:${CX_VERSION:-1.0.0}
    build: { context: ., dockerfile: dockerfile/platform/Dockerfile, args: { BASE_IMAGE: "${BASE_IMAGE:-bellsoft/liberica-openjre-rocky:21}" } }
    environment:
      <<: *cx-env
      # 九个模块的类元数据同处一个 JVM，堆比单模块服务大一档（模板默认 -Xms256m -Xmx768m）。
      # 实测堆 used 约 361MB，1536m 留足余量；即便如此总占用仍远低于九容器形态。
      # ⚠️ 本行整体覆盖 x-cx-env 的同名值，编码参数必须跟着抄一份，否则本服务中文日志变问号。
      JAVA_TOOL_OPTIONS: -Xms512m -Xmx1536m -Dstdout.encoding=UTF-8 -Dstderr.encoding=UTF-8
      # 原 jnpf-system 是 Dubbo LogProvider 唯一 provider（补丁 #8），聚合后本服务接管。
      # 不设此项 → 每个请求的 RequestLogAspect 都调用失败。
      DUBBO_PROTOCOL_PORT: "20880"
    healthcheck:
      <<: *hc-30000
      test: ["CMD-SHELL", "exec 3<>/dev/tcp/127.0.0.1/30002"]

  # ── cx-oauth 已并入 cx-platform（2026-08-11），整段注释保留以便回滚 ──
  # cx-oauth:
  #   <<: *cx
  #   container_name: cx-oauth
  #   image: cx/oauth:${CX_VERSION:-1.0.0}
  #   build: { context: ., dockerfile: dockerfile/oauth/Dockerfile, args: { BASE_IMAGE: "${BASE_IMAGE:-bellsoft/liberica-openjre-rocky:21}" } }
  #   healthcheck:
  #     <<: *hc-30000
  #     test: ["CMD-SHELL", "exec 3<>/dev/tcp/127.0.0.1/30001"]


  # ── cx-system 已并入 cx-platform（2026-08-11），整段注释保留以便回滚 ──
  # cx-system:
  #   <<: *cx
  #   container_name: cx-system
  #   image: cx/system:${CX_VERSION:-1.0.0}
  #   build: { context: ., dockerfile: dockerfile/system/Dockerfile, args: { BASE_IMAGE: "${BASE_IMAGE:-bellsoft/liberica-openjre-rocky:21}" } }
  #   environment:
  #     <<: *cx-env
  #     # 补丁 #8：jnpf-system 是 Dubbo LogProvider 唯一 provider，固定协议端口供直连
  #     DUBBO_PROTOCOL_PORT: "20880"
  #   healthcheck:
  #     <<: *hc-30000
  #     test: ["CMD-SHELL", "exec 3<>/dev/tcp/127.0.0.1/30002"]


  # ── cx-visualdev 已并入 cx-platform（2026-08-11），整段注释保留以便回滚 ──
  # cx-visualdev:
  #   <<: *cx
  #   container_name: cx-visualdev
  #   image: cx/visualdev:${CX_VERSION:-1.0.0}
  #   build: { context: ., dockerfile: dockerfile/visualdev/Dockerfile, args: { BASE_IMAGE: "${BASE_IMAGE:-bellsoft/liberica-openjre-rocky:21}" } }
  #   healthcheck:
  #     <<: *hc-30000
  #     test: ["CMD-SHELL", "exec 3<>/dev/tcp/127.0.0.1/30003"]


  # ── cx-flowable 已并入 cx-platform（2026-08-11），整段注释保留以便回滚 ──
  # cx-flowable:
  #   <<: *cx
  #   container_name: cx-flowable
  #   image: cx/flowable:${CX_VERSION:-1.0.0}
  #   build: { context: ., dockerfile: dockerfile/flowable/Dockerfile, args: { BASE_IMAGE: "${BASE_IMAGE:-bellsoft/liberica-openjre-rocky:21}" } }
  #   healthcheck:
  #     <<: *hc-30000
  #     test: ["CMD-SHELL", "exec 3<>/dev/tcp/127.0.0.1/30004"]


  # ── cx-file 已并入 cx-platform（2026-08-11），整段注释保留以便回滚 ──
  # cx-file:
  #   <<: *cx
  #   container_name: cx-file
  #   image: cx/file:${CX_VERSION:-1.0.0}
  #   build: { context: ., dockerfile: dockerfile/file/Dockerfile, args: { BASE_IMAGE: "${BASE_IMAGE:-bellsoft/liberica-openjre-rocky:21}" } }
  #   healthcheck:
  #     <<: *hc-30000
  #     test: ["CMD-SHELL", "exec 3<>/dev/tcp/127.0.0.1/30005"]


  # ── cx-message 已并入 cx-platform（2026-08-11），整段注释保留以便回滚 ──
  # cx-message:
  #   <<: *cx
  #   container_name: cx-message
  #   image: cx/message:${CX_VERSION:-1.0.0}
  #   build: { context: ., dockerfile: dockerfile/message/Dockerfile, args: { BASE_IMAGE: "${BASE_IMAGE:-bellsoft/liberica-openjre-rocky:21}" } }
  #   healthcheck:
  #     <<: *hc-30000
  #     test: ["CMD-SHELL", "exec 3<>/dev/tcp/127.0.0.1/30008"]


  # ── cx-permission 已并入 cx-platform（2026-08-11），整段注释保留以便回滚 ──
  # cx-permission:
  #   <<: *cx
  #   container_name: cx-permission
  #   image: cx/permission:${CX_VERSION:-1.0.0}
  #   build: { context: ., dockerfile: dockerfile/permission/Dockerfile, args: { BASE_IMAGE: "${BASE_IMAGE:-bellsoft/liberica-openjre-rocky:21}" } }
  #   healthcheck:
  #     <<: *hc-30000
  #     test: ["CMD-SHELL", "exec 3<>/dev/tcp/127.0.0.1/30010"]


  cx-lims:
    <<: *cx
    container_name: cx-lims
    image: cx/lims:${CX_VERSION:-1.0.0}
    build: { context: ., dockerfile: dockerfile/lims/Dockerfile, args: { BASE_IMAGE: "${BASE_IMAGE:-bellsoft/liberica-openjre-rocky:21}" } }
    environment:
      <<: *cx-env
      # Spring relaxed binding → audit.spool-dir（AuditSdkAutoConfiguration @Value("${audit.spool-dir:./audit-spool}")）。
      # cx-lims 是当前**唯一**的 audit-sdk 宿主，也就是唯一需要 spool 兜底的服务。
      AUDIT_SPOOL_DIR: /jnpf/audit-spool
      # M2 Task A1：audit-sdk 已接入 lims。relaxed binding 自动映射到 audit.enabled（总开关，
      # AuditSdkAutoConfiguration @ConditionalOnProperty），无需在 application.yml 重复声明占位符。
      # 双态断言见 tasks/audit-m2-startup-check.sh。
      AUDIT_ENABLED: ${AUDIT_ENABLED:-true}
      # 2026-08-11：AUDIT_LAYER1_ENABLED / AUDIT_LAYER1_PER_TABLE_MASKED_COLUMNS 随层 1 整套移除。
      # 层 1 自交付起一直默认 false，audit_events 表内 source_layer=1 零行，属未启用即负债。
    volumes:
      # ⚠️ 服务级 volumes 会**整体覆盖** x-cx 锚点的那份，不是追加——所以 jnpf-resources
      # 与日志挂载都得在这里再写一遍，漏一行该服务就静默退回容器内路径（2026-08-11 踩过）。
      - ${JNPF_DATA_DIR:-/Users/Shared}/jnpf-resources:/data/jnpf-files/jnpf-resources
      - ${JNPF_LOG_DIR_HOST:-./logs}:/data/jnpf-logs
      - audit-spool-lims:/jnpf/audit-spool
    healthcheck:
      <<: *hc-30000
      test: ["CMD-SHELL", "exec 3<>/dev/tcp/127.0.0.1/30019"]

  # eln 业务模块（ADR 售卖单元制）：profile 隔离，默认 make up 不起（本地 VM 内存账，L024）。
  # 起用：docker compose --profile eln up -d
  cx-eln:
    <<: *cx
    container_name: cx-eln
    image: cx/eln:${CX_VERSION:-1.0.0}
    profiles: ["eln"]
    build: { context: ., dockerfile: dockerfile/eln/Dockerfile, args: { BASE_IMAGE: "${BASE_IMAGE:-bellsoft/liberica-openjre-rocky:21}" } }
    healthcheck:
      <<: *hc-30000
      test: ["CMD-SHELL", "exec 3<>/dev/tcp/127.0.0.1/30013"]

  # ══ cx-audit（30014）已于 2026-08-11 退役 ══
  # 审计整体搬入 jnpf-biz-common（见下），JVM/容器/镜像各减一个。
  # 服务名 jnpf-audit 在 config/shared/discovery.yaml 里保留为**别名**指向 cx-biz-common:30015，
  # 故 lims 的 Feign 投递与 /api/audit/** 路由一行未改。
  # 原先这里的 AUDIT_SPOOL_DIR + audit-spool-audit 卷是**从未生效的配置**：spool 属 audit-sdk，
  # 而 audit 服务端的依赖链（server→controller→biz→api）从不含 sdk——退役前实测该卷内始终为空。

  # 公共业务能力聚合服务（jnpf-biz-common）：默认启动（无 profiles，区别于 cx-eln）。
  # 一个 JVM 承载多个能力模块（onlyoffice、audit…），准入纪律见 specs/2026-08-07-biz-common-design.md §3
  cx-biz-common:
    <<: *cx
    container_name: cx-biz-common
    image: cx/biz-common:${CX_VERSION:-1.0.0}
    build: { context: ., dockerfile: dockerfile/biz-common/Dockerfile, args: { BASE_IMAGE: "${BASE_IMAGE:-bellsoft/liberica-openjre-rocky:21}" } }
    # 只有本服务消费这个密钥，故不进公共 *cx-env 锚点，单独覆盖（保留锚点其余变量）。
    # 🔴 漏了它会静默失败而不是报错：config/shared/jnpf-biz-common.yaml 里写的是
    # ${ONLYOFFICE_JWT_SECRET}，而 Spring Boot 的 Binder 对解析不了的占位符是原样放行，
    # 后端会拿字面量 "${ONLYOFFICE_JWT_SECRET}" 当密钥签名，DS 验签必然失败，
    # 表现为编辑器里「文档安全令牌的格式不正确」——2026-08-08 实踩。
    environment:
      <<: *cx-env
      ONLYOFFICE_JWT_SECRET: ${ONLYOFFICE_JWT_SECRET:?缺 ONLYOFFICE_JWT_SECRET，先 cp .env.example .env}
    healthcheck:
      <<: *hc-30000
      test: ["CMD-SHELL", "exec 3<>/dev/tcp/127.0.0.1/30015"]

  cx-dms:
    <<: *cx
    container_name: cx-dms
    image: cx/dms:${CX_VERSION:-1.0.0}
    build: { context: ., dockerfile: dockerfile/dms/Dockerfile, args: { BASE_IMAGE: "${BASE_IMAGE:-bellsoft/liberica-openjre-rocky:21}" } }
    healthcheck:
      <<: *hc-30000
      test: ["CMD-SHELL", "exec 3<>/dev/tcp/127.0.0.1/30016"]

  # ── cx-visualdata 已并入 cx-platform（2026-08-11），整段注释保留以便回滚 ──
  # cx-visualdata:
  #   <<: *cx
  #   container_name: cx-visualdata
  #   image: cx/visualdata:${CX_VERSION:-1.0.0}
  #   build: { context: ., dockerfile: dockerfile/visualdata/Dockerfile, args: { BASE_IMAGE: "${BASE_IMAGE:-bellsoft/liberica-openjre-rocky:21}" } }
  #   healthcheck:
  #     <<: *hc-30000
  #     test: ["CMD-SHELL", "exec 3<>/dev/tcp/127.0.0.1/30011"]

  # ================= 前端（Backlog F）=================
  # nginx 静态托管 dist + /api、/websocket 反代 gateway；非 JVM 用 *infra 模板（x-cx 的
  # JAVA_TOOL_OPTIONS/文件卷/depends_on 均不适用）。不加 depends_on：nginx.conf 用变量
  # proxy_pass + resolver 惰性解析，gateway 未起时 nginx 照常启动、重建换 IP 自动重解析。
  # dist 由 make web-dist 快照进 docker/frontend/dist/（独立 build context——根 .dockerignore
  # 是 deny-all 白名单，context: . 拿不到前端文件）。
  cx-web:
    <<: *infra
    container_name: cx-web
    image: cx/web:${CX_VERSION:-1.0.0}
    build:
      context: docker/frontend
      args:
        NGINX_BASE_IMAGE: "${NGINX_BASE_IMAGE:-nginx:1.27-alpine}"
    ports:
      - "80:80"
      # - "443:443"    # TLS 现场启用（证书 + nginx.conf 443 块，三步见交付包 INSTALL.md §5）
    volumes:
      # 挂载为准（现场免构建改反代/开 TLS），镜像内 COPY 的同份 conf 作自包含兜底
      - ./docker/frontend/nginx.conf:/etc/nginx/conf.d/default.conf:ro
      # - ./docker/frontend/certs:/etc/nginx/certs:ro    # TLS 证书挂载点
    healthcheck:
      # alpine 无 bash 用不了 &hc-30000 的 /dev/tcp；busybox wget 探静态入口即可
      test: ["CMD", "wget", "-qO", "/dev/null", "http://127.0.0.1/"]
      interval: 30s
      timeout: 5s
      retries: 3
      start_period: 10s

  # ---- 以下 2 个本地暂未使用，按需 --profile extra 启动 ----

  cx-scheduletask:
    <<: *cx
    profiles: [extra]
    container_name: cx-scheduletask
    image: cx/scheduletask:${CX_VERSION:-1.0.0}
    build: { context: ., dockerfile: dockerfile/scheduletask/Dockerfile, args: { BASE_IMAGE: "${BASE_IMAGE:-bellsoft/liberica-openjre-rocky:21}" } }
    healthcheck:
      <<: *hc-30000
      test: ["CMD-SHELL", "exec 3<>/dev/tcp/127.0.0.1/30009"]

  # ── cx-app 已并入 cx-platform（2026-08-11），整段注释保留以便回滚 ──
  # cx-app:
  #   <<: *cx
  #   profiles: [extra]
  #   container_name: cx-app
  #   image: cx/app:${CX_VERSION:-1.0.0}
  #   build: { context: ., dockerfile: dockerfile/app/Dockerfile, args: { BASE_IMAGE: "${BASE_IMAGE:-bellsoft/liberica-openjre-rocky:21}" } }
  #   healthcheck:
  #     <<: *hc-30000
  #     test: ["CMD-SHELL", "exec 3<>/dev/tcp/127.0.0.1/30012"]


networks:
  cx:
    name: cx

volumes:
  # Redis 持久化卷（AOF+RDB）。普通内部卷：`down -v` 会删，
  # 但 idgenerator_Index: 丢失只影响雪花 workerId 分配，重建即可，不是跨机迁移数据。
  redisdata:
  # 复用 PG 迁移期创建的既有卷（原 docker/postgres 项目）；external=compose 永不删除（含 down -v），
  # 全新机器需先 docker volume create postgres_pgdata 再灌数据（docker/postgres/migration/）
  pgdata:
    name: postgres_pgdata
    external: true
  # audit-sdk spool 兜底目录（两级降级的最后一级）：per-service 独立卷（Codex 批次二 #2：
  # 多实例共享 spool 卷会有孤儿租约风险，per-service 隔离规避）。
  # 2026-08-11：audit-spool-audit 随 cx-audit 退役一并删除（它从未被写入过——spool 属 sdk，
  # 而 audit 服务端不含 sdk，退役前实测卷内为空）。当前只有 SDK 宿主 cx-lims 需要。
  audit-spool-lims:
  # OnlyOffice DS 状态：Data=文档缓存与转换产物，db=内置 PG（编辑会话状态），log=日志。
  # 均为可重建数据（丢失只影响编辑中的未保存内容，已保存的文档在 jnpf-file 存储里），
  # 故用普通内部卷，不设 external
  onlyoffice-data:
  onlyoffice-log:
  onlyoffice-db: