@@ -356,6 +356,57 @@ git commit -m "feat(scripts): 行数红线测量与棘轮校验工具"
 
 ---
 
+### Task 2 修复轮（**Task 3 的前置**，单独提交）：两条 Minor
+
+Task 2 评审结论 **APPROVE**（无 Important），但给出两条 Minor。**它们必须在 Task 4 接线之前修掉** —— 否则将来会变成静默通过路径。
+
+**Minor 1（真问题，有明确的未来触发条件）**：`check()` 的 `(c)`/`(d)` 全部依赖 `measured` / `rows` 非空，而 `(a)`/`(b)` 只依赖 `FROZEN_OVER_LIMIT` 非空。评审者实测三种失效组合：
+
+| 失效组合 | 问题数 | exit |
+|---|---|---|
+| 扫描域（`SCAN_DIRS`）不存在 | 132（15 个 `b` + 117 个 `d`） | 1 |
+| 登记表不存在 | 138（全走 `c`） | 1 |
+| **两者同时失效** | **15（只剩 `b`）** | 1 |
+
+⇒ 问题数从 47 塌缩到 15 时**仍是红的**，**但一旦 `FROZEN_OVER_LIMIT` 被清空（正是 0-C2/0-C3 拆完后的目标状态），同样的双失效会给出 `exit 0` 绿灯** —— "工具坏了却报平安"，而且恰好发生在没人再盯它的时候。
+
+**修法**：在 `check()` **最开头**（`scanTree()` 之后、任何不变式之前）加规模自检：
+
+```js
+  // 规模自检：没有它，扫描域失效会让 (a)/(c) 静默通过、(d) 反把 117 条登记行报成"指向不存在的文件"。
+  // 更危险的是未来：FROZEN_OVER_LIMIT 被清空（0-C2/C3 拆完后）时，双失效会给出 exit 0 绿灯。
+  if (measured.size === 0) {
+    console.error(
+      `❌ line-limits：扫描域为空 —— ${SCAN_DIRS.join(' / ')} 下没有匹配 ${SOURCE_EXT} 的文件。\n` +
+        `   这几乎总是路径写错或工作目录不对，**不是"没有超限文件"**。`,
+    );
+    process.exit(1);
+  }
+```
+
+**Minor 2（诊断误导）**：扫描根失效时日志报 117 条「`(d)` 条目指向不存在的文件」——把真实原因（内容树没扫到）说成"登记行该删"，**会把人引向删行**；登记表缺失时则逐条报「未登记」，却不提示"登记表不存在"。
+
+**修法**：在 `parseTable()` 之前显式判定登记表是否存在，并给专用提示：
+
+```js
+  const tableAbs = join(ROOT, TABLE_PATH);
+  if (!existsSync(tableAbs)) {
+    console.error(`❌ line-limits：登记表不存在 —— ${TABLE_PATH}。先运行 --write 生成，或检查路径。`);
+    process.exit(1);
+  }
+```
+
+（扫描根缺失由 Minor 1 覆盖；两者合起来就不再产生那 117 条误导性的 `(d)`。）
+
+**Nit（不单独处理）**：`writeFileSync` 目前 import 未用、docblock 已宣称 `--write` —— **Task 3 Step 1 加上写分支后自然消解**。（这是计划 Step 1 逐字如此，非实施者擅自增删。）
+
+**本修复轮的验收**：
+1. 默认校验**行为不变**：仍报 **47** 处、`exit=1`
+2. 三条失效组合各自给出**专用提示**（依次把 `SCAN_DIRS` 指向不存在路径、把 `TABLE_PATH` 指向不存在文件、两者同时；**每次都要用 `Copy-Item` 备份还原**，验完 `git diff --stat` 为空）
+3. **单独提交**：`fix(scripts): 校验器补规模自检与失效诊断` —— **不要**与 Task 3 的重建混在一个提交里
+
+---
+
 ### Task 3: 重建登记表（把历史日志变成快照登记）
 
 **Files:**