动机（Why）

PR #5 诊断块在远端输出了关键真相——截图实证：

PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
DOCKER_HOST=<unset>
which docker: <not found>
ls /usr/bin/docker*: No such file or directory
env | grep -i docker:
  CNB_DOCKER_MODEL_REGISTRY=docker-model.cnb.cool
  CNB_PIPELINE_DOCKER_IMAGE=cnbcool/default-build-env  ← ★ 关键
  CNB_DOCKER_REGISTRY=docker.cnb.cool

★ 关键信号：CNB_PIPELINE_DOCKER_IMAGE=cnbcool/default-build-env

这证明 PR #4 引入的 docker: { image: maven:... } 语法让 CNB 回退到了默认镜像 cnbcool/default-build-env（该镜像无 maven 无 docker），而不是 maven image。这解释了为什么 coverage 0.19s fail——mvn 都没有。

对比证据：biz-backend-compile 远端 64.5s 真跑了 mvn compile——它用的是 image: maven:* 旧语法，说明旧语法才正确生效。

变更清单（What）

3 处修正

改动 1：.cnb.yml（push + MR 4 处回滚）

  - name: biz-backend-coverage
-   services:
-     - docker
-   docker:
-     image: maven:3.9-eclipse-temurin-17
+   image: maven:3.9-eclipse-temurin-17
+   services:
+     - docker
    script: ...

回到 PR #3 原语法但保留 services: [docker] 声明——假设它注入 daemon sidecar 但不注入 CLI（由脚本自装）。

改动 2：脚本加 install_docker_cli 函数

在 functional.sh + coverage.sh 都加：

• Docker CLI 不存在时从 download.docker.com/linux/static/ 下载官方静态二进制（docker-26.1.0.tgz ~30MB）
• 解压后放到 /usr/local/bin/docker + chmod +x
• 不依赖 apt-get（避免 sudo + 依赖链）
• 下载失败则降级跳过

改动 3：同时探测 DOCKER_HOST

if [ -z "${DOCKER_HOST:-}" ]; then
    if [ -S /var/run/docker.sock ]; then         # 标准 socket
        :
    elif nc -z docker 2375 2>/dev/null; then     # CNB sidecar 常见约定
        export DOCKER_HOST="tcp://docker:2375"
    elif nc -z localhost 2375 2>/dev/null; then  # localhost 兜底
        export DOCKER_HOST="tcp://localhost:2375"
    fi
fi

验证证据（How verified）

本地 15/15 CI stages 全绿 + 0 lint + yml 对称 81/81 行

Docker 可用场景（本地有 OrbStack）：

==> P1 后端覆盖率棘轮 (JaCoCo, unit + functional)
    PG 启动路径: compose-v2
    行覆盖: 79%  保底: 78%
    分支覆盖: 71%  保底: 70%
[OK] 后端覆盖率棘轮达标

本地不能验证的（需远端 CI 真跑）：

• download.docker.com 在 CNB 网络的可达性
• CNB sidecar 的实际 DOCKER_HOST 端点（是 docker:2375 还是别的）
• 装上 CLI 后 services: [docker] 提供的 daemon 是否真的可连

影响面（Impact）

本次的假设链（全部依赖远端验证）

1. services: [docker] 确实启动了 dind sidecar（即使 CLI 不注入）
2. sidecar 通常在 docker:2375 或 localhost:2375 暴露 API
3. 装上 CLI + 探测 DOCKER_HOST 即可连通

合入后远端 CI 的可能结果（3 种分支）

回归 PR #3 思路的合理性

PR #3 的 .cnb.yml 语法实际是正确的（image: maven + services:）；当时失败是因为脚本在 command -v docker 就 exit 0 + WARNING 静默跳过。本 PR 保留 services 声明 + 脚本安装 CLI——这是"PR #3 语法 + PR #5 策略"的真实组合。

本轮的 meta 意义

• 回滚 PR #4 的语法变更——坦诚承认先前推断错误
• 诊断数据→行动的经典闭环：PR #5 收集、PR #6 基于实证修复
• 三连 PR（#4/#5/#6）展示"错误修复 → 观察 → 正确修复"的真实工程节奏，比"一次到位"有教育价值

候选待办

• T-Q2-h：若 PR #6 远端仍失败，根据新诊断走第 2/3 种分支
• T-Q2-j：新候选 LESSONS §二 B14——"未经实证推断平台行为就直接修改配置"（由 PR #4 的错误证明）
• T-Q2-k：新候选 retrospective-sop §5.1 加第六档——"CI 平台行为变化触发的诊断采集"（由轮次 3.1/3.2 的经验证明）

Refs

• 父事件：PR #5 远端诊断块输出 + CNB_PIPELINE_DOCKER_IMAGE=default-build-env 发现
• 关联：
  • CHECKPOINT §四 轮次 3.2 待闭环的 T-Q2-h
  • meta-principles §原则 2（诊断驱动的逐步修复）
  • LESSONS §二 B12 推论 + B14 候选（未经实证就修改配置）