/x-verify-spec

name: x-verify-spec
description: |
  Gate ① 单 task 交付对账。开发完成后，核对 spec、req 承接范围、checklist 与 dev-report 的回指、覆盖、内容基线、执行证据及结论。输出对账通过、未完成或不通过；需求歧义列为待用户确认。不重跑测试，不做独立功能或技术验收。触发：x-dev 交付、用户提到 x-verify-spec 或要求 verify/复核 task。

x-verify-spec · Gate ① 交付对账

定位与边界

只核对单个 task 的交付记录是否闭合。spec 提供功能预期及用户已确认的关键业务约束，req 分配记录确定责任范围，开发记录提供执行结果。回指有效、测试全绿、对账通过都不等同独立行为验收。

不重跑测试、不审核断言充分性或实现架构、不改交付文档，不扫描或编排同级 task，不重新评审需求质量。

输入与来源

读取完整 dev-checklist.md、dev-report.md 及 checklist 指向的 spec.md；承接 C/用例时按设计指针读取 tech-design 的用例主定义与映射，仅用于交付对账。核对 spec 指针、task 目录、dev-report 的 task 指针是否对应同一交付；只检查对账所需结构，不假定 spec 已确认。

接受已有可定位记录，不要求新增固定字段或重写上游模板：

• 承接范围：req 交付中的 task→feat 分配、用户明确范围，或可读取的 req 分配基线。
• 内容基线与确认：已有用户确认依据、req 拆解及开发验证使用的版本/内容记录和可读取的历史内容。
• 执行证据：dev-report、已有测试报告、执行记录或人工记录中的验证位置、结果及来源回指。

记录采用的来源。当前任务行不能同时充当预期全集和实际集合；创建日期不能代替内容基线，开发者声明不能代替用户确认。缺资料先报告给来源负责方补取已有记录，继续检查不受影响的项目，不补造预期或批准。

旧项目无 C 定义时核对现有已确认场景/约束及既有编号或章节定位，不以缺 C 章节单独判失败、不强造 C。未确认提议只列待澄清，不作为既定验收标准；影响本轮范围时阻止整体通过。本 task 引用的设计/用例主定义缺失时，相应覆盖与证据映射标未核实，不因其他测试全绿豁免。

对账项

一次核查全部适用项，再汇总问题、待澄清项与待补资料。

1. **结构与唯一定位**：checklist、report、spec 可读取，spec 有标题、概述、feat 与场景结构；被引用场景有 GIVEN/WHEN/THEN。目标编号重复、结构残缺或指针矛盾时明确报告，不能含糊定位。

2. **spec 内容基线**：核对拆解、开发验证与当前相关 spec 的行为和编号。有差异时比较本 task 的场景、GIVEN/WHEN/THEN 与分配范围；同时比较相关 C 的原意、范围、可观察判据与确认来源，以及用例主定义的基线；纯措辞且行为、回指未变时记录依据，行为或编号变化须有重新对齐记录。编号仍存在不代表旧证据适用；缺确认来源、基线或可读旧内容时标“基线未核实”。

3. **完整场景回指**：按 `(feat编号, 场景编号)` 建立索引；既有 Scenario ID 则按原 ID 建索引，不强制迁移编号。完整解析整格，支持中英文逗号、多项及闭区间。`feat01 场景1, 场景2` 的后项继承本格最近明确的 feat；`feat01 场景1-3, feat02 场景2` 展开后逐项检查。首项不能省 feat，不跨行继承；倒序范围、缺成员、歧义或未解析残余不得通过。同场景可被多行引用，覆盖统计去重。

4. **本 task 覆盖**：从可核查的 req 分配建立应覆盖集合，取分配给本 task 的 feat 的全部场景；用户另有明确范围时依其记录，不自行缩小或扩大。与任务行实际回指对照，列出遗漏；范围外引用单列用途与依据，不据此要求本 task 交付他人的 feat。从已确认 spec 和设计主定义核对本 task 适用 C 及其全部用例与 req 分配，跨 task 的共享约束以明确分配核对；一个 C 可有多个测试，不能以一条绿灯代替全部用例或需求覆盖。缺承接记录时只报告已有回指有效性，标“范围与完整覆盖未核实”，不得反推全集后宣称全覆盖。

5. **None 与 D 回指**：场景列 None 须有可辨认的纯技术支撑理由及相应检查结果，不计入功能覆盖，也不豁免应覆盖场景。功能任务写 None 或理由不清时报告给 req 负责方，不以数量多单独判失败。任务含 D 编号时按已有设计指针或 spec 同目录设计核对存在性；没有 D 不强行补，仅核对引用，不做架构验收。

6. **每个预期结果的证据**：所有应覆盖场景与 C 约束/分配用例须有真实、可定位执行记录对应前提/触发及全部预期/禁止结果；一份记录可覆盖多项，但需明确对应关系。总绿灯、测试名称或文件存在不能替代映射。接受现有记录，不规定新格式；缺记录标“证据映射未核实”，明确少哪个结果，不审断言证明能力或代验 D 机制。记录已说明关键机制被替换、关键用例跳过、零测试或仅构建成功时，不可算作该约束的有效证据；机制是否实际落实交 x-verify-tech。核对有效红灯原因或如实记录的既有满足/人工等理由，不要求伪造 TDD。发现验收标准变化须追溯权威来源与重新确认/对齐记录，不能靠改报告取得通过。

7. **人工与高风险记录**：人工验证须有步骤、实际观察与执行结论，不能把缺自动测试自行解释为人工通过。风险为 `高:` 的行须能定位 smoke 或以上真实链路的方式与结果，只有汇总声明时标“已声明，具体证据未核实”。明确只有 unit 的记录不满足该行验证要求。

8. **影响树**：树与涉及文件列一一对应，标记仅 U/M/D；glob 按目录节点核对，保留 req 的简化及合并写法，不引入表外文件。

9. **状态与结论**：通过要求全部行 `[x] 🟢`、既有回归通过且记录一致。分别列执行失败、阻塞、未执行、缺证据及文档矛盾，不能以全绿抵消。已知失败在未决节逐行对应行号、摘要与已尝试动作；测试数、任务行数、场景数不得互相替代。

需求澄清与问题去向

• **需求歧义或需求来源无法确定**：列出具体 feat/场景、问题、对验收的影响及需要确认的行为，请用户确认，相关项标“待澄清”。继续其余检查，不猜预期、不擅改 spec、不自动调用 x-spec。
• **确定的机械问题或资料缺失**：路径拼错、结构缺项、编号悬空、分配记录缺失、None 理由或影响树问题，按来源报告给 req/spec/设计记录负责方；基线、执行证据、report 或状态问题报告给开发负责方。先补取已有记录，不把所有机械问题升级为用户产品决策；若仍无法确定权威需求，按上一条澄清。
• **已如实记录的执行失败**：报告给开发/修复负责方，明确这是已知失败，不误报为文档问题；阻塞和未执行分别说明原因。

一次列全问题与待补资料，不自动启动其他 skill 或 x-fix，不降低标准、不递增 fix-counter，不修改任何交付文件。

结论与回执

• **对账通过**：全部适用项可核查且一致，无失败、阻塞、未执行、待澄清或未核实项。只证明记录闭合。
• **对账未完成**：来源/证据缺失、待澄清、阻塞或尚未执行。列已核查事实和缺项，不给整体通过。
• **对账不通过**：发现确定的矛盾、悬空引用、覆盖遗漏、验证要求未满足或执行失败；同时列出尚未核实项，不因缺资料隐藏已知问题。
• 不适用须有具体依据；未覆盖、未执行和缺证据不能写成不适用。

不写报告文件，只输出回执与必要清单：

🛡️ Gate① 对账通过 · <task> · 行 N/N 🟢 · task 覆盖、spec 基线、证据映射已核实 · 影响树及结论一致
🛡️ Gate① 对账未完成 · <task> · 已核查：... · 待澄清/未核实/阻塞/未执行：... · 待补来源：...
🛡️ Gate① 对账不通过 · <task> · 问题 N 项 · 来源负责方：...

回执注明：本轮未重跑测试，非独立功能或技术验收。