动机（Why）

目标项目 anta-newproject-demo 在方向 D 指令下完成第一个真实业务需求 Q2-001（文章 CRUD），PR #2 合入 main。过程中发现 4 条规则空白——本 PR 主动回写到源仓库，保持"规则从业务中来、回馈到业务中去"的健康循环。

"规则 ↔ 业务" 双向 loop 首次闭合：

• PR #40 / PR-B / PR-C 是「规则修订 → 目标项目落地」（向外）
• PR-D 是「目标项目经验反哺规则」（向内回路）
• 对比尾声 PR #39 的「向外溢出」——PR-D 是「向内反哺」，是尾声之后第二种健康形态

关闭目标项目 anta-newproject-demo/CHECKPOINT.md §五 的 T-Q2-b + T-Q2-c 两条回馈类待办。

变更清单（What）

2 个 commits 分层推进

• commit 1 docs(rules) 0fe60f7：规则层实质修订（3 文件）
• commit 2 docs(meta) 702c9d0：CHECKPOINT §四 轮次 14-d 档案同步（1 文件）

改动 1：.codebuddy/skills/scaffold/SKILL.md 局限节强化（§6 → §9）

• 修改 §字段类型：加"常见误用"提示框
  • 用户常写 string/boolean 这些通用术语，scaffold 只识别 str/bool/text 等 9 种抽象类型
  • 不识别类型被静默忽略——字段数变 0 但 15 个骨架文件仍生成
• 新增 §7 字段命名转换：Entity 驼峰 ↔ SQL snake_case 需人工核对
  • Flyway 迁移脚本和 MyBatis XML 都不自动转换
  • 附 grep 检查命令定位潜在错误
• 新增 §8 默认 deleteById 是物理删除——业务可能要求软删除
  • 6 处典型改写清单（注解 SQL × 2 + XML × 3 + Service 调用 × 1）
  • 所有查询必须加 WHERE is_deleted = FALSE 过滤
• 新增 §9 系统字段（isDeleted / createdBy）会被放进 DTO/VO——需按业务移除
  • 引用 backend-core.md §2.1 边界对象 规范
  • 首次总结 scaffold 70/30 黄金比例：70% 骨架 + 30% 业务适配（Q2-001 实测得出）

改动 2：LESSONS.md §二 新增反模式 B12（18 条 → 19 条）

「通过工具 UI 的颜色 / 位置 / 排版推断数值而非读真实文本或原始数据」

• 诞生场景：JaCoCo HTML 报告 68 of 107——68 是 MISSED（红）、39 才是 COVERED（绿），视觉直觉把阈值设为 43% 而非 36% 导致 mvn verify 立即挂
• 同类风险：Lighthouse 评分圆环 / Grafana 面板 / perf flame graph / 堆内存可视化 / Coverage HTML 色块
• 正模式：
  • 从机器可读格式（CSV/JSON/XML/API）读取数值
  • 手动计算一次交叉验证
  • 设置阈值后跑一次实际守门员确认不超过实测
  • 是 §原则 1「真实编译」在阈值设定场景的推论

改动 3：.codebuddy/rules/testing-standards.md 新增 §1.3.1「阈值首次激活的实操流程」

• 5 步标准流程：跑真实测试 → 读机器可读源 → 手动验证 → 向下取整 → 守门员实测
• 4 种工具的机器可读读数对照表（JaCoCo CSV / Vitest JSON / go cover / pytest-cov）
• 4 种典型误读场景对照（JaCoCo HTML / Lighthouse / Grafana / Vitest CLI）
• 与 LESSONS B12 建立双事实源——第 10 处双事实源

改动 4：CHECKPOINT.md 档案同步

• §一 last-update + §二 反模式条目 18→19
• §三 PR 总览新增 PR-D 行
• §四 轮次 14 主标题追加 PR-D（轮次 14 现有 4 子段 a/b/c/d）
• §四 轮次 14-c 末尾追加完整 PR-D 档案段（~60 行）：
  • 回写 3 件事的详细清单
  • 规则自举第 3 次实证详述
  • §七 指标变化子表（反模式 +1 / 双事实源 +1）
  • 4 条本轮学到的东西

验证证据（How verified）

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

关键指标变化

规则自举第 3 次实证

写 testing-standards §1.3.1 时最初文字写了 Q2-001 演练（2026-05-03）——abstraction_check.py 立即识别 testing-standards.md:70 的 2026-05-03 为 residual 并阻塞：

⚠️ .codebuddy/rules/testing-standards.md:70 [residual] match='2026-05-03'
    理由: 不匹配任何豁免规则

改写为"曾有演练"后通过。这是继 PR #38（2026-05-03 硬编码）+ PR-C（CNB 商标）之后的第 3 次规则自举——3 次同构实证说明：规则写作者不会记住所有反模式，但守门员记得。

影响面（Impact）

规则体系的累积演进

• scaffold SKILL.md 现覆盖 9 条局限 + 字段类型误用提示，首次业务用户会少踩 3 个坑
• LESSONS 累积 19 条反模式（A7 + B12）
• testing-standards 新增阈值首次激活实操——每个从"空项目"进入"真实业务"的新项目都会用到此节
• 双事实源 9 → 10 处

发现的新反模式产生路径（入 CHECKPOINT 轮次 14-d 档案）

• B11 空 PR body：外部视角（用户）驱动发现——"规则盲区"型
• B12 UI 误读：内部失败驱动发现——"阈值误设"型
• 两种驱动机制应作为下次 retrospective-sop 修订的双重候选触发源

候选待办（本 PR 不处理）

• T-Q3-a：retrospective-sop §5.1 加入「第五档：用户/业务驱动的即时审视」——由 B11 + B12 两种来源共同触发的 SOP 修订候选（已在 CHECKPOINT 轮次 14-c/14-d 留记）
• 目标项目 T-Q2-a（功能测试补齐）仍在目标仓库待办，不在本 PR 范围

轮次 14 的完整形状

至此轮次 14 有 4 子段：

• 14-a（PR #40）：.archived/ 结构性修正
• 14-b（PR-B）：LESSONS §四 修订 + A7 反模式
• 14-c（PR-C）：远端 CI 验证 + PR body 规范 + B11
• 14-d（PR-D）：Q2-001 业务反哺 + B12 + testing-standards §1.3.1

可能是本项目迄今跨度最大的一个轮次——从规则修订到目标项目业务落地再到业务反哺规则的完整周期。

Refs

• 父事件：
  • 目标项目 anta-newproject-demo PR #2 Q2-001 文章 CRUD 合入
  • 目标项目 CHECKPOINT §五 T-Q2-b + T-Q2-c 回馈类待办
• 关联：
  • LESSONS.md §二 B12（UI 颜色位置推断数值）
  • rules/testing-standards.md §1.3.1（阈值首次激活实操）
  • skills/scaffold/SKILL.md §字段类型 + §7 / §8 / §9
  • CHECKPOINT §四 轮次 14-d（"规则↔业务"双向 loop 闭合）
• 远端业务验证：https://cnb.cool/qshenzhang/anta-newproject-demo/-/build/logs/cnb-npo-1jnmqmgrk（PR #2 触发的 14/14 绿 239.8s）