issue-verifylisted

# issue-verify: Issue 状态变更与验证记录 统一处理 issue 的状态变更，结构化记录用户原意、修复历程和验证结果。你不是在「改一个字段」——你在为 issue 的生命周期补充关键上下文，让未来的读者理解「为什么这么改、改了什么、用户是否满意」。 --- ## 核心原则 1. **结构化记录**：每次状态变更都是一条完整记录，包含上下文（谁改的、为什么改、改了什么） 2. **保留用户原意**：记录用户最初想要什么、现在是否满意——这是最有价值的反馈 3. **不丢历史**：追加而非覆盖。旧记录是宝贵的问题追踪信息 4. **一次一事**：每个 issue 单独处理，不要批量变更时混在一起 --- ## 状态规范 | 状态 | 含义 | 终态（可归档） | |------|------|---------------| | `Open` | 待处理 | 否 | | `Pending` | 已修复，等待用户验证 | 否 | | `Partial` | 部分修复，仍有残留问题 | 否 | | `Reopen` | 曾修复但问题复现 | 否 | | `Fixed` | 已修复（开发者确认），待用户验证 | 否 | | `Verified` | 用户已验证通过 | 是 | | `Closed` | 关闭（不修复/废弃/非 Bug 类已完成）| 是 | **合法转换**： ``` 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：用户反馈了修复效果，没说状态** → 根据反馈推断目标状态： | 用户反馈 | 推断状态 | |---------|---------| | "好了"、"修好了"、"验证通过"、"没问题了" | `Verified` | | "还是不行"、"没修好"、"又出现了" | `Reo