命名/分包口味这条不报边界没守住：2/3 轮把包名不一致报成 P2 缺陷 #17

评测实测发现：「命名 / 分包口味」这条不报边界没守住——三轮里有 2 轮把纯口味问题报成了 P2 缺陷。

现象

两轮都把「两个包都叫 package shop，目录名却是 checkout/ 和 refund/」当成了一条 P2 文档问题报出来：

• B 轮：[P2][文档] internal/refund/refund.go:5 —「两个包都叫 shop，第一个同时用到两者的文件就得写 import 别名」
• C 轮：[P2][文档] internal/refund/refund.go:1 —「两个包都叫 shop，目录名却是 checkout / refund：同进程引用必须起别名，godoc 里并排两个 "package shop"」

两轮的论证都还挺完整——C 轮甚至查了 README.md 的结构图，说「代码与 README 对不上」。

但 ground truth 的「不该报」清单第一条就是：「两个包都叫 package shop、一个文件里放多个类型 → 命名与分包口味，SKILL.md 的不报清单第一条」。

SKILL.md 的不报清单第一条也写着：「纯格式、命名口味、import 顺序、主观分层偏好」。

为什么没守住

这条边界在当前 skill 里只以「清单条目」的形式存在，没有说明怎么判断某个命名问题算不算口味。模型看到的是：

• 一条抽象规则：「不报命名口味」
• 一个具体事实：「两个包同名、目录名不一致」

模型会认为后者有具体后果（import 要别名、godoc 混在一起），于是按「文档维度成立条件：指出读者会因此做错什么」报了。这不是模型乱报——是抽象规则没给出可操作的判断方法，而具体事实看起来又足够「有后果」。

对比一下守得住的那些条目：并发、重复、错误语义这些维度都有可判定的信号（重复看「两处是否必须一起改」、并发看「能不能说���交错窗口」），而命名这条只有一个标签。

修法建议

1. 给「命名口味」补一条可操作的判断方法，而不是只列它不该报。可能的写法（待议）：
   • 判据一：编译器和工具链会不会因此出错？ import 别名是 Go 的正常机制、编译器不报错、godoc 虽有重名但能正常生成 → 属口味。
   • 判据二：同项目里有没有相反的惯例？ 若项目其他地方包名都跟目录名对齐，才可能说「这里不一致」；项目内部本来就五花八门，就不是这条。
   • 判据三：能不能不改？ 改包名要动所有 import，代价与收益不成比例 → 更该不改。
2. 在 references/dimensions.md 第 4 维（文档）的「不算」里补一句具体例，让模型知道这类长什么样：

   算：文档说的行为与代码实际行为不符，读者会因此判断错。
   不算：包名与目录名不一致、文件内类型分组方式、命名风格——除非它让同一进程出现两个同名包必须起别名，或让 godoc 出现无法区分的同名条目。
   后者若要报，只能作为「需要你拍板」里的风格统一建议，不能作为缺陷。

3. 顺带检查 references/playbooks.md 的 API/库一节有没有覆盖「包名与导出面」这类问题（如果没有，别往里加——这属于口味）。

验收标准

• 修完后重跑评测，这一类（包名/目录名口味）不再出现在「必须修 / 建议修」里；若模型仍认为该提，它应当落在「需要你拍板」。
• 不牺牲别的维度：同样一轮里，真正的文档缺陷（godoc 与实现不符、注释说反了返回值顺序）仍然要报出来。实测里已经能报对，例如两轮都抓到了 Issue 注释「第二个返回值」实际是第一个。

附：本轮误报计分

按 rubric「把不该报清单里的候选报出来每条 −1」，这轮两轮各扣 1 分，是本次评测唯一的误报扣分项。