用途
openspec-verify-change 用于在归档（archive）一个变更之前，验证代码实现是否与变更产物（specs、tasks、design）匹配，确认实现完整、正确且连贯。
输入与前置处理
- 可指定变更名称；若未提供，会尝试从对话上下文推断。
- 若名称模糊或存在歧义，必须提示用户从可用变更中选择，不得猜测或自动选择。
- 通过
openspec list --json获取可用变更，再用 AskUserQuestion 工具让用户选择。选择界面展示存在实现任务的变更（存在 tasks 产物），如可用则附带每个变更使用的 schema，未完成任务标记为 "(In Progress)"。
主要流程
- 用
openspec status --change "<name>" --json检查状态，解析 schemaName（如 "spec-driven"）以及存在哪些产物。 - 用
openspec instructions apply --change "<name>" --json获取变更目录与上下文文件，读取 contextFiles 中所有可用产物。 - 初始化校验报告结构，包含三个维度：完整性（跟踪任务与规格覆盖）、正确性（跟踪需求实现与场景覆盖）、一致性（跟踪设计遵循与模式一致性）；每个维度可有 CRITICAL、WARNING、SUGGESTION 级问题。
三个维度的校验
- 完整性：读取 tasks.md，解析
- [ ]与- [x]复选框，统计完成数与总数；未完成任务记 CRITICAL。对openspec/changes/<name>/specs/中的 delta specs，提取所有 "### Requirement:" 需求，搜索代码库判断是否已实现，疑似未实现记 CRITICAL。 - 正确性：将每个需求映射到代码实现证据（记录文件路径与行号范围），实现偏离规格意图时记 WARNING；对每个 "#### Scenario:" 场景检查代码是否处理、是否有测试覆盖，未覆盖记 WARNING。
- 一致性：若存在 design.md，提取关键决策（如 "Decision:"、"Approach:"、"Architecture:" 等章节）并核对实现，矛盾记 WARNING；若无 design.md 则跳过并注明。审查新代码在文件命名、目录结构、编码风格上与项目模式的一致性，显著偏离记 SUGGESTION。
输出格式
生成 Markdown 校验报告：
- 汇总表：维度 | 状态（如完整性 X/Y 任务、N 项需求；正确性 M/N 需求覆盖；一致性 遵循/问题）。
- 按优先级分组的 issue 列表：CRITICAL（归档前必须修复）、WARNING（应修复）、SUGGESTION（可选修复），每条附具体可执行建议。
- 代码引用格式为
file.ts:123。 - 最终评估：有 CRITICAL 时提示修复后再归档；仅有 WARNING 时提示可归档（附改进项）；全部通过时提示可归档。
判定原则与优雅降级
- 完整性侧重客观清单项；正确性可用关键词搜索、文件路径分析与合理推断，不要求完全确定；一致性只找明显矛盾，不苛求风格细节。
- 不确定时优先 SUGGESTION 而非 WARNING，优先 WARNING 而非 CRITICAL。
- 每条 issue 必须有具体建议，避免 "consider reviewing" 之类模糊表述。
- 产物不完整时降级：仅有 tasks.md 只校验任务完成；tasks+specs 校验完整性与正确性；产物齐全时三维全查。始终说明跳过了哪些检查及原因。