[Luo-root]

这个 PR 修什么

v1.1.0 发版前的全面自检发现了 5 处执行文件内部口径不一致——不是 bug，是同一件事在两个文件里写成了两样话，模型读哪份就听谁的。加上把「成品不出现相对表述」这条纪律从人工 grep 变成机器检查。

本 PR 是 docs/eval-caliber 的后继分支（叠在上面），请按 #18 → #19 → 本 PR 的顺序合。

---

一、5 处口径不一致

1. 输出模板的维度覆盖表漏了两行

references/output-template.md 的「骨架表」和「示例表」都只列到「可观测性」，缺 性能 和 测试盲区。

但 SKILL.md 写着「扩展维度各自成行」——模型照着模板填表时，这两维要么被静默丢掉，要么自己另起格式。示例表尤其糟：它本来就是给模型抄的格式，抄出来的东西天然缺两行。

改法：骨架表与示例表各补两行，示例行给的是「无发现 + 为什么」的写法，不给空模板。

2. 扩展维度清单漏了「测试盲区」

SKILL.md 的扩展维度清单列了六个（错误路径、并发与生命周期、安全、兼容性、可观测性、性能），没有「测试盲区」。

结果是同一个 skill 里，测试盲区既出现在 references/dimensions.md 的细则里、又被输出模板要求成行，却没进 SKILL.md 的执行顺序清单——模型按 SKILL.md 跑就永远扫不到它。

改法：清单补上「测试盲区」。

3. 测试的触发条件与细则互相矛盾

SKILL.md 原来写的是：测试只在「断言了错误行为」或「改动会让既有测试静默失效」时报告。

但 references/dimensions.md 第 4 维的细则里还有第三个条件：关键分支完全没有覆盖且该分支高风险。

这两条打架。严格按 SKILL.md 执行就永远不会报测试盲区，而 GT 里 G10（零值 Checkout{} 这条高风险路径完全没覆盖）恰好是第三条撑起来的——首轮评测里 G10 三轮全漏，根因就在这儿。

改法：SKILL.md 的触发条件补上第三条，与细则对齐。

4. 硬编码维度的速查表还是旧口径

PR #19 把 references/dimensions.md 第 5 维拆成了「协议固定值 / 业务政策值」，但 SKILL.md 的速查表、references/verification.md 的硬编码闸门与必答句还留着旧问法（「它必须随什么变化」）。

新口径下一句话就能判：改了会出错 → 不算；改了只是口径变了 → 算。旧问法逼模型对所有字面量追问「随什么变化」，于是 100（元转分的协议固定值）也被报成硬编码——首轮评测里 B/C 两轮都明确引用旧细则判了「硬编码：无发现」，说明旧问法确实压住了真问题，但也让真问题（refundWindow = 24h 这个业务政策值）没有合法出口。

改法：SKILL.md 速查表、verification.md 闸门、必答句三处同步新口径，并给出「协议固定值 → 删」的出口。

5. API/库/SDK 这条 playbook 少查三类问题

references/playbooks.md 的 API/库/SDK 节原来只有：参数契约、默认值、零值歧义、向后兼容、错误语义、文档示例。

首轮评测三轮合计漏掉的 13 条真缺陷里，有三类正好落在这个缺口上，且都属于这个 playbook 该管的范畴：

• 共享状态：导出的指针字段 / 共享 map / 非原子的 x++（并发下丢更新 + data race）
• 零值可用性：导出类型零值能不能直接用，不能用时 godoc 有没有写明「必须用构造函数」
• 单位一致性：入口收「元」、出口返「分」，把上游总额直接传进去差一个数量级

改法：补这三类，并各写成可执行的判据（不是提醒，是「两种做法都对，但必须有一个，不能沉默」这种能落地的形式）。

---

二、一处事实错误（评测实测揪出来的）

references/dimensions.md 第 4 维的命名/分包判据第 1 条写的是：

import 别名是 Go 的正常机制，编译器不报错、go doc 也能正常生成 → 属口味，不报。

这句是错的。 本轮评测里 A 轮实测出：两个包都叫 shop 时，同一个文件里一起 import 而不起别名，编译器直接报

shop redeclared in this block
    other declaration of shop

（我另外独立复现过一遍，同样报错；起别名则编译通过。）

改法：把理由改成准确的说法——同名包一起 import 确实编译不过，但起个别名就能解开，编译器会拦住，不会有错误代码上线，go doc 只是包注释串味；处置规则不变（仍属口味，只能进「需要你拍板」，不能进「必须修/建议修」）。

evals/ground-truth.md 里「不该报」清单的同一条也写着同样的话，一并改掉，并在计分要点里注明：处置规则没变，所以修正前后的口径对同一份输出给分相同，不需要为这个修正单独重跑。

---

三、相对表述检查机器化

这个 skill 的硬要求是：成品里不出现「内置 X」「别的工具」「第二个工具」。只要提一次「内置」，这个 skill 就始终是相对于别的东西定义的，不是一份完整物。

原来这条靠人工 grep 守 —— 靠自觉的纪律一定会漏。现在进了仓库自带的 lint：

• 扫 SKILL.md / README.md / references/ / evals/
• 命中「内置」「别的工具」「第二个工具」即报错并给 文件:行号
• 退出码非 0，CI 的 lint skill 检查会拦住

验证方式：拿临时副本植入违规词，确认 lint 确实报出（退出码 1 + 定位到行号），再把测试副本回收站清掉。全仓真实文件扫描零命中。

---

四、顺带修正的两处小东西

• evals/ground-truth.md：G23 行号 42 → 41、G24 行号 36 → 35。GT 全部 25 条的行号已逐行核对源码，剩下两条是对齐后的结果。
• README.md / evals/README.md：缺陷数量 12 → 25、目录树补 baseline.md、首轮评测结论补一段（「三轮共同漏掉的两条恰恰是标准答案自己写错的两条」）。

---

五、验证

检查	结果
node tools/lint-skill.mjs .	通过（含新增的相对表述检查）
全仓 CRLF 检查（CI 同款）	通过
相对表述扫描（内置 / 别的工具 / 第二个工具）	零命中
GT 25 条行号逐条核对源码	通过
相对表述检查的反向验证（植入违规 → 必须报错）	通过
同名包 import 的编译行为	实测：不起别名报错、起别名通过（已据此修正 dimensions.md 的表述）

---

六、影响面

• 改的是执行文件（SKILL.md / references/）里互相矛盾的地方，统一到细则已有的口径；另有一处事实错误按实测更正。
• 改 SKILL.md 的执行顺序与扩展维度清单、改 references/dimensions.md 的「不算」条款 → 按 evals/runbook.md 的规则，必须重跑评测。本 PR 之后的评测已在进行，基线会作为独立 PR 追加进 evals/baseline.md。
• 不改变任何对外接口、不改样本代码。