[Luo-root]

这份 PR 做了什么

加一份评测基线：evals/baseline.md。v1.0.0 之后改 skill 时，要能看出「是变好还是变坏」——这份文件就是那个对照点。

它记录了首次跑通 evals/runbook.md 三种问法的完整结果。

结论摘要

维度	A（快模式）	B（按七维审）	C（模块体检）
命中	6.5 / 12（54%）	8.5 / 12（71%）	9.5 / 12（79%）
误报	0 条	1 条（−1）	1 条（−1）
归类（按已报条目）	66.7%	68.8%	68.8%
证据强度均值	2.8 / 5	3.3 / 5	3.3 / 5
表达质量	6.6 / 12	8.2 / 12	8.6 / 12

• 档位分流全部正确：问「能不能合」的那轮输出紧凑列表 + 一句结论，没套六段骨架；另两轮输出完整七维覆盖表 + 拍板项 + 已查过没问题。
• 差距在命中覆盖，不在判级能力：归类质量三轮接近，快模式少的是设计面条目，符合它「只报本次引入、能落到触发路径」的定位。
• 三轮共同漏掉的只有 2 条，而这两条恰好是标准答案本身站不住的那两条——漏报不是本 skill 的系统性短板。

顺带暴露的问题（已分别开票，本 PR 不改）

• ground truth 的 G4 判定错了：read-only 承诺有限定语，不该报为缺陷 #15：ground truth 的 G4 判定错了。源码那句承诺有限定语「read-only with respect to the order store」，写 c.Processed / c.Stats 不违反它（那是 Checkout 自己的字段，不是订单存储）。三轮里两轮明确判定该承诺成立并给了推理。
• dimensions.md 第 5 维自相矛盾：硬编码的「算」与「不算」两解（退款窗口类业务政策值） #16：references/dimensions.md 第 5 维自相矛盾——「算」条款说会随版本变化的要报，「不算」条款把「7 天」列为真不变量，而退款窗口正是这类业务政策值。B、C 两轮明确引用细则原文判了「硬编码：无发现」。是细则给了两个互斥答案，不是模型做错。
• 命名/分包口味这条不报边界没守住：2/3 轮把包名不一致报成 P2 缺陷 #17：命名/分包口味这条不报边界没守住，2/3 轮把「两个包都叫 package shop」报成了 P2 缺陷。这也是本次唯一的误报扣分项。

另外基线里记了 13 条标准答案漏掉的真缺陷（三路合计发现，全部可复核）——当前 12 分制只覆盖样本真实缺陷的一部分，所以基线偏乐观。

口径说明

• 分数按**修前的标准答案（v1）**计算，baseline.md 里另附 v2 口径复算。
• 修完 ground truth 的 G4 判定错了：read-only 承诺有限定语，不该报为缺陷 #15 / dimensions.md 第 5 维自相矛盾：硬编码的「算」与「不算」两解（退款窗口类业务政策值） #16 后需要重跑一轮才能得到与修订后 GT 同口径的新基线，否则新旧分数不可比。原有 v1 分数保留不覆盖——它是「当时按当时的标准答案跑出来的结果」，属历史事实。
• 三轮原始输出留在仓外 scratchpads\dcr-eval\runs\，不进版本控制。

验证

• node tools/lint-skill.mjs . 通过。
• 本 PR 只新增一个 Markdown 文件，不改 skill 执行文件，不影响 CI 的 lint 检查。

关联 #14。