核对表目录
核对表目录：从无上下文的清单推进到能拒绝缺证据结论的任务门禁，让每次勾选都有条件、证据和回归路径。
学习目标
- 能从任务类型和进入条件定位合适的核对表，而不是把一张清单用于所有问题。
- 能为每个条目写出判断条件、证据位置、拒绝理由和回归检查。
- 能区分“全部勾选”和“证据充分”，并通过故障与复位实验验证门禁是否有效。
为什么需要这一机制
核对表目录的价值不在于让勾选数量变大，而在于让任务进入正确的检查路径。一个没有上下文的清单会鼓励机械勾选；一个有门禁的目录会先确认任务类型，再规定逐项证据、责任人和拒绝条件。缺少证据的条目必须能阻止结论通过。
先避开三个清单误区
核心合同与操作术语
门禁可以写成：所有条目都必须同时满足 condition 和 evidence。↡决定使用哪组检查项的交付活动、风险类型和当前阶段定义问题；↡允许检查开始并规定输入、版本和责任人的前置事实防止清单被滥用。
↡按条目判断并为每项留下结果、证据和责任人的过程把抽象建议变成动作；↡能让别人定位结果的测试输出、变更记录、截图或审查链接让勾选可复查；↡说明为何拒绝通过以及修订后如何重新检查的记录使失败也成为流程的一部分。
目录节点逐项深读
核对表目录
核对表目录的工程任务是把构建任务映射到门禁。先写任务、输入、版本和检查目的，再从目录选表；每一项同时写状态、证据位置和责任人。一个没有证据的勾选必须拒绝，修复后从相同基线回归，而不是直接改成通过。
最小可重放实现
baseline = freeze(task, version, input)
checklist = locate_by_task_type(task)
for item in checklist:
result = evaluate(item.condition, baseline)
record(result, item.evidenceLocation, owner)
reject_if_missing_evidence()
reset()
assert replay(baseline) == baseline.trace正常轨迹验证全链路；边界轨迹改变任务类型或进入条件；故障轨迹注入没有证据的勾选；复位轨迹重新定位清单并回归。门禁的输出应包含通过、拒绝和下一步动作。
先预测，再操作证据实验
先预测任务类型、证据位置或拒绝条件改变后哪一个节点会先变化，再切换一个场景。组件显示的是清单门禁模型，不代表项目的自动批准。
核对表目录 · 证据实验
任务类型 → 进入条件 → 逐项核对 → 证据位置 → 拒绝与回归
固定版本、输入和观察窗口，只改变一个条件；先预测首个偏离，再用同一基线复位。
练习与答案
练习
问题 1：选择清单。 一个探索性原型准备转入发布，请写出任务类型、进入条件和三条必须有证据的检查项。
问题 2：拒绝无证据勾选。 团队已经勾完所有项目，但某一条“边界条件已验证”没有输出。门禁应如何处理？
问题 3：设计回归。 清单通过后接口版本改变，哪些条件必须重新固定？
术语表
名词解释
本章出现的专业名词，用大白话再讲一遍。
- 任务类型
- 决定采用哪一组检查项的交付活动和风险。
- 进入条件
- 允许检查开始的版本、输入、环境和责任人约束。
- 逐项核对
- 对每个条目给出判断、证据和责任人的过程。
- 证据位置
- 别人可以定位结果的输出、记录或审查链接。
- 拒绝与回归
- 缺证据时拒绝，通过修订后从同一基线重新检查。
本页小结
核对表目录把“勾选”变成有条件的门禁：先定位任务，再逐项判断，附上证据位置，缺证据就拒绝，修复后从同一基线回归。这样清单才是降低遗漏的工具，而不是制造完成率的装饰。