CHAPTER 13 · 公开候选
“结果不对”不是诊断。你会保留修复前摘要,让范围守卫指出 B-17,写出已知与仍未知,再只改选择范围;修复后的摘要除去 B-17 那一行外必须逐字相同。
打开第 13 章练习入口。完整任务位于练习包内 tasks/chapter-13.md;网站只提供下载与阅读,不会替你执行本地文件。
1. 起点
批处理摘要中出现了范围外材料 B-17。你知道“它不该出现”,但还不知道哪一步让它进入结果。
先理解问题
最危险的排查方式是先删异常,再写一个听起来合理的根因。B-17 输入必须保留,before 必须保留,同一守卫必须先红后绿;只有这样才能说“范围过滤”被证实。
2. 只读输入
inputs/chapter-13/allowed-scope.jsoninputs/chapter-13/B-17.mdinputs/chapter-13/incident-request.md- 第 12 章结果、异常与决定
建议阅读顺序
先读允许范围和修复前摘要,再读 B-17 本身;最后看事件请求。顺序的目的,是先固定现象和规则,不让解释抢先。
3. 唯一写入位置
只写 workbench/incident/。先保存的现场文件不得覆盖。
写入位置是本章的安全边界。Codex 可以创建目录,但不能扩大到 inputs、checkpoint 或别章输出。
4. 本章唯一成果
交付 symptom.md、timeline.md、hypotheses.md、before-summary.md、red.log、fix.md、after-summary.md、green.log 和 decision.md。
成果必须能打开、能回查、能由本章检查验证。只有一句“已经完成”不算交付。
5. 可复制给 Codex 的任务
先把出现 B-17 的摘要原样保存为 workbench/incident/before-summary.md,并写现象、时间线和至少三个仍待验证的假设。运行 `node scripts/run-scope-test.mjs --expect-red workbench/incident/before-summary.md workbench/incident/red.log`;它必须检测到 B-17、直接退出 1,并把命令和失败信息写入 red.log。`run-scope-test.mjs` 是外层命令封装器;日志中的 `COMMAND` 记录它实际调用的底层 `scope-guard`,所以两行命令不同是预期。不要删现场,不要同时改多项。只把摘要生成器的范围过滤从宽泛模式改成 allowed-scope.json 的明确 ID 允许清单,保持其余输入和格式不变,生成 after-summary.md。用同一封装器的 `--expect-green` 再次运行守卫并写 green.log;比较前后允许 ID,写 fix.md 和证据强度诚实的 decision.md,最后运行 npm run check:13。
把代码块整段复制,不要拆掉输入范围、停止条件和检查命令。Codex 的总结不能代替产出文件。
6. 你必须亲手完成
先阅读 RED,确认失败来自 B-17 越界而非命令错误;再逐行比较 before/after,确认唯一消失的是 B-17、允许材料仍在;最后把“证实了什么、仍不知道什么”写入 decision.md。
人工动作为什么不能省
你要亲手逐行比较 before 与 after:S-01 至 S-05 完全相同,唯一少 B-17。再读 decision,确认“请求为何产生”仍未知,没有被模型推测冒充根因。
7. 你应该看到
- 原始现场和 B-17 输入都还在。
- RED 直接退出码为 1,并准确点名 B-17。
- 最小修复只改变范围过滤。
- GREEN 直接退出码为 0,允许 ID 没有丢失。
跟着做:从输入到可观察结果
1. 保存现场
把 checkpoint 原样保存为 before,保留 B-17 输入。
**你应看到:**before 同时含五个允许 ID 与 B-17。
2. 运行范围守卫
执行 node scripts/run-scope-test.mjs --expect-red workbench/incident/before-summary.md workbench/incident/red.log。这是外层命令封装器;red.log 的 COMMAND 记录实际调用的底层探针 scope-guard。
**你应看到:**red.log 点名 OUT_OF_SCOPE: B-17,直接退出码 1。
3. 只改一个变量
从摘要选择中移除 B-17,不改输入、格式或允许 ID。
**你应看到:**before 去掉一行后与 after 逐字相等。
4. 同一守卫复测
检查 green.log,运行 npm run check:13。
**你应看到:**直接退出码 0,五个允许 ID 全部保留,决定区分已证实与仍未知。

参考完成态:本地实跑记录
- before 保存 B-17,after 只少这一行。
- 同一守卫日志分别记录直接退出 1 与 0。
- decision 保留仍未知,没有夸大根因。
证据文件:completed-example/incident/red.log。这些记录只证明虚构练习在本地按规则跑通,不代表网站已发布、现实用户已使用或作者已批准。
8. 三个真实坑
坑 1:先删现场
如果覆盖 before-summary.md,就没有可信起点。检查要求 before-summary.md 去掉 B-17 那一行后与 after-summary.md 保持一致;先保留 before,再运行 RED,才能证明只改变了范围选择。
坑 2:一次改多个变量
若同时改过滤、输入和摘要格式,无法归因。差异检查只允许范围选择逻辑和随之消失的 B-17 行变化。
坑 3:把解释当根因
假设文件故意列出多个可能。只有一变量复测支持的结论才能标为“已证实”,其余继续保留未知。
这三个坑都由练习材料、代码或检查实际暴露,不是提醒语。
先看信号,再做补救
**识别信号:**before 已经没有 B-17、after 还改变了别的行,或 decision 把未验证原因写成根因,说明现场或因果链被破坏。**补救动作:**从只读现场恢复 before,重新得到点名 B-17 的 RED,只改变允许范围过滤;逐行确认 before 去掉 B-17 后才等于 after。
补救后仍不能让本章检查因正确原因通过,就按第 10 节停止并回退;不要手改日志或复制参考完成态绕过。
9. 复选框验收
- before 现场在任何修改前已保存。
- RED 因 B-17 越界退出 1。
- 最小修复只改变范围过滤。
- GREEN 退出 0 且允许材料完整。
-
npm run check:13通过。
每一项都要靠打开文件或完成动作后再勾选;不要只凭 Codex 报告的 PASS。
10. 停止、回退与交接
无法保存现场、RED 原因不对、差异超过一个变量或允许材料丢失时停止。回退为恢复过滤基线并保留全部事件证据。交给第 14 章的是修复后的允许范围、前后摘要、RED/GREEN 与证据结论,不交一个被夸大的“全部解决”声明。
**停止条件:**现场被覆盖、修复改动超过 B-17 一行、允许材料丢失、或未验证解释被写成根因。
**回退动作:**从只读 before checkpoint 重建 after;before、red.log 和 B-17 输入始终保留。
**交接文件:**incident/ 的 before/after、RED/GREEN、修复说明与证据决定。