CodeBuddy

Hy3 preview

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

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

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

anta-workshopdemo

docs: 10 轮迭代经验决算 LESSONS.md + 改造 README (#5)

收官文档：
- LESSONS.md（95 行）：10 轮迭代沉淀的经验决算，4 核心原则 + 10 反模式对照 + 13 工程资产 + 6 步迁移指南
- README.md（1→66 行）：按读者角色导航的入口

三份 md 各司其职：README 入口 / LESSONS 结论 / CHECKPOINT 轨迹。

feat(ci): 迁移演练的两处脚本修补——白名单 + 迁移警告

docs(meta): CHECKPOINT §四 轮次 14-e 追加——方向 F1 四 PR 经验回写档案

配合上一 commit 的 LESSONS / testing-standards / cicd-pipeline 修订，
登记本轮完整档案。

改动：
1. §一 last-update → PR-E 轮次 14-e
2. §二 反模式条目 19 → 21（A7 + B14）
3. §三 PR 总览新增 PR-E 行
4. §四 轮次 14 主标题追加 PR-E + 副标题扩展
5. §四 轮次 14-d 档案末尾追加 PR-E 完整档案段：
   - 4 PR 演化链表格（PR #3 假绿 → #4 推断修 → #5 诊断 → #6 装 CLI → #7 接受限制）
   - 本 PR 回写 4 条经验清单
   - §七 指标变化子表
   - 规则自举第 4 次实证（首次"放行"——守门员不粗暴）
   - 4 条本轮学到的东西：
     * "诊断 PR"作为第一公民 PR 类型候选
     * "信号欺骗家族"反模式首次成型（B12+B13+B14）
     * 4 PR 递进的价值验证——没有捷径跳过盲猜→实证
     * CNB 平台坑点的公共价值——跨项目可迁移资产

关闭的回馈类待办：
- ✅ T-Q2-e 回写目标项目经验
- ✅ T-Q2-i 棘轮口径区分版反馈到 testing-standards
- ✅ T-Q2-j LESSONS B14 候选

新增待办（Q3 周期候选）：
- T-Q3-01：git-conventions §4 新增 diag: commit type
- T-Q3-02：LESSONS §三 新增"信号欺骗家族"分类条目
- T-Q3-03：workshop-share.md 第 15 种模式"CI 平台坑点实证清单"
- T-Q3-04：目标项目 T-Q2-d 前端 E2E 补齐

本轮特别意义：
- 第 2 次"业务反哺规则"loop——PR-D 是单次 Q2-001 业务开发的经验回写，
  PR-E 是 4 PR 连续 CI 修复演化的经验回写。两次都证明"规则从业务
  中来"的健康循环形态
- 轮次 14 有 5 子段（a/b/c/d/e）—— 可能是项目最大跨度的一个轮次，
  从规则修订 → 目标项目业务落地 → 业务反哺 → CI 深挖 → 深挖反哺
- 对比尾声 PR #39 的"向外溢出"——PR-E 与 PR-D 都是"向内反哺"，
  两种健康形态共存：向外溢出（面向其他团队）+ 向内反哺（面向自己规则）

本地 9/9 CI stages 全绿 + 0 lint。

派生自 meta-principles §原则 5（档案作为机器可读契约——轮次 14-e
必须如实反映"回写"性质；B13/B14 反模式的命名空间规划必须登记到
CHECKPOINT 便于未来 B15+ 命名参考）。

Refs: 轮次 14-e / 目标项目 PR #4-#7 / LESSONS B13/B14 /
      testing-standards §1.3 棘轮口径区分 / cicd-pipeline CNB 4 坑点


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）

## 背景

10 轮迭代后的收官。CHECKPOINT.md 是过程日志，越写越长（200+ 行），信噪比下降。需要一份与它互补的结论性文档：任何人 10 分钟读完就能带走经验。

## 新增 LESSONS.md（95 行）

四个板块：

1. 核心原则 × 4（按重要性排序）：真实编译 / 可自举 / 契约优先 / 抽象化
2. 10 条反模式 vs 正模式对照表，每条附「在哪防御」链接
3. 工程资产清单（13 项），可直接拷贝到新项目
4. 迁移到新项目的最小步骤（6 步）+ 已知边界

## 抽象度自查（符合自定义原则）

- 无日期、无具体测试数字、无业务编号、无项目专属类名
- 符合「拷到新项目直接能用」的目标

## 重写 README.md

从 1 行扩到 66 行，按读者角色导航。

## 关系梳理

- README.md（入口，1 分钟）
- LESSONS.md（结论，10 分钟）— 新
- CHECKPOINT.md（轨迹，30 分钟）
- .codebuddy/README.md（规则索引）

## 验证

- lint 0 错误
- LESSONS 95 行（目标 ≤ 150）
- 0 处项目专属残留

背景

新增 LESSONS.md（95 行）

抽象度自查（符合自定义原则）

重写 README.md

关系梳理

验证

Successfully merged and closed