congde/codexfde/spec-acceptance-review

Spec 验收审查

判断一份候选 Spec 是否已经清楚到可以提交负责人确认。重点不是把文档写得更长，而是找出会导致不同实现、无法验收或越过授权边界的内容。

使用边界

• 本技能审查合同内容，不替负责人作业务决定。
• 解析器通过只表示结构正确，不表示业务含义正确。
• Spec 审查通过只表示需求可以作为后续工作的依据，不表示功能已经实现或验收。
• 用户只要求审查时保持只读；用户要求修订时，只生成最小修订候选，并保留原稿、待确认项和修改理由。

开始前取得材料

尽量取得以下材料；缺失时继续完成能够核对的部分，并明确写出证据缺口：

• 原始诉求及提出者或来源；
• 候选 Spec 的路径和版本；
• 与需求直接相关的项目规则、代码事实或业务记录；
• 已作出的人员决定及其确认状态。

如果材料中的事实互相冲突，不自行选择一个版本，也不把模型建议写成人员决定。

按四步审查

1. 检查结构

先读取目标项目对 Spec 的格式要求。CodexFDE L03 当前要求六个二级章节按以下顺序出现：

来源 → 目标 → 非目标 → 约束 → 验收用例 → 完成定义

检查缺失、空内容、重复、乱序、未知章节和未闭合代码围栏。若项目已有真实解析入口，就实际运行并记录命令、输出和退出码；没有运行时，只能写“静态检查”。

本步只给出“结构有效／结构无效／未实际运行”，不判断业务正确性。

2. 检查来源、范围和业务含义

逐条追问会改变实现或验收的内容来自哪里：原始诉求、仓库事实、人员决定，还是尚未确认的建议。来源不明的关键规则必须交给负责人决定。

重点检查：

• 谁在什么情境下使用结果，要据此作什么决定；
• 业务对象、状态、时间点、单位、公式、行粒度和排序是否明确；
• 目标、非目标、约束和验收用例是否互相一致；
• 是否加入了原需求没有授权的界面、通知、审批或技术方案；
• 实现方式是否被误写成业务要求。

遇到“快速、正确、适当、支持异常、格式同上、尽量”等表述时，尝试构造两种都符合原句、结果却不同的实现。若能构造出来，就说明还需要补充可观察边界。

需要收紧一条行为时，可以改写为：

在<初始状态>下，当<事件>发生时，<角色或系统>必须产生<可观察结果>。

3. 检查验收是否能推翻错误实现

每项关键行为至少说明：

1. 给定什么初始状态和数据；
2. 当发生什么操作或事件；
3. 那么能够观察到什么结果；
4. 并且不变什么数据、文件或状态。

至少检查一个正常情境，以及一个与本需求直接相关的失败或边界情境。公式要换一组数据复算；排序要打乱输入；写文件失败要检查旧文件和半成品；只读操作要检查权威状态未改变。

“测试通过”“没有报错”或“函数被调用”不能替代具体的预期结果。

4. 给出审查结论

使用以下三个结论之一：

• 退回修改：存在相反理解、已知规则冲突、无法观察的验收条件或明显越界内容；
• 待负责人确认：主要内容已经清楚，但仍有会改变实现或验收的人员决定没有确认；
• 确认版可用：关键来源和人员决定有实际记录，范围与验收一致，没有尚未处理的关键问题。

“确认版可用”仍不能证明解析器已经接入工作台，也不能证明产品功能已经完成。

交接前可选检查

只有用户明确要求交接复验，或材料已经包含交接记录时，才检查以下内容：

• 负责人确认的 Spec 路径、版本和内容哈希；
• 实际解析的 Spec 路径、版本和内容哈希；
• 交接包提供的 Spec 路径、版本和内容哈希。

三者不一致时报告“版本不一致”；缺少证据时报告“证据不足”。此检查只判断交接的是否为同一份合同，不检查后续功能是否实现。

输出格式

按以下顺序返回：

1. 审查结论：退回修改、待负责人确认或确认版可用；
2. 依据：分别说明结构、业务含义和验收是否成立，以及使用了什么实际证据；
3. 关键发现：用表格列出“位置｜问题｜可能产生的错误结果｜需要谁决定｜建议”；
4. 下一步：列出最少且明确的处理动作。

只有用户要求修订时，才在最后附上最小修订候选。不要擅自补齐业务决定，也不要把候选稿标成已确认版。