issue-verify

name: issue-verify description: > Issue 状态变更与验证记录。当用户说"验证一下这个 issue"、"issue 验证通过了"、 "这个问题修好了"、"还没修好"、"Reopen 这个 issue"、"部分修复了"、 "关掉这个 issue"、"把 issue 状态改成 xxx"时立即触发。 也适用于 fix-issue 完成后需要记录修复结果、用户回归测试后反馈结果、 或任何需要变更 issue 状态的场景。 即使没有明确说"验证"，只要用户在反馈 issue 的修复效果就应触发。

issue-verify: Issue 状态变更与验证记录

统一处理 issue 的状态变更，结构化记录用户原意、修复历程和验证结果。你不是在「改一个字段」——你在为 issue 的生命周期补充关键上下文，让未来的读者理解「为什么这么改、改了什么、用户是否满意」。

核心原则

1. 结构化记录：每次状态变更都是一条完整记录，包含上下文（谁改的、为什么改、改了什么）
2. 保留用户原意：记录用户最初想要什么、现在是否满意——这是最有价值的反馈
3. 不丢历史：追加而非覆盖。旧记录是宝贵的问题追踪信息
4. 一次一事：每个 issue 单独处理，不要批量变更时混在一起

状态规范

合法转换：

Open → Pending | Fixed | Partial | Closed
Pending → Verified | Reopen | Partial | Closed
Fixed → Verified | Reopen | Partial | Closed
Partial → Fixed | Pending | Reopen | Closed
Reopen → Fixed | Pending | Closed
Verified → Reopen（问题回归）
Closed → Reopen（重新打开）

工作流程

阶段一：定位 Issue

1. 用户通过 $ARGUMENTS 提供引用——可能是文件名、关键词、标题片段、或 spec/issues/ 中的路径
2. 如果用户给了明确路径（如 spec/issues/2026-06-01-xxx.md）→ 直接 Read
3. 如果用户给了模糊引用（如"那个 streaming 的 issue"、"昨天的 issue"）→ 用 Grep 在 spec/issues/ 中搜索匹配
4. 如果找不到 → 在 spec/archive-issues/ 中也搜索一次（可能已归档）
5. 读取 issue 文件，提取当前状态和内容

找不到时：告知用户未找到匹配 issue，建议用 /issue-create 先创建。不要猜测。

阶段二：确认变更意图

基于用户输入和当前状态，确认要做什么：

场景 A：用户明确说了目标状态（如"验证通过"、"改成 Reopen"） → 直接确认意图，跳到阶段三

场景 B：用户反馈了修复效果，没说状态 → 根据反馈推断目标状态：

用 AskUserQuestion 确认推断：

"我理解你想把这个 issue 标记为 [推断状态]，对吗？

• A) 是的
• B) 不对，我想改成其他状态"

阶段三：收集验证详情

根据目标状态，收集不同粒度的信息：

→ Verified（验证通过）

问用户：

1. 验证通过的具体表现是什么？（用户期望的效果是否达到）
2. 有没有额外发现？（修复是否引入了新问题）

→ Reopen（验证失败）

问用户：

1. 当前表现是什么？（与原始 issue 描述是否一致、有无新症状）
2. 是否在特定条件下才复现？

→ Partial（部分修复）

问用户：

1. 哪部分修好了？
2. 哪部分还有问题？
3. 残留问题的表现是什么？

→ Closed（关闭）

问用户：

1. 关闭原因？（不修复 / 已废弃 / 不是 bug / 已有其他方案）

→ Pending（等待验证）

问用户：

1. 修复了什么？（概要）
2. 涉及哪些文件/commit？
3. 用户原意是什么？（用户最初想要什么效果）

→ Fixed（开发者标记已修复）

问用户：

1. 修复了什么？（概要）
2. 涉及哪些文件/commit？
3. 用户原意是什么？（用户最初想要什么效果）

阶段四：更新 Issue 文档

按以下步骤更新 issue 文件：

步骤 1：更新状态头部

将 **状态**：旧状态 改为 **状态**：新状态。

如果新状态是 Reopen，在头部追加 **Reopen 日期**：YYYY-MM-DD（如有多个 Reopen，用逗号追加日期）。

步骤 2：追加状态变更记录

在「状态变更记录」表格末尾追加一行：

| YYYY-MM-DD | 旧状态 | 新状态 | [操作人] | [简述原因] |

如果 issue 没有「状态变更记录」段落（旧格式 issue），在文档末尾（## 涉及文件 之后、或文档最后）追加该段落，并将历史转换补齐为：

## 状态变更记录

| 日期 | 从 | 到 | 操作人 | 说明 |
|------|-----|-----|--------|------|
| 创建日期 | — | Open | [创建者] | 创建 |
| YYYY-MM-DD | Open | [中间状态] | ... | ...（根据文档内容推断历史） |
| YYYY-MM-DD | 旧状态 | 新状态 | [当前操作人] | [本次变更原因] |

步骤 3：追加修复记录（仅 Fixed 状态变更时）

如果是 → Fixed 或 → Verified（隐含经过 Fixed），在「修复记录」段落追加：

### 修复 #N（YYYY-MM-DD）

- **操作人**：[agent / 用户名]
- **用户原意**：[用户希望达到什么效果——用用户自己的话概括]
- **修复内容**：[做了什么改动]
- **涉及 commit**：[commit hash，如有]
- **验证状态**：[待验证 / 已验证 / 验证失败]

其中 #N 为递增序号（从文档中已有条目数 +1）。用户原意从 issue 的「问题描述」或用户的当前反馈中提取。

如果是 → Verified 且该 issue 已有修复记录但验证状态仍为「待验证」，则更新最近一条修复记录的验证状态为「已验证」，而不是新建记录。

如果 issue 没有「修复记录」段落（旧格式 issue），在「状态变更记录」之后追加该段落。

步骤 4：追加验证详情（仅 Verified / Reopen / Partial 时）

在「症状详情」段落末尾追加验证反馈子段：

### 验证 #N（YYYY-MM-DD）—— [结果]

[用户反馈的详情：期望效果是否达到、当前表现、残留问题等]

阶段五：输出摘要

✅ Issue 状态已更新 → spec/issues/YYYY-MM-DD-<slug>.md

旧状态 → 新状态
变更原因：[一句话]
更新内容：
  - 状态变更记录 +1
  - 修复记录 +N（如适用）
  - 验证详情（如适用）

常见场景示例

场景 1：fix-issue 完成后标记 Fixed

用户说：streaming 的那个 issue 修好了

Agent 执行：

1. Grep 搜索 spec/issues/ 找到匹配 issue
2. 读取，当前状态 Open
3. 推断目标：Fixed
4. 收集修复信息：修了什么、涉及文件、用户原意
5. 更新：Open → Fixed，追加修复记录 #1，状态变更记录 +1

场景 2：用户验证通过

用户说：刚才那个 issue 验证通过了，没问题

Agent 执行：

1. 找到 issue，当前状态 Fixed
2. 确认转换：Fixed → Verified
3. 更新最近修复记录的验证状态为「已验证」
4. 追加状态变更记录 + 验证详情

场景 3：用户反馈没修好

用户说：那个 popup 的 bug 还在，我试了一下还是会崩

Agent 执行：

1. 找到 issue，当前状态 Fixed
2. 确认转换：Fixed → Reopen
3. 收集复现信息：用户看到的症状
4. 追加验证详情（验证失败 + 当前表现）
5. 追加状态变更记录

场景 4：批量验证（多个 issue）

用户说：把那几个 hook 相关的 issue 都标记为 Fixed

Agent 对每个 issue 独立执行阶段三至五，输出汇总报告。每个 issue 的修复记录分别追加，不合并。

注意事项

• 不要删除或覆盖已有内容——所有更新都是追加
• 旧格式 issue（没有「状态变更记录」/「修复记录」段落）→ 在末尾补建段落
• 归档 issue（spec/archive-issues/ 中的）→ 拒绝变更，建议创建新 issue 关联
• 状态已经是目标状态 → 提示用户"已经是该状态"，但仍可追加验证详情