v1.1.0 发版票面

v1.0.0 之后的第一个版本。本票只列范围与验收，发版动作等命令。

本票已更新到「重跑完成」状态。 评测重跑（v4 轮）已跑完并落盘，三项验收里有一项不通过（详见第五节 P4），已在第六节写清后果与处置。

一、这一版要解决的

v1.0.0 之后我们把 skill 通审了一遍（12 张票、PR #13），又把评测跑通了一轮。v1.1.0 要装的是：

1. 审查本身更准——13 条设计问题的修复落地（已合入 feat: 修 13 个设计问题——路由分层、规则矛盾、输出契约、仓库工具链与评测护栏 #13）。
2. 能力覆盖不缺——合并判定与设计体检两类问题都能路由进来，skill 自成一体不依赖任何其他东西。
3. 能度量——有一份可复核的评测基线，改动之后能看出「是变好还是变坏」。
4. 能持续——把评测暴露出的口径问题修掉，让下一轮评测测得准。

谁会用它：在合并前自查 PR 的开发者（快模式问「能不能合」），以及要审设计、契约、重复、过度设计的开发者（全量模式）。

二、功能点清单（这一版具体多了什么）

三、需求点清单（这一版满足了哪些要求）

四、这一版明确不做

五、发版前必须完成

P3 是硬门槛：不重跑就发版，等于把一个没验证过的口径修正放进正式版。这一条已经履行。

P3 重跑的实际过程

原计划是「修完标准答案 → 重跑一轮 → 发版」。执行时发现两件事，都得先解决才能拿到能进正式版的分数：

第一件：第一次重跑跑在了「移动的靶」上。
重跑的那几分钟里，我同时在改 skill 本体（发版前自检发现执行文件内部有 5 处口径打架）。三轮评测是并行的，每轮各自去读 skill 文件——而我正好在那几分钟里改它们。结果 A/B/C 读到的 skill 版本互不相同：C 轮明确读到的是修复前的模板（它自己的思考过程写着「输出模板漏了性能和测试盲区两行」）。这样的分数不能当基线——它描述的是一个中间状态，不存在哪个提交对应它。
处置：等改动全部落地、把 skill 冻结在 7c1c4ea 这一个提交上，三轮全部重跑。发版基线只认这个提交。

第二件：A 轮读到了磁盘上另一份过期的 skill 副本。
我给子 Agent 的约束里写了「不要读 D:\Github-Project\deep-code-review」，本意是防它去翻仓库里的标准答案。但 skill 的安装线本来就是从那个目录符号链接过去的——它读不到 skill，就去磁盘上别处找，找到了一份 10 月 19 日的旧副本（缺 regression-review.md，硬编码还是旧口径）。
后果：A 轮判「硬编码：无发现」，用的正是被 #19 修掉的那条旧细则。这轮作废。
处置：① 改约束——明确告诉它 skill 装在哪，同时只禁 evals/ 目录（那里才有标准答案）；② 把那份陈旧副本清进回收站（可还原）；③ A 轮重跑。两条都已写进 evals/runbook.md 的卫生规则。

P4 三件事的验证结果

断言③ 不成立的后果与处置：

• 不构成 v1.1.0 的阻塞项。原因是它测的不是一个「文档维度整体失灵」的系统性短板——三轮都能报出「文档与实现不一致」类问题（G3/G11/G14），说明这个能力在。漏的是两种更窄的形态：位置指代型（G19）和承诺无对应对象型（G4）。
• 这两条属于能力边界，补它们要改 references/dimensions.md 的成立条件 → 触发重跑评测，且属于新增能力不是修复。已单独开 v1.2.0 的票跟踪。
• 断言③ 的表述已在 evals/baseline.md 里按实测改写，避免下一轮又按旧表述去验收。

v4 轮分数（发版基线）

值得留意：C 轮命中最高，raw 反而最低——差距不在「看漏了什么」，在证据强度（C 4.20 vs A 4.93）。C 靠读完读懂拿命中，A 靠跑探针拿证据。

六、三个待拍板决策的实际执行

七、待你发话

1. PR 合并顺序：#18 → #19 → #21 → #22。这四个是叠着的（fix: 修 5 处执行文件口径不一致 + 1 处事实错误；lint 新增相对表述检查 #21 的 base 是 fix(dimensions): 修硬编码判定自相矛盾 + 命名口味边界；GT 扩到 25 条 #19 的分支，docs(evals): 折进判分细则 + 记录 v4 轮基线（25 条口径，冻结提交 7c1c4ea） #22 的 base 是 fix: 修 5 处执行文件口径不一致 + 1 处事实错误；lint 新增相对表述检查 #21 的分支），必须按这个顺序合，合并动作我不代合。
2. PR fix: 修 5 处执行文件口径不一致 + 1 处事实错误；lint 新增相对表述检查 #21 的顺序有讲究：它改了 references/dimensions.md 的第 5 维口径，而 docs(evals): 折进判分细则 + 记录 v4 轮基线（25 条口径，冻结提交 7c1c4ea） #22 的基线是按 7c1c4ea 跑的——7c1c4ea 正是 fix: 修 5 处执行文件口径不一致 + 1 处事实错误；lint 新增相对表述检查 #21 的头提交。所以 fix: 修 5 处执行文件口径不一致 + 1 处事实错误；lint 新增相对表述检查 #21 必须在 docs(evals): 折进判分细则 + 记录 v4 轮基线（25 条口径，冻结提交 7c1c4ea） #22 之前合，否则基线对应的代码状态对不上。
3. P5 打 tag 与发版，等你命令。
4. P6 关掉 issue 评测基线：首跑 A/B/C 三轮，记录分数与口径缺陷 #14–命名/分包口味这条不报边界没守住：2/3 轮把包名不一致报成 P2 缺陷 #17，等你合完再关。

八、已知能力边界（本轮实测，v1.1.0 不修，已开 v1.2.0 票跟踪）

这几条不是 skill 的缺陷（skill 内部口径一致、能跑的路径都跑通了），是能力覆盖上的已知边界——它们在标准答案里，但三轮都没当成一条结论报出来：

处置建议：v1.2.0 把「承诺指向的对象在不在」「godoc 的位置指代」「状态持久性」「零使用字段」四条做成 references/dimensions.md 里的可操作判据，然后按 evals/runbook.md 的规则重跑一轮。这会改 dimensions.md 的成立条件 → 必须重跑评测，所以不能塞进 v1.1.0。