CodeBuddy

Hy3 preview

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

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

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

anta-workshopdemo

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

1.21.3 是 1.21.x 系列末版（2025-06），内嵌更新的 docker-java，对 daemon 协议漂移兼容性更强。
遵循 LESSONS §11：Testcontainers 锁在小版本末版最稳。

本地 15/15 单测 PASS。Testcontainers 容器启动验证待 CI Linux runner 二次确认。

fix(build): 修复 JaCoCo check 配置 + 设置现实的覆盖率保底阈值

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）

docs(share): M9 新增"首次消费端实证"子节——ROI 完整闭环

关闭 CHECKPOINT §五 T-Q3-07——把目标项目 PR #8 成功消费 M9 的
实证案例回写到源仓库，让 M9 首次拥有"生产端 + 消费端"双案例。

背景：目标项目 anta-newproject-demo PR #8 前端 E2E 选型阶段，
读 M9 决策树主动规避 CNB 坑点（services:[docker] 强制改 image），
选 Mock API 方案一次成功接入 Playwright E2E：
  - 0 CI fail（对比生产端方向 F1 的 4 PR 代价）
  - biz-frontend-e2e stage 耗时 32.7s（按 M9 坑点 3 自查真跑）
  - 本地 16/16 远端 16/16 全绿

改动 1：workshop-share.md §四 M9 新增"首次消费端实证"子节
  - 方案 A/B/C 选型对照表——把"与 M9 关系"列作为选型依据
  - 生产 vs 消费对比表：
    维度           生产端           消费端
    PR 数          4（演化）        1（一次成功）
    CI fail        2~3 次            0 次
    真跑验证       事后 stage 耗时  前置自查
  - M9 双层价值对照表（使用指引层 skills/ + 治理模式层 docs/）
  - 给新团队建议：从第 1 个坑就建条目 + 3 条记录标准

改动 2：§一 TL;DR 同步升级
  - M9 行"对应 PR"显式分列：
    生产：目标项目 #4~#7 + 源 PR-E /
    消费：目标项目 #8
  - 反直觉认识 M9 条追加"首次消费实证：一次成功 0 CI fail"

第 2 次双向 loop 首次闭合为 3 步环：
  方向 F1（业务代价）
    → 源 PR-E（规则沉淀）
    → 源 PR-G（升维为治理模式）
    → 目标 PR #8（规则消费）
    → 源 PR-H（本——反哺回填消费证据）

之前仅 2 步 loop（业务→规则；规则→业务 独立路径）；本 PR 让
"业务→规则→业务→规则"首尾相接——**规则体系首次自闭环**，
"可自我验证"的元证据。

规则自举第 7 次实证——连续 4 次放行：
  次 4~7 均为放行，证明团队稳态地用抽象术语写规则，§原则 4
  抽象化的长期回报进一步稳固。

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

4 条本轮学到的东西：
  - "双向 loop"升级为"3 步环"——规则体系可自我验证的元证据
  - 消费端证据比生产端难得——通常延后几个月才能拿到
  - M9 章节双层对照表首次显式——让 Leader 一眼看出分层价值
  - 规则体系稳态的标志——4 连放行 = 团队内化规则

派生自 meta-principles §原则 4（抽象化的长期回报——4 连放行）
+ §原则 5（契约——消费端证据是规则契约有效性的终极验证）
+ workshop-share §M9（本 PR 补齐 M9 的 ROI 实证闭环）。

Refs: 目标项目 PR #8（#7 合并后 30 分钟即消费 M9 成功）/
      CHECKPOINT §四 轮次 15-c /
      M9 双层分层（skills vs docs/workshop-share）


PR-H：M9 消费端首次实证回写——双向 loop 3 步环闭合（轮次 15-c）

## 背景

PR #6 已把 Testcontainers 从 1.19.7 升到 1.20.6 修复 `CAP_NET_RAW` 反序列化。本 PR 再进一步升到 **1.21.3**（2025-06，1.21.x 系列末版）做双重保险。

## 为什么还要升

- 1.20.6 发布于 2025-03，1.21.3 发布于 2025-06，再新 3 个月的 daemon 兼容补丁
- 1.21 系列内嵌的 docker-java 更新，对协议漂移兼容性更强
- 遵循 [`LESSONS.md §11`](LESSONS.md)：Testcontainers 应锁在小版本末版（不是直接锁大版本，也不是锁死某个早期补丁）

## 风险评估

| 项 | 评估 |
|---|---|
| 业务代码影响 | 0（Testcontainers 仅 test scope） |
| API 破坏 | 1.20 → 1.21 无破坏性变化（查过 release notes，仅新增容器类型和 bug fix） |
| 本地单测 | 15/15 PASS |
| 回滚成本 | 1 行版本号，CI 如果不行立即回滚 |

## 验证

- ✅ 本地 Docker JDK 17 真实跑：15/15 单元测试 PASS
- ✅ lint 0 错误
- 🟡 Testcontainers 启动真实容器的验证依赖 CI Linux runner 完成

## 决策依据

PR #6 合并后 CI 本应在 1.20.6 上再跑一次，如果通过就关闭 FB-02。但从风险模型看：

- 用更新的版本 = 降低"1.20.6 刚好也不够新"的尾部风险
- 成本 = 1 行版本号 + 1 个 commit
- **期望效益 >> 成本**，值得做

## 合并后预期

CI 在 main 上第三次跑 mvn verify：
- 如通过 → FB-02 彻底关闭，ac3 功能测试也能最终验证
- 如还挂 → 需要重新诊断（可能不是 Testcontainers 版本问题）

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

背景

为什么还要升

风险评估

验证

决策依据

合并后预期

Successfully merged and closed