从散乱材料到可维护工作台

CHAPTER 8 · 公开候选

这一章不再讲“应该如何整理”。你会实际处理 12 份当前材料、3 份归档材料和 5 个待确认问题，让 Codex 在不碰输入的前提下生成资料库，再亲手反查两个最容易误判的样本。

打开第 8 章练习入口。完整任务位于练习包内 tasks/chapter-08.md；网站只提供下载与阅读，不会替你执行本地文件。

1. 起点

你收到 12 份当前材料、3 份旧版和 5 项待确认问题。文件名看起来很整齐，但不能直接证明材料状态或内容。

先理解问题

真正的难点不是把文件排整齐，而是下一次仍能回答：这条记录从哪来、现在是什么版本、能不能进入后续内容。A-05 的文件名写着“最终版”，正文却是 v0.8；U-03 的文件名像已确认，正文仍是待确认。它们让“别猜”成为可以失败的行为门，而不是一句提醒。

2. 只读输入

• inputs/chapter-08/current/
• inputs/chapter-08/archive/
• inputs/chapter-08/pending/
• inputs/chapter-08/expected-records.json

开始前运行 npm run verify:inputs。不得修改、移动或重命名这些输入。

建议阅读顺序

先读 expected-records.json 了解数量合同，再读 A-05 和 U-03 观察陷阱，最后才让 Codex 扫描全部材料。这样你知道检查在保护什么。

3. 唯一写入位置

只写 workbench/library/。

写入位置是本章的安全边界。Codex 可以创建目录，但不能扩大到 inputs、checkpoint 或别章输出。

4. 本章唯一成果

建立一套能反查原材料的资料库：index.csv、field-rules.md、pending.md、update-log.md。

成果必须能打开、能回查、能由本章检查验证。只有一句“已经完成”不算交付。

5. 可复制给 Codex 的任务

只读取 inputs/chapter-08。逐份读取文件正文中的材料 ID、标题、日期、版本、状态和来源类别；不要根据文件名猜事实。把 12 份当前材料和 3 份旧版写入 workbench/library/index.csv，并让 current/archive 在独立字段中可区分。把 5 项未解决问题写入 pending.md，不得把它们写成已确认事实。补充 field-rules.md 和一条五项 update-log.md。只写 workbench/library，完成后运行 npm run check:08；如果输入哈希变化，立即停止。

把代码块整段复制，不要拆掉输入范围、停止条件和检查命令。Codex 的总结不能代替产出文件。

6. 你必须亲手完成

从索引随机选三条当前材料和一条旧版，打开原文件逐字段核对；再选一项待确认问题，确认它只出现在 pending.md，没有混进已确认索引或下一章事实。

人工动作为什么不能省

你要亲手打开 A-05_最终版.md 和 U-03_已确认学习时长.md，再到索引与待确认清单逐项对照。自动检查可以证明结构，却不能替你判断一条陈述是否忠实。

7. 你应该看到

• 索引有 15 行材料记录：12 行 current、3 行 archive。
• 待确认清单有 5 项，每项保留问题而不是虚构答案。
• 每行都有能回到原文件的相对路径。
• 输入完整性检查前后哈希一致。

跟着做：从输入到可观察结果

1. 确认共同起点

运行 npm run verify:inputs。

你应看到：看到 INPUTS_PASS: 62 files unchanged；它证明整套练习输入没有被提前改写。

2. 生成资料库

把第 5 节任务整段交给 Codex，让它只在 workbench/library/ 生成四个成果文件。

你应看到：本章检查能确认 12 current · 3 archive · 5 pending，目录出现四个成果文件。

3. 反向抽查

从 index.csv 抽 A-05、任意两条 current 和一条 H 系列，沿相对路径回到正文；再检查 U-03。

你应看到：A-05 仍为 v0.8，U-03 只在 pending.md，没有因为文件名变成事实。

4. 关闭本章

运行 npm run check:08，随后再次运行输入完整性检查。

你应看到：本章检查退出 0，输入哈希前后相同。

参考完成态：本地实跑记录

• 索引基线恰有 12 行 current 和 3 行 archive。
• U-01 至 U-05 只在待确认清单。
• 本地行为门输出 CH08_PASS，输入未改。

证据文件：completed-example/library/index.csv。这些记录只证明虚构练习在本地按规则跑通，不代表网站已发布、现实用户已使用或作者已批准。

8. 三个真实坑

坑 1：把文件名当事实

有一份文件名看起来像“最终版”，正文却明确说明它仍需核对。检查会比较正文元数据，靠文件名判断会失败。

坑 2：把旧版登记为当前版

旧版标题与当前材料相近。若索引没有独立版本区域，检查会发现 H 系列混入 current。

坑 3：把待确认写成已确认

U 系列故意提供了听起来合理但未解决的问题。它们一旦进入确认索引或第 9 章事实底稿，检查立即失败。

这三个坑都由练习材料、代码或检查实际暴露，不是提醒语。

先看信号，再做补救

识别信号：A-05 在索引里不是 v0.8、H 系列出现在 current，或 U 系列出现在 index.csv，说明你相信了文件名或补写了答案。补救动作：回到正文重新抄 category、version、status 和 source，只清理并重建 workbench/library/；随后重新运行输入完整性检查。

补救后仍不能让本章检查因正确原因通过，就按第 10 节停止并回退；不要手改日志或复制参考完成态绕过。

9. 复选框验收

• □npm run verify:inputs 通过。
• □index.csv 正好包含 12 条 current 和 3 条 archive。
• □抽查的四条材料都能反查原文件。
• □pending.md 正好包含 5 项未决问题。
• □npm run check:08 通过。

每一项都要靠打开文件或完成动作后再勾选；不要只凭 Codex 报告的 PASS。

10. 停止、回退与交接

发现来源、版本或状态说不清时停止，不替材料补答案。若写错，只清理 workbench/library/ 后重做，不碰 inputs/。交给第 9 章的是 workbench/library/index.csv、pending.md、field-rules.md、update-log.md，并在交接记录中抄下本轮 npm run verify:inputs 的最终通过行；第 9 章只使用 status=已确认 的 current 行。

停止条件：索引行无法回到输入、U 系列进入确定事实、或输入哈希变化。

回退动作：只清理 workbench/library/ 后重建，不修改、重命名或补写 inputs/。

交接文件：workbench/library/index.csv、pending.md、field-rules.md、update-log.md，以及本轮 verify:inputs 最终通过行；第 9 章只读使用已确认 current 行。

CHAPTER 9 · 公开候选

上一章解决“材料能不能信”，这一章解决“怎样交付而不带偏事实”。你会实际生成一个可打开的十页 PowerPoint、同内容 HTML 预览、一页摘要、事实底稿与五条反查记录。

打开第 9 章练习入口。完整任务位于练习包内 tasks/chapter-09.md；网站只提供下载与阅读，不会替你执行本地文件。

1. 起点

第 8 章已经把可用事实、旧版和未决问题分开。现在要把已确认材料组织成一页摘要和十页演示，而不是只交一份大纲。

先理解问题

一份顺滑的大纲仍可能把未知写成事实，也可能根本没有形成用户可打开的交付物。本章同时约束内容链和文件链：陈述要回到 A-ID，.pptx 要有真实十页结构，预览要离线可读。

2. 只读输入

• workbench/library/index.csv
• workbench/library/pending.md
• 第 8 章索引指向的 current 原材料
• inputs/chapter-09/audience-and-purpose.md
• inputs/chapter-09/deck-constraints.json
• inputs/chapter-09/statement-check.json

建议阅读顺序

先读受众与用途，再看十页约束和五条抽查表；最后才打开模板。先决定“讲什么、依据什么”，视觉模板不能反过来决定事实。

3. 唯一写入位置

只写 workbench/content-package/。

写入位置是本章的安全边界。Codex 可以创建目录，但不能扩大到 inputs、checkpoint 或别章输出。

4. 本章唯一成果

交付 facts.md、one-page-summary.md、deck-outline.md、十页 weekend-learning-workbench.pptx、deck-preview.html、visual-assets.md 和 acceptance.md。

成果必须能打开、能回查、能由本章检查验证。只有一句“已经完成”不算交付。

5. 可复制给 Codex 的任务

只使用第 8 章 index.csv 中 current 且 status=已确认的材料，以及 inputs/chapter-09 的读者与约束。先写带 A 系列材料 ID 的 facts.md，再写一页摘要和十页 deck-outline.md，并把同一十页内容写入 workbench/content-package/deck-model.json。按脚本 usage 运行 `node scripts/export-deck.mjs workbench/content-package/deck-model.json workbench/content-package/weekend-learning-workbench.pptx`；export-deck.mjs 只生成实际十页 PPTX，再读取同一 deck-model.json 单独生成同内容的 deck-preview.html。deck-model.json 是中间文件，不替代七项交接成果。U-04 的品牌颜色仍待确认，因此 PPTX 和 HTML 预览只使用中性灰阶，不得自行选择蓝绿或其他品牌强调色；在 visual-assets.md 明写这一边界，并为每项视觉素材写清来源类别与用途。不得把 pending.md 的问题改写成事实，不得联网取图。只写 workbench/content-package，最后运行 npm run check:09。

把代码块整段复制，不要拆掉输入范围、停止条件和检查命令。Codex 的总结不能代替产出文件。

6. 你必须亲手完成

按 statement-check.json 指定的五条陈述，逐条从摘要或演示回到 facts.md，再回到 A 系列材料。把核对结果与日期写入 acceptance.md。

人工动作为什么不能省

你要亲手从第 1 页滚到第 10 页，并用演示软件打开实际 PPTX。再按 statement-check.json 做五条双向反查；只看大纲或相信扩展名都不算完成。

7. 你应该看到

• .pptx 是可识别的演示文件，内部正好十页。
• HTML 预览也正好十页，没有演示软件仍可阅读。
• 五条抽查陈述都有事实 ID 和材料 ID。
• PPTX 与 HTML 预览只使用中性灰阶；视觉素材清单明确说明 U-04 的品牌颜色仍待确认。
• 视觉素材清单说明“为什么用”，没有网络素材依赖。

跟着做：从输入到可观察结果

1. 锁定受众与事实

阅读 audience-and-purpose.md，并确认事实底稿只引用第 8 章已确认 A-ID。

你应看到：U-01 至 U-05 只出现在排除声明，不进入确定陈述。

2. 生成真实内容包

把第 5 节任务整段交给 Codex；它用包内 scripts/export-deck.mjs 从 deck-model.json 只导出 PPTX，再从同一模型单独生成预览。

你应看到：出现真实 .pptx、十页预览、摘要、底稿、素材表和验收表。

3. 打开而不是猜

先浏览 deck-preview.html，再打开 weekend-learning-workbench.pptx。

你应看到：两处均恰有 10 页；封面、第 5 页和第 10 页内容与大纲一致。

4. 反查与离线检查

完成五条反查，运行 npm run check:09。

你应看到：输出 CH09_PASS: 10 slides · 5 statements traced，PPTX 无外部关系。

参考完成态：本地实跑记录

• PPTX 包内恰有 10 个 slide XML。
• 五条抽查均回到事实底稿和 A-ID。
• 所有关系文件均无 External link，U-ID 未进入事实。

证据文件：completed-example/content-package/weekend-learning-workbench.pptx。这些记录只证明虚构练习在本地按规则跑通，不代表网站已发布、现实用户已使用或作者已批准。

8. 三个真实坑

坑 1：补写没有依据的事实

待确认清单含有很容易被补全的数字和时间。事实检查会拒绝任何 U 系列 ID 或无法回到 A 系列正文的陈述。

坑 2：把大纲冒充完成的演示

检查会直接打开 .pptx 包并数 slide XML；只有 Markdown 大纲或改后缀的文本文件无法通过。

坑 3：视觉层偷偷替待确认项做决定

U-04 没有确认品牌颜色。即使素材全是本地生成，也不能在预览里擅自选蓝绿强调色；本轮只用中性灰阶，并在 visual-assets.md 同时说明颜色边界、来源类别和用途。检查器会读取 HTML CSS 与 PPTX 页面的显式颜色。

这三个坑都由练习材料、代码或检查实际暴露，不是提醒语。

先看信号，再做补救

识别信号：facts.md 出现 U-ID、PPTX 不是十页、某条陈述回不到 A-ID，或关系文件出现 External，说明事实链或文件链已经断开。补救动作：先从已确认索引重建 facts.md，再清理 workbench/content-package/ 重新导出；不要靠补页、改扩展名或联网素材掩盖失败。

补救后仍不能让本章检查因正确原因通过，就按第 10 节停止并回退；不要手改日志或复制参考完成态绕过。

9. 复选框验收

• □facts.md 的确定陈述全部带 A 系列引用。
• □摘要能在一页内读完。
• □PPTX 与 HTML 预览均为十页。
• □PPTX 与 HTML 预览均为中性灰阶，visual-assets.md 保留 U-04 的待确认边界。
• □五条陈述已亲手完成双向反查。
• □npm run check:09 通过。

每一项都要靠打开文件或完成动作后再勾选；不要只凭 Codex 报告的 PASS。

10. 停止、回退与交接

事实无法回到第 8 章、PPTX 不是十页、出现非灰阶品牌配色、或出现联网素材时停止。回退只清理 workbench/content-package/ 后从 facts.md 重建。交给第 10 章的是已验收的内容包和 inputs/chapter-10/field-card.md；不得带入任何现实任务数据。

停止条件：PPTX 无法打开、页数不等于 10、陈述无法回到 A-ID、或出现网络素材依赖。

回退动作：只清理 workbench/content-package/，保留第 8 章资料库，从 facts.md 和安全模板重建。

交接文件：完整内容包与第 10 章字段卡；下一章只把这些虚构成果当记录对象，不读取现实任务或账号。

CHAPTER 10 · 公开候选

这一章不讨论“以后可以做什么系统”。你会拿到一个真实离线页面，亲手新增 T-004、观察统计变化、按状态筛选，再刷新确认数据不会假装永久保存。

打开第 10 章练习入口。完整任务位于练习包内 tasks/chapter-10.md；网站只提供下载与阅读，不会替你执行本地文件。

1. 起点

你有一张五字段需求卡和三条虚构记录，需要做一个本地网页。目标只是“能记录、能筛选、能统计”，不是完整管理系统。

先理解问题

页面“能打开”只证明 HTML 存在。可用工具至少要完成一次输入—结果闭环，并诚实说明数据边界。本章把范围压到四个输入字段、三种状态和四个可观察行为，避免一上来造完整系统。

2. 只读输入

• inputs/chapter-10/field-card.md
• inputs/chapter-10/records.json
• 第 9 章已验收内容包的用途说明

建议阅读顺序

先读字段卡中的“做什么／不做什么”，再读三条样本，最后看只读 v1.0 checkpoint。不要从现有页面反推需求。

3. 唯一写入位置

只写 workbench/tracker-app/。

写入位置是本章的安全边界。Codex 可以创建目录，但不能扩大到 inputs、checkpoint 或别章输出。

4. 本章唯一成果

完成 index.html、styles.css、app-core.mjs、app.js、records.json 和 README.md 的记录页 v1.0。

成果必须能打开、能回查、能由本章检查验证。只有一句“已经完成”不算交付。

5. 可复制给 Codex 的任务

根据 inputs/chapter-10 的字段卡和三条虚构记录，在 workbench/tracker-app 建一个不联网的本地记录页 v1.0。字段只有自动 ID、任务名称、状态、下一步、待确认问题；状态只有未开始、进行中、已完成。实现新增、全部查看、按状态筛选和三个独立统计；空任务名称必须拒绝。数据只保存在页面内存，刷新后恢复三条样本，并在页面明确提示这一点。不得读取其他资料或增加账号、同步、权限、数据库。完成后运行 npm run check:10。

把代码块整段复制，不要拆掉输入范围、停止条件和检查命令。Codex 的总结不能代替产出文件。

6. 你必须亲手完成

启动 npm run preview，打开终端打印的根地址，再把路径切换到 /workbench/tracker-app/index.html。在浏览器新增一条有标题的虚构记录；切换到一个状态筛选并核对列表；再切回全部，核对三个统计。刷新页面，确认它恢复为三条起始样本。

人工动作为什么不能省

你要亲手新增“复查第九章五条陈述”，确认 T-004 和 2／1／1 统计；再筛选、提交一次空标题并刷新页面。页面内存边界只有经过刷新才真正被理解。

7. 你应该看到

• 空标题提交时出现明确错误且列表不增加。
• 有效记录得到自动 ID 并立即进入列表。
• 筛选后只显示所选状态，统计仍按全部内存记录计算。
• 刷新后回到三条样本，页面说明没有持久保存。

跟着做：从输入到可观察结果

1. 建立 v1.0 副本

把第 5 节任务整段交给 Codex，让它只在 workbench/tracker-app/ 建立页面。

你应看到：工作台出现 HTML、CSS、核心逻辑、页面脚本、三条样本和说明。

2. 完成一次有效新增

启动 npm run preview，填写任务名称、未开始、下一步和待确认问题后提交。

你应看到：自动生成 T-004；未开始由 1 变 2，其他统计仍为 1。

3. 筛选并制造一次无效输入

筛选未开始，再清空任务名称提交。

你应看到：列表只显示匹配行；空标题出现错误且不会增加记录。

4. 刷新并验证

刷新页面后运行 npm run check:10。

你应看到：恢复三条虚构样本；输出包含 add、filter、3 counts、blank title rejected。

参考完成态：本地实跑记录

• 浏览器实际新增 T-004，页面快照显示 2／1／1。
• 空标题由核心逻辑拒绝。
• 刷新恢复三条样本；v1.0 checkpoint 哈希保持不变。

证据文件：checkpoints/chapter-10-v1.0/tracker-app/index.html。这些记录只证明虚构练习在本地按规则跑通，不代表网站已发布、现实用户已使用或作者已批准。

8. 三个真实坑

坑 1：把小工具扩成完整系统

字段和状态由输入卡冻结。若增加登录、同步、优先级或数据库，范围检查会拒绝这些未授权能力。

坑 2：读取现实数据

页面只能加载本地 records.json。代码扫描会拒绝外部请求、浏览器存储和不在练习包内的数据地址。

坑 3：页面能开却不能完成动作

检查直接调用核心函数验证新增、过滤、统计和空标题，不接受“有按钮、有文字”作为功能完成。

这三个坑都由练习材料、代码或检查实际暴露，不是提醒语。

先看信号，再做补救

识别信号：页面出现需求卡外字段、发起网络请求、刷新后保留练习记录，或空标题也能入表，说明 v1.0 边界被突破。补救动作：回到字段卡，只保留五个字段、三个状态和内存态；删除工作副本，从只读 checkpoint 重新复制并逐项复演新增、筛选、计数和拒绝。

补救后仍不能让本章检查因正确原因通过，就按第 10 节停止并回退；不要手改日志或复制参考完成态绕过。

9. 复选框验收

• □页面只显示五个约定字段。
• □有效记录可新增，空标题被拒绝。
• □三个状态均可筛选且计数正确。
• □刷新后恢复虚构样本并有内存态提示。
• □npm run check:10 通过。

每一项都要靠打开文件或完成动作后再勾选；不要只凭 Codex 报告的 PASS。

10. 停止、回退与交接

一旦需要联网、读取现实记录、增加需求卡外字段或引入安装依赖，就停止。回退为删除 workbench/tracker-app/ 的本章输出并从输入卡重建。交给第 11 章的是 v1.0 文件、npm run check:10 结果和只读 checkpoint；不要直接在 checkpoint 上修改。

停止条件：页面尝试联网或持久化、字段超出需求卡、核心行为不一致、或 checkpoint 被改动。

回退动作：删除练习副本 workbench/tracker-app/，从只读 v1.0 checkpoint 重新复制。

交接文件：只读 v1.0 checkpoint、工作副本和本章通过结果；第 11 章必须先让新需求在旧版上失败。

CHAPTER 11 · 公开候选

接手不是先改代码。你会先让“待确认必须独立统计和筛选”在 v1.0 上确定失败，把直接退出码写入 red.log；再只改状态列表、页面选项、统计卡和布局，得到可回退的 v1.1。

打开第 11 章练习入口。完整任务位于练习包内 tasks/chapter-11.md；网站只提供下载与阅读，不会替你执行本地文件。

1. 起点

记录页 v1.0 已通过旧检查。新需求只增加“待确认”状态，并要求它独立统计，不计入“进行中”。

先理解问题

没有 RED 的 GREEN 只能说明某段代码当前没报错，不能说明新测试抓住了需求缺口。这里用同一探针打旧版和新版，让失败原因、最小差异与回归边界都能被第三方复查。

2. 只读输入

• checkpoints/chapter-10-v1.0/tracker-app/
• inputs/chapter-11/change-card.md
• 第 10 章行为基线和通过记录

建议阅读顺序

先读变更卡和第 10 章行为基线，再读探针要验证什么；只有确认“待确认不受支持”是预期失败，才打开工作副本准备修改。

3. 唯一写入位置

只修改 workbench/tracker-app/，并把证据写入 workbench/chapter-11/。checkpoint 永远只读。

写入位置是本章的安全边界。Codex 可以创建目录，但不能扩大到 inputs、checkpoint 或别章输出。

4. 本章唯一成果

交付记录页 v1.1，以及 change-card.md、red.log、green.log、regression.md、rollback.md。

成果必须能打开、能回查、能由本章检查验证。只有一句“已经完成”不算交付。

5. 可复制给 Codex 的任务

先读 inputs/chapter-11/change-card.md 和第 10 章基线。不要先修改代码：先用 scripts/run-change-test.mjs 在只读 v1.0 checkpoint 上运行新需求测试，必须因不支持“待确认”而失败，并把命令、直接退出码和失败原因写入 workbench/chapter-11/red.log。`run-change-test.mjs` 是外层命令封装器；日志中的 `COMMAND` 会记录它实际调用的底层探针，所以两行命令不同是预期，不是证据错位。确认 checkpoint 哈希未变后，只在 workbench/tracker-app 修改状态集合、表单选项、筛选和统计，增加独立“待确认”计数。不要改字段或无关样式。旧版合同必须用 `node checks/chapter-10.mjs checkpoints/chapter-10-v1.0` 对只读 checkpoint 运行；不要在已经升级为 v1.1 的 workbench 上执行默认 `npm run check:10`。workbench 中的 v1.1 和四状态回归由 `npm run check:11` 验证。把 GREEN 与回归结果写入对应文件。

把代码块整段复制，不要拆掉输入范围、停止条件和检查命令。Codex 的总结不能代替产出文件。

6. 你必须亲手完成

先打开 red.log，判断它是否真的因“待确认不受支持”失败，而不是路径或语法错误。GREEN 后在页面新增一条“待确认”，确认该卡只进入待确认统计；再筛选“进行中”，确认它没有混入。

人工动作为什么不能省

你要亲手判断 red.log 是否因正确原因退出 1。GREEN 后，在 v1.1 新增“确认下一轮维护频率／待确认”，筛选待确认只见 T-004，并确认它没有混入进行中。

7. 你应该看到

• RED 的直接退出码为 1，错误明确指向未支持的新状态。
• v1.0 checkpoint 前后哈希一致。
• GREEN 后有四个独立状态计数。
• 第 10 章的新增、三种旧筛选和空标题检查仍通过。
• node checks/chapter-10.mjs checkpoints/chapter-10-v1.0 退出 0；workbench 的 v1.1 由 check:11 退出 0 证明。

跟着做：从输入到可观察结果

1. 得到正确 RED

运行 node scripts/run-change-test.mjs --expect-red checkpoints/chapter-10-v1.0/tracker-app/app-core.mjs workbench/chapter-11/red.log。这是外层命令封装器；red.log 的 COMMAND 记录它实际调用的底层探针，两行不同是预期。

你应看到：red.log 写有 UNSUPPORTED_STATUS: 待确认 与直接退出码 1。

2. 检查最小修改

比较 v1.0 与 v1.1，只应涉及状态集合、HTML 选项和统计卡、统计布局、README。

你应看到：字段、数据方式和无关界面没有被重构。

3. 用同一探针变绿

阅读 green.log，并在浏览器新增待确认记录。

你应看到：直接退出码 0，四种状态各为 1。

4. 回归与回退

筛选待确认和进行中，运行 npm run check:11，再读 rollback.md。

你应看到：旧三状态、自动 ID、空标题均通过，checkpoint 哈希不变。

参考完成态：本地实跑记录

• red.log 保留旧版直接退出码 1，没有被 GREEN 覆盖。
• green.log 记录直接退出码 0。
• 浏览器中四状态各为 1，筛选待确认只显示 T-004。

证据文件：completed-example/chapter-11/red.log。这些记录只证明虚构练习在本地按规则跑通，不代表网站已发布、现实用户已使用或作者已批准。

8. 三个真实坑

坑 1：没读基线就改

新测试若没有先在 v1.0 上失败，就无法证明它能抓住需求缺口。检查要求精确的 RED 原因和 checkpoint 哈希。

坑 2：顺手重构无关部分

允许差异只涉及状态集合、选项、筛选和统计。检查器会验证 checkpoint 未变和 v1.1 行为，但不会自动判断所有无关重构；你必须亲手比较文件清单与差异。字段、数据方式或大段样式一旦超出变更卡，就停止并从只读 checkpoint 重建工作副本。

坑 3：把 v1.0 检查指向 v1.1

默认 check:10 的目标是 workbench，但第 11 章完成后那里已经是四状态 v1.1，直接运行会预期退出 1。旧版合同要明确指向只读 checkpoint；旧行为在 v1.1 上是否仍成立，则由 check:11 的回归探针判断。

这三个坑都由练习材料、代码或检查实际暴露，不是提醒语。

先看信号，再做补救

识别信号：RED 是路径或语法错误、文件差异扩出状态相关逻辑，或旧版检查被指向 v1.1，说明测试顺序或比较对象错了。补救动作：保留日志，恢复工作副本到只读 v1.0；先让同一需求探针因 UNSUPPORTED_STATUS 变红，再只改状态集合、选项、筛选和统计，并人工核对差异清单。

补救后仍不能让本章检查因正确原因通过，就按第 10 节停止并回退；不要手改日志或复制参考完成态绕过。

9. 复选框验收

• □RED 在未改 checkpoint 上因正确原因出现。
• □v1.0 checkpoint 哈希未变。
• □v1.1 的待确认独立计数正确。
• □第 10 章全部旧行为仍通过。
• □旧版合同检查明确指向 checkpoints/chapter-10-v1.0，没有把 v1.1 的预期差异误报为回归失败。
• □npm run check:11 通过。

每一项都要靠打开文件或完成动作后再勾选；不要只凭 Codex 报告的 PASS。

10. 停止、回退与交接

RED 因路径、语法或缺文件失败时停止，不进入修改；差异超出变更卡时也停止。回退按 rollback.md 用 v1.0 checkpoint 重建工作副本。交给第 12 章的是 v1.1、RED/GREEN 和回归结论；第 12 章只读接收，不继续改记录页。

停止条件：RED 原因不是新需求缺失、修改扩到变更卡外、旧行为回归失败、或 checkpoint 哈希变化。

回退动作：移走 v1.1 工作副本，从只读 v1.0 checkpoint 重建；保留 RED/GREEN 和失败现场。

交接文件：v1.1、red.log、green.log、regression.md、rollback.md；第 12 章只读接收，不继续改记录页。

CHAPTER 12 · 公开候选

安全批处理的目标不是把数量跑满，而是尽早判断规则是否可靠。你会冻结 20 份输入，只选择 S-01 至 S-05，得到三种不同异常，然后根据 20% 质量门停止扩张。

打开第 12 章练习入口。完整任务位于练习包内 tasks/chapter-12.md；网站只提供下载与阅读，不会替你执行本地文件。

1. 起点

你收到 20 份格式不完全一致的虚构学习条目。目标不是追求“全量跑完”，而是先用五份样本看清异常，再决定是否扩大。

先理解问题

一次处理 20 份看起来省时间，规则一旦错误却会放大 20 次。S-02 缺日期、S-04 使用非法状态、S-05 标签重复；它们让异常保留、质量门和停止决定成为真实操作。

2. 只读输入

• inputs/chapter-12/S-01.md 至 S-20.md
• inputs/chapter-12/expected-outcomes.json
• 第 11 章 v1.1 与回归结论

建议阅读顺序

先看 20 个文件是否都存在，再读 expected-outcomes 中的固定五样本与阈值；不要先挑看起来最干净的五份。

3. 唯一写入位置

只写 workbench/batch-output/。

写入位置是本章的安全边界。Codex 可以创建目录，但不能扩大到 inputs、checkpoint 或别章输出。

4. 本章唯一成果

交付 sample-selection.md、results.csv、exceptions.md、quality-gate.json 和 decision.md。

成果必须能打开、能回查、能由本章检查验证。只有一句“已经完成”不算交付。

5. 可复制给 Codex 的任务

只读取 inputs/chapter-12。先根据明确的覆盖规则选择五份样本，把 ID 与选择理由写入 workbench/batch-output/sample-selection.md；没有这份文件不得运行处理。用 scripts/run-batch.mjs 只处理五份样本，把每份输入的结果写入 results.csv，把缺字段、日期异常、状态不明或重复标签原样记入 exceptions.md，不修写输入。根据固定阈值生成 quality-gate.json，再让 decision.md 用实际计数决定扩大或停止。运行前后比较输入哈希，最后运行 npm run check:12。

把代码块整段复制，不要拆掉输入范围、停止条件和检查命令。Codex 的总结不能代替产出文件。

6. 你必须亲手完成

在运行前确认五份样本同时覆盖正常、缺字段和状态异常；运行后打开一条成功项和每类异常的原文件，判断结果是否忠实；最后亲手选择“扩大”或“停止”，并在 decision.md 写出依据。

人工动作为什么不能省

你要亲手打开 S-02、S-04、S-05，对照异常清单；再用纸笔算 3 ÷ 5 = 0.6，并与 0.2 阈值比较。脚本给数字，扩大或停止仍是你的判断。

7. 你应该看到

• 结果表正好覆盖五个样本 ID，没有偷偷处理其余十五份。
• 预置异常留在 exceptions.md，不是从结果中消失。
• 质量门使用实际错误率和固定阈值给出允许或阻止。
• 输入哈希在处理前后完全一致。

跟着做：从输入到可观察结果

1. 冻结全量，选定小样本

运行输入检查，并在 sample-selection.md 固定 S-01 至 S-05。

你应看到：五个 ID 在运行前就确定，其余 15 份明确不处理。

2. 运行受控批处理

执行 node scripts/run-batch.mjs workbench/batch-output/sample-selection.md workbench/batch-output。

你应看到：结果表恰有五行；成功和异常行都保留。

3. 核对三类异常

回到 S-02、S-04、S-05 原文。

你应看到：分别对应缺日期、状态不在允许值、标签重复；不是处理器编造。

4. 执行质量门

比较 0.6 与 0.2，阅读决定，运行 npm run check:12。

你应看到：输出 STOP；S-06 至 S-20 不进入结果，输入哈希不变。

参考完成态：本地实跑记录

• results.csv 恰有 S-01 至 S-05 五行。
• exceptions.md 恰有三项。
• 质量门为 5／3／0.6／0.2／false，检查输出 CH12_PASS。

证据文件：completed-example/batch-output/results.csv。这些记录只证明虚构练习在本地按规则跑通，不代表网站已发布、现实用户已使用或作者已批准。

8. 三个真实坑

坑 1：跳过样本直接全量

运行器要求 sample-selection.md 恰有五个不重复 ID；数量不等于五个时会拒绝开始。异常覆盖则由随后运行的 npm run check:12 对照固定样本核验。

坑 2：吞掉异常

固定结果表给每个样本一行，异常还必须进入单独清单。缺一行或把异常当成功都会与独立预期表冲突。

坑 3：改写原始输入

输入中有容易“顺手修好”的日期和状态。完整性检查会比较二十份文件的前后哈希，任何修写都会失败。

这三个坑都由练习材料、代码或检查实际暴露，不是提醒语。

先看信号，再做补救

识别信号：样本不是预先固定的 S-01 至 S-05、exceptions.md 少了异常，或 decision 写成扩大，说明你在挑结果或吞错误。补救动作：只清空 workbench/batch-output/，恢复固定样本，重新运行并逐份对照 S-02、S-04、S-05；60% 仍高于 20% 时必须保持 STOP。

补救后仍不能让本章检查因正确原因通过，就按第 10 节停止并回退；不要手改日志或复制参考完成态绕过。

9. 复选框验收

• □五份样本在运行前已选定并写明理由。
• □每个样本在 results.csv 中正好一行。
• □所有预置异常都出现在 exceptions.md。
• □决定与质量门的实际计数一致。
• □npm run check:12 和输入完整性检查均通过。

每一项都要靠打开文件或完成动作后再勾选；不要只凭 Codex 报告的 PASS。

10. 停止、回退与交接

样本没有覆盖异常、输入哈希变化、异常被吞掉或质量门阻止时，停止扩大范围。回退只清空 workbench/batch-output/ 后重新选择样本。交给第 13 章的是 results.csv、exceptions.md、decision.md 和允许范围规则。

停止条件：异常率超过阈值、异常不能回到输入、结果丢行、或脚本开始处理 S-06 至 S-20。

回退动作：只清空 workbench/batch-output/ 后重跑同一五份样本，不改输入或换样本追求更好数字。

交接文件：results.csv、exceptions.md、quality-gate.json、decision.md 与允许范围规则。

CHAPTER 13 · 公开候选

“结果不对”不是诊断。你会保留修复前摘要，让范围守卫指出 B-17，写出已知与仍未知，再只改选择范围；修复后的摘要除去 B-17 那一行外必须逐字相同。

打开第 13 章练习入口。完整任务位于练习包内 tasks/chapter-13.md；网站只提供下载与阅读，不会替你执行本地文件。

1. 起点

批处理摘要中出现了范围外材料 B-17。你知道“它不该出现”，但还不知道哪一步让它进入结果。

先理解问题

最危险的排查方式是先删异常，再写一个听起来合理的根因。B-17 输入必须保留，before 必须保留，同一守卫必须先红后绿；只有这样才能说“范围过滤”被证实。

2. 只读输入

• inputs/chapter-13/allowed-scope.json
• inputs/chapter-13/B-17.md
• inputs/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、修复说明与证据决定。

CHAPTER 14 · 公开候选

多角色协作不是把同一任务复制三遍。你会按交付物拆成盘点、起草、审查三条单写路径；审查只能记录发现，不能改草稿；建议 A 与 B 都要留到人工决定。

打开第 14 章练习入口。完整任务位于练习包内 tasks/chapter-14.md；网站只提供下载与阅读，不会替你执行本地文件。

1. 起点

你要把前章成果整理成训练包，需要盘点、起草和审查三种不同工作。两份虚构建议互相冲突，不能靠角色“投票”自动决定。

先理解问题

协作失控往往不是模型不够强，而是两个角色同时写一份文件，或审查者直接把草稿改成自己的版本。本章用目录、唯一交付物和前后哈希，把职责边界变成可检查事实。

2. 只读输入

• inputs/chapter-14/master-task.md
• inputs/chapter-14/role-inventory.md
• inputs/chapter-14/role-draft.md
• inputs/chapter-14/role-review.md
• inputs/chapter-14/conflict-a.md
• inputs/chapter-14/conflict-b.md
• 第 8—13 章已验收成果

建议阅读顺序

先读总任务，再读三张角色卡，最后并排读 conflict-a 与 conflict-b。不要在角色输出前决定哪个建议“更好”。

3. 唯一写入位置

• 盘点只写 workbench/collaboration/inventory/
• 起草只写 workbench/collaboration/draft/
• 审查只写 workbench/collaboration/review/
• 你只写 workbench/collaboration/human-decision/
• 角色边界账本写 workbench/collaboration/role-boundaries.json
• 总交接写 workbench/collaboration/handoff.md

写入位置是本章的安全边界。Codex 可以创建目录，但不能扩大到 inputs、checkpoint 或别章输出。

4. 本章唯一成果

得到四份隔离结果：inventory/materials.md、draft/training-package.md、review/findings.md、human-decision/decision.md，以及 role-boundaries.json 和 handoff.md。

role-boundaries.json 不是额外业务内容，而是检查器读取的边界账本。它必须记录三角色各自的 writableDirectory 与 delivery、草稿审查前后的 draftHashBeforeReview / draftHashAfterReview，以及两份冲突原文的 conflictSourceHashes。这些值都从本轮实际目录和 SHA-256 计算得到，不手填占位值。

成果必须能打开、能回查、能由本章检查验证。只有一句“已经完成”不算交付。

5. 可复制给 Codex 的任务

读取 inputs/chapter-14 的总任务和三张角色卡，按交付物而不是工具名称执行三步协作。盘点角色只写 inventory/materials.md；起草角色只读盘点和已确认事实，只写 draft/training-package.md；审查角色只读前两份结果，只写 review/findings.md，不得改草稿。完整保留 conflict-a.md 与 conflict-b.md 的冲突。审查前后分别计算草稿 SHA-256，并把三角色目录/交付物、两个草稿哈希和两份冲突原文哈希写入 collaboration/role-boundaries.json；字段名使用 writableDirectory、delivery、draftHashBeforeReview、draftHashAfterReview、conflictSourceHashes。不要替人工选择，也不要用角色票数决定。三份角色输出和边界账本完成后，只核对目录、交付物和哈希并停下等待我决定；此时决定与交接尚未完成，不要运行全量 check:14。等我在 human-decision/decision.md 记录采用、退回或暂停后，生成 handoff.md，再运行 npm run check:14。

把代码块整段复制，不要拆掉输入范围、停止条件和检查命令。Codex 的总结不能代替产出文件。

6. 你必须亲手完成

阅读盘点、草案、审查意见和两份冲突建议。亲自选择“采用 A”“采用 B”“退回补材料”或“暂停”，在 human-decision/decision.md 写明依据、未采用或未决项和下一步，再让 Codex 生成交接。检查器接受这四种人工决定，不替你预设答案；若选择“退回补材料”或“暂停”，本章可以验收，但连续实战必须停在这里，不能假装已经获准进入第 15 章。

人工动作为什么不能省

你要亲手选择采用 A、采用 B、退回补材料或暂停，并写依据、未采用项和下一步。参考完成态的“采用 B”只是虚构人工步骤示例，不能复制成你的决定。

7. 你应该看到

• 三个角色各有且仅有一个输出目录。
• 草案没有被审查者直接覆盖。
• role-boundaries.json 中审查前后草稿哈希相同，两份冲突源哈希都能回到只读输入。
• 两份冲突建议都保留原文和证据位置。
• 最终选择只出现在你的人工决定记录中。

跟着做：从输入到可观察结果

1. 按交付物拆角色

抄出盘点、起草、审查各自唯一目录和文件。

你应看到：三条写入路径没有交集。

2. 顺序执行

把第 5 节任务整段交给 Codex，要求它按盘点、起草、审查顺序写入三个隔离目录。

你应看到：三个角色各产出一份文件，role-boundaries.json 记录实际路径。

3. 证明审查未改稿

比较 draftHashBeforeReview 与 draftHashAfterReview。

你应看到：两个哈希完全相等；审查只写 findings。

4. 保留冲突并人工决定

在 findings 中找 A/B 两条建议，亲手写决定，再运行 npm run check:14。

你应看到：角色输出没有 FINAL_CHOICE，最终选择只有 human-decision 一处真源。

参考完成态：本地实跑记录

• 三个角色目录互不重叠，每个只有一份交付物。
• 审查前后草稿哈希相同。
• 参考决定明确标为虚构示例，不代表作者已经审核。

证据文件：completed-example/collaboration/role-boundaries.json。这些记录只证明虚构练习在本地按规则跑通，不代表网站已发布、现实用户已使用或作者已批准。

8. 三个真实坑

坑 1：按工具名而不是交付物分工

角色卡检查的是读写目录和唯一交付物；“让三个 AI 都完善内容”会因为共享写入而失败。

坑 2：多个角色共写一份文件

检查会比较角色允许目录和实际变更。审查者直接改草稿或盘点者补写决定都会越界。

坑 3：用 AI 投票替代人工裁决

两份建议故意冲突且没有预设多数。没有 human-decision/decision.md 时，章节不能通过；任何自动票数都不是决定依据。

这三个坑都由练习材料、代码或检查实际暴露，不是提醒语。

先看信号，再做补救

识别信号：两个角色写同一路径、审查前后草稿哈希变化，或角色输出出现 FINAL_CHOICE，说明职责边界已经失控。补救动作：只移走越界角色自己的目录，保留前序交付与冲突输入，按盘点→起草→审查重跑；最终选择仍由人写入唯一决定文件。

补救后仍不能让本章检查因正确原因通过，就按第 10 节停止并回退；不要手改日志或复制参考完成态绕过。

9. 复选框验收

• □盘点、草案、审查各自只写唯一目录。
• □审查意见有证据位置且未改草稿。
• □role-boundaries.json 已记录角色边界、草稿前后哈希和两份冲突源哈希。
• □两份冲突建议完整保留。
• □我已亲手记录决定、理由与下一步。
• □如果我选择退回或暂停，已停止而没有进入第 15 章。
• □npm run check:14 通过。

每一项都要靠打开文件或完成动作后再勾选；不要只凭 Codex 报告的 PASS。

10. 停止、回退与交接

出现共享写入、冲突被覆盖、审查直接改稿或没有人工决定时停止。回退只重建越界角色的目录，保留冲突和审计记录。交给第 15 章的是 handoff.md 和人工明确采用的成果；被退回或暂停的内容不得进入最终工作台。

停止条件：出现共享写入、审查改稿、冲突被覆盖、角色自动选择、或人工决定没有依据。

回退动作：只重建越界角色自己的目录，保留前序交付、冲突输入和审计记录。

交接文件：collaboration/handoff.md 与 human-decision/decision.md；第 15 章只接收人工采用的结果。

CHAPTER 15 · 公开候选

最后一章不是写一份“项目完成说明”。你会打开统一入口的真实链接，用 A-13 只改四个白名单业务文件，运行受影响检查，实际回退到更新前哈希，再确定性地重新应用。

打开第 15 章练习入口。完整任务位于练习包内 tasks/chapter-15.md；网站只提供下载与阅读，不会替你执行本地文件。

1. 起点

第 8—14 章已经交出并验收了各自成果。现在要把人工采用的结果接成一个入口，并用新增材料 A-13 完成一次可回退的小更新。

先理解问题

可维护的判断标准不是目录看起来完整，而是下一位能从入口开始，知道读什么、写哪里、失败时如何恢复。A-13 更新把这件事变成一次真实演练：范围受限、检查可跑、回退等值、重放确定。

2. 只读输入

• 第 8—14 章通过检查的成果和人工决定
• inputs/chapter-15/A-13.md
• inputs/chapter-15/update-request.md

任何未验收、被退回或仍待确认的前章内容都不进入工作台。

建议阅读顺序

先读第 14 章 handoff 和人工决定，再读 A-13 与 update-request；最后才打开更新脚本。入口只接收已验收且被采用的成果。

3. 唯一写入位置

只写 workbench/handoff/，以及更新请求明确允许的 workbench/library/ 和 workbench/content-package/ 副本。不得改 inputs/、checkpoint 或前章证据。

写入位置是本章的安全边界。Codex 可以创建目录，但不能扩大到 inputs、checkpoint 或别章输出。

4. 本章唯一成果

交付 index.html、maintenance-log.md、test-record.md、rollback-point.json、rollback-proof.json、HANDOFF.md 和 maintenance-checklist.md，并证明 A-13 可更新、可检查、可回退。

rollback-proof.json 必须在实际回退并逐文件比对之后生成：顶层记录 exactRestoration: true 和回退命令的 directExitCode: 0；files 为四个白名单业务文件逐一记录 actualSha256 与 exact: true。其中 actualSha256 必须等于 rollback-point.json 中同一文件的 beforeSha256，不能只写一句“已经恢复”。

成果必须能打开、能回查、能由本章检查验证。只有一句“已经完成”不算交付。

5. 可复制给 Codex 的任务

只整合第 8—14 章已通过检查且被人工采用的成果，在 workbench/handoff/index.html 建一个离线统一入口，逐项链接资料库、内容包、记录页、批处理、事件证据和协作决定。先运行 node scripts/apply-update.mjs workbench，记录允许文件的更新前哈希到 rollback-point.json，再按 inputs/chapter-15/update-request.md 把 A-13 作为一次最小更新加入获准的资料库和内容包副本，写 maintenance-log.md，运行受影响检查并写 test-record.md。执行 node scripts/rollback-update.mjs workbench；直接记录退出码，逐一计算四个白名单文件回退后的 SHA-256，与 beforeSha256 比较，并把 exactRestoration、directExitCode、每个文件的 actualSha256 和 exact 写入 rollback-proof.json。只有全部逐字节恢复，才运行 node scripts/apply-update.mjs workbench --reuse-rollback-point 重新应用经检查的更新。脚本也接受把 --reuse-rollback-point 放在目标目录之前，但不得省略或猜测其他参数。写清从哪里开始、读什么、改哪里、何时回退、何时停止的 HANDOFF.md 和维护清单。最后运行 npm run check:15。

把代码块整段复制，不要拆掉输入范围、停止条件和检查命令。Codex 的总结不能代替产出文件。

6. 你必须亲手完成

从统一入口依次打开六类前章成果；检查 A-13 在资料库与内容包中的表达一致；亲手执行一次回退并比较结果；最后按 HANDOFF.md 判断下一位是否能在不询问背景的情况下开始一次小更新。

人工动作为什么不能省

你要亲手打开资料、交付、记录、批处理、事故、协作、维护七类入口；再实际运行一次 rollback-update 和重新 apply。文档写“可回退”而没有真实回退，不算完成。

7. 你应该看到

• 入口的本地链接全部可达，没有链接到未采用成果。
• A-13 只改变授权的资料库、内容包和维护记录。
• 记录页 v1.1 和其他未受影响检查仍通过。
• 回退后哈希与更新前完全一致，重新应用后检查再次通过。
• rollback-proof.json 中四个 actualSha256 都等于对应的更新前哈希，且没有把未执行的回退写成成功。

跟着做：从输入到可观察结果

1. 建立统一入口

把第 5 节任务整段交给 Codex，只整合前章已通过检查且被人工采用的成果。

你应看到：handoff/index.html 有 17 个本地链接，未采用和待确认内容不进入主线。

2. 应用白名单更新

脚本先记录四个业务文件 before 哈希，再把 A-13 加入资料库和文字内容包。

你应看到：只有 index.csv、update-log.md、facts.md、one-page-summary.md 四个既有文件变化。

3. 实际回退与重放

运行 node scripts/rollback-update.mjs workbench，再运行 node scripts/apply-update.mjs workbench --reuse-rollback-point。

你应看到：回退逐字节等于 before；重放逐项等于第一次 after。

4. 全链检查与交接

运行 npm run check:15 和 npm run check:all，再读 HANDOFF 的五个问题。

你应看到：17 个链接可达，记录页回归绿色，输出 LAB_ALL_PASS: inputs + Chapters 8–15。

参考完成态：本地实跑记录

• 17 个相对链接全部解析到现有文件。
• A-13 只改变四个白名单业务文件，回退后逐字节恢复。
• 重放哈希与第一次一致，全练习检查通过；最终 ZIP 仍需从零独立复演并核对哈希。

证据文件：completed-example/handoff/index.html。这些记录只证明虚构练习在本地按规则跑通，不代表网站已发布、现实用户已使用或作者已批准。

8. 三个真实坑

坑 1：一次塞入所有扩展

更新请求只授权 A-13 和三类文件。增加新模块、字段或协作角色会被变更范围清单拦住。

坑 2：打开离线入口后就写“已经发布”

识别信号是：你只在本机打开了 handoff/index.html，却在交接里出现“发布完成、已经外发、现实用户可用”。立刻删掉这类越界结论，把状态恢复为“虚构、离线、练习”；真正发布必须另行获得作者批准并完成部署验收。

坑 3：交接责任与下一步不清

HANDOFF.md 必须回答开始、读取、写入、回退和停止五个问题。只有文件列表、没有责任边界不能通过。

这三个坑都由练习材料、代码或检查实际暴露，不是提醒语。

先看信号，再做补救

识别信号：有死链、超过四个既有业务文件变化、rollback 后实际哈希不等于 before，或离线练习被写成线上发布，说明维护闭环失真。补救动作：立即停止并保留当前哈希；只有当前文件仍匹配 after 时才运行确定性回退，逐文件比对成功后再重新应用，不能强制覆盖。

补救后仍不能让本章检查因正确原因通过，就按第 10 节停止并回退；不要手改日志或复制参考完成态绕过。

9. 复选框验收

• □统一入口的全部本地链接可达。
• □A-13 只影响授权文件且前后表达一致。
• □受影响检查和记录页回归均通过。
• □回退精确恢复，重新应用后再次通过。
• □rollback-proof.json 记录了真实退出码与四文件逐字节比对结果。
• □npm run check:15 通过。

每一项都要靠打开文件或完成动作后再勾选；不要只凭 Codex 报告的 PASS。

10. 停止、回退与交接

入口有死链、更新越界、资料库与内容包不一致、回归失败或回退不等值时停止。使用 rollback-point.json 和 scripts/rollback-update.mjs 恢复，不靠手工猜。最终交接文件是 workbench/handoff/HANDOFF.md；本地检查或 AI 复演不能被写成另一位人类已经完成复演。

停止条件：入口死链、白名单外改动、A-13 两处不一致、回归失败、回退不等值、或出现现实发布声明。

回退动作：只有当前文件匹配 after 哈希时运行回退；不匹配时先保留现场并停止，不能强制覆盖。

交接文件：workbench/handoff/HANDOFF.md、index.html、维护与测试记录、回退点和回退证明。