# 第 11 章任务卡：接手并修改 v1.0 ## 1. 起点 记录页 v1.0 已通过旧检查。新需求只增加“待确认”状态，并要求它独立统计，不计入“进行中”。 ## 2. 只读输入 - `checkpoints/chapter-10-v1.0/tracker-app/` - `inputs/chapter-11/change-card.md` - 第 10 章行为基线和通过记录 ## 3. 唯一写入位置 只修改 `workbench/tracker-app/`，并把证据写入 `workbench/chapter-11/`。checkpoint 永远只读。 ## 4. 本章唯一成果 交付记录页 v1.1，以及 `change-card.md`、`red.log`、`green.log`、`regression.md`、`rollback.md`。 ## 5. 可复制给 Codex 的任务 ```text 先读 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 与回归结果写入对应文件。 ``` ## 6. 你必须亲手完成 先打开 `red.log`，判断它是否真的因“待确认不受支持”失败，而不是路径或语法错误。GREEN 后在页面新增一条“待确认”，确认该卡只进入待确认统计；再筛选“进行中”，确认它没有混入。 ## 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 证明。 ## 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` 的回归探针判断。 ## 9. 复选框验收 - [ ] RED 在未改 checkpoint 上因正确原因出现。 - [ ] v1.0 checkpoint 哈希未变。 - [ ] v1.1 的待确认独立计数正确。 - [ ] 第 10 章全部旧行为仍通过。 - [ ] 旧版合同检查明确指向 `checkpoints/chapter-10-v1.0`，没有把 v1.1 的预期差异误报为回归失败。 - [ ] `npm run check:11` 通过。 ## 10. 停止、回退与交接 RED 因路径、语法或缺文件失败时停止，不进入修改；差异超出变更卡时也停止。回退按 `rollback.md` 用 v1.0 checkpoint 重建工作副本。交给第 12 章的是 v1.1、RED/GREEN 和回归结论；第 12 章只读接收，不继续改记录页。