CodeBuddy

Hy3 preview

## 26年蒸蚌特权准备中...

26年蒸蚌特权准备中，顶级组织自由创建暂时关闭，节后放开，好好过节

电商 mini 演示项目 + .codebuddy 框架（rules/skills/feedback）— 沉淀了 Spring Boot 3 + Vue 3 全栈开发的规则与经验教训

anta-workshopdemo

fix(deps): Testcontainers 1.19.7 → 1.20.6 修复 CAP_NET_RAW + FB-02 二次沉淀 (#6)

CI 失败根因：较新 Docker daemon 返回带 CAP_ 前缀的枚举值，1.19.x 内嵌的 docker-java 不识别。

修复：升级 Testcontainers 到 1.20.6。
顺带：FB-02 从"macOS 独有"升级为通用协议漂移问题；新增"Testcontainers 当常规依赖升级"硬约束 + LESSONS 第 11 条。

本地 15/15 单测 PASS。功能测试的 Testcontainers 启动验证待 CI 二次确认。

fix(deps): Testcontainers 1.20.6 → 1.21.3（双重保险）

docs(rules): LESSONS §四 修订——覆盖首次演练错误描述 + A/B 分层 + 反模式 A7

关闭 migration-dryrun-report-2026-Q2 的 5 条"进规则修订"摩擦点
（#1 / #3 / #4 严重 / #6 / #7 严重）。

LESSONS §四 大段重写：

1. 演练证据段重写：从"首次演练完成"改为"首次 + 第二次演练"双证据，
   硬约束"再次修订必须重做演练回写独立报告"

2. Step 2（摩擦点 #1）：从"二选一无默认"改为"默认 (a) 保留"
   只在不执行 Step 6 时选 (b) 批量改写

3. Step 4 大段重写（摩擦点 #4 严重——覆盖首次演练错误）：
   - 明确"A 层元 CI 9 脚本栈无关不改"（附实际约束对象表）
   - 首次演练曾建议的"改写 check-py-compile/check-unittest/check-coverage
     为目标语言工具"——**此描述经第二次演练证伪**，以 ⚠️ 标注废除
   - 新增"B 层业务 CI 新建模板 + 空项目幂等跳过硬约束"（摩擦点 #3）
   - CNB 同构 → 拷 .cnb.yml + 改项目名（摩擦点 #6）+ push/MR 两段对称
   - GHA / GitLab CI → 外壳重写但保持"YAML 只调度、逻辑在 .sh"的分层

4. Step 6 大段重写（摩擦点 #7 严重）：
   - A 层阈值完全继承源（字节级复制品的度量必然相同；这是真正的 §原则 3）
   - B 层阈值归零起点（首次业务代码后按 §七 测量 + 上调）
   - "禁止沿用"的真正语义是"禁止错位继承"（源 88% 沿用到新项目 0 代码）

5. 迁移完成断言：4 条扩展，双事实源从"6 处"扩至"8+ 处"
   明确列出 PR #37 / #38 新增的 2 处（scaffold 栈规则 / L6+ 前缀白名单）

LESSONS §二 新增反模式 A7：
演练报告的"修订建议"被视为终极真理——写进规则后下次演练才发现修订
本身是错的。典型案例：首次演练提"Step 4 改 check-py-compile 为 go build"
被采纳进 LESSONS §四，第二次演练纠正。
正模式：修订必须带"待下次演练验证"标记，等通过后才稳定；禁止"内部推理
直接改规则"——所有规则修订必须有演练证据。

LESSONS §二 A1 微调：
.archived/<stack>.md → rules/<stack>.md（PR #40 已修正路径）

.cnb.yml 顶部注释（摩擦点 #6）：
项目名硬编码改为 {{project-name}} 占位符 + 迁移时改项目名注记

本 PR 与下一 commit 的 CHECKPOINT 轮次 14 档案配对，完整关闭
Q2 演练报告的 5 条规则修订归类。

派生自 meta-principles.md §原则 2（主动式验证的自纠正循环）+
§原则 3（棘轮语义精确化）+ §原则 4（抽象化占位符）。

本地 9/9 CI stages 全绿（#16 抽象化 35→39 命中，L6+ 前缀白名单 +
L3 语义关键词豁免联合生效，0 residual）。

Refs: governance/migration-dryrun-report-2026-Q2.md 摩擦点 #1/#3/#4/#6/#7


PR-E：方向 F1 四 PR 经验回写——LESSONS B13/B14 + 棘轮口径区分 + CNB 坑点实证清单（轮次 14-e）

docs(share): workshop-share.md 新增 M9·CI 平台坑点实证清单（第 9 种治理模式）

关闭 CHECKPOINT §五 T-Q3-03——把目标项目方向 F1 四 PR 演化换来的 CNB
坑点，从 skills/cicd-pipeline/SKILL.md 的"使用指引层"升级到
workshop-share.md 的"治理模式层"——让其他团队 Leader 也能看懂
"为什么要把平台坑点收编为一等资产"。

改动：

1. §一 TL;DR 表扩展 8 行 → 9 行
   - PR 数 "15 PR" → "23 PR"（反映 Q2 + Q3 累计）
   - 新增 M9 行：CI 平台坑点实证清单
   - 反直觉认识新增一条：M9 的生存价值——4 个 fail PR 换来的实证
     不能只消化在源代码里

2. §四 标题 "八种模式" → "九种模式" + M9 完整子节

   M9 · CI 平台坑点实证清单（Platform Pitfalls as First-Class Assets）

   起因：4 PR 演化实证表（附目标项目 #3~#7 演化）
     #3 假绿 → #4 推断修 → #5 诊断 → #6 装 CLI → #7 根治

   4 条核心发现（官方文档未说明）：
   - services:[docker] 强制忽略 image: 字段
   - services:[docker] 不注入 CLI 也不设 DOCKER_HOST
   - Stage 耗时是识别静默跳过的关键信号
   - default-build-env 实际内容：Java/Maven ✅ / Docker CLI ❌

   把坑点本身作为资产——对比表：
     普通经验笔记 vs M9 平台坑点实证清单
     - 写在私有 doc → 写在 skills/ 被 scaffold 引用
     - 下一个项目重新踩 → 下一个项目直接跳过
     - "我记得 CNB 有个问题" → "坑点 1: 证据 env 输出"

   4 条关键约束（派生自 M2 + M4）：
   - 必须配实证锚点（env 输出/PR SN/stage 耗时）
   - 必须与 CHECKPOINT 某轮次关联
   - 推荐随平台扩充独立子节（GitHub Actions/GitLab CI/...）
   - 推荐坑点失效时标注"历史坑点"不删除

   3 条反模式：
   - 我们换脚本绕过了但没记录 bug
   - 那是平台方的问题不是我们的
   - 写在 commit message 里（git log 不是知识库）

   与 M8 的关系：
     对已发生的坑要收编（M9），对未验证的假说才克制（M8）
     两者合成"对不同证据强度采取不同机制化力度"

M9 的分层定位：
  使用指引层（PR-E 已完成）：skills/cicd-pipeline/SKILL.md
    受众：本项目 scaffold 使用者
    内容：具体坑点条目 + 决策树

  治理模式层（本 PR 完成）：docs/workshop-share.md §四 M9
    受众：其他团队 Leader
    内容：把"收编平台坑点作为资产"本身作为治理模式

  前者讲"怎么用"，后者讲"为什么要这样用"——同一知识在不同层
  有不同价值，关键是各有受众。

本地 9/9 CI stages 全绿 + 0 lint + #16 仍 45 legit / 0 residual。

规则自举第 6 次实证：docs/ 天然在 scope（rules + governance）
之外放行——不是"守门员识别能力"而是"scope 划分本身的健康度"。
健康 scope 让输出向文档（docs/）和约束向文档（rules/governance）
天然隔离。累计 6 次 = 3 阻塞 + 3 放行（连续 3 次合规放行）。

派生自 meta-principles §原则 4（抽象化——把具体坑点升级为模式
是抽象层级的跃迁）+ §原则 5（契约——M9 作为"模式"本身是
跨团队的契约，约定"什么是好的坑点记录方式"）+ LESSONS §二
信号欺骗家族（B13 的正面消化：把 4 fail PR 的认知沉淀）。

Refs: 目标项目 anta-newproject-demo PR #4~#7 /
      源仓库 PR-E（skills 层沉淀）/
      CHECKPOINT §四 轮次 15-b / T-Q3-03 闭环


PR-G：workshop-share.md 新增 M9·CI 平台坑点实证清单——第 9 种治理模式外显（轮次 15-b）

## CI 失败根因

CI 流水线运行 OpenApiExportTest / Req1OrderCreateTest 时失败：

```
Can not deserialize value of type Capability from String "CAP_NET_RAW":
  value not one of declared Enum instance names:
  [ALL, SYS_BOOT, ..., NET_RAW, ...]
```

较新的 Docker daemon（CNB 的 DinD）在 `HostConfig.CapDrop` 返回带 `CAP_` 前缀的枚举值，而 Testcontainers 1.19.7 内嵌的 `docker-java` 的 `Capability` 枚举只识别不带前缀的名称。结果：容器启动成功但 inspect 调用解析崩溃，判定启动失败。

## 修复

`testcontainers.version: 1.19.7 → 1.20.6`（同大版本末版最稳健，可识别 `CAP_*` 前缀）。

## 顺带沉淀到框架

这是 **FB-02 的二次验证**——第一次在 macOS + OrbStack 暴露为 API 版本号协商失败，这次在 CI 的 DinD 暴露为枚举反序列化失败。**同一根因族**（docker-java 与 daemon 的协议漂移），之前误以为是 macOS 独有问题，事实是**任何足够新的 Docker 环境都会出现**。

沉淀动作：

| 位置 | 改动 |
|------|------|
| `.archived/feedback/FB-02-*.md` | 新增"二次症状"章节 + 抽象为通用启示 |
| `cicd-pipeline/SKILL.md §硬约束` | 新增"把 Testcontainers 当常规依赖定期升级"硬约束 |
| `cicd-pipeline/SKILL.md §踩坑` | 新增"CI 使用较新 DinD"场景 |
| `LESSONS.md` | 第 11 条反模式：基础设施依赖长期锁定 vs 定期升级 |

## 3 个 commit

| # | Commit | 说明 |
|---|--------|------|
| 1 | `fix(deps)` | Testcontainers 版本升级 |
| 2 | `docs(framework)` | FB-02 二次沉淀 + cicd-pipeline 硬约束 + LESSONS 第 11 条 |

## 验证

- ✅ 本地 Docker JDK 17 真实跑单元测试：**15/15 PASS**
- ✅ lint 0 错误
- 🟡 功能测试的 Testcontainers 启动验证依赖 CI Linux runner 完成（macOS 本地受 FB-02 原问题干扰）

## 下一步

合并后让 CI 二次验证功能测试能否启动容器。如果 1.20.6 仍不行，再考虑 1.21.3。

CI 失败根因

修复

顺带沉淀到框架

3 个 commit

验证

下一步

Successfully merged and closed