name: 故障分类 description: 为CLI待办系统进行故障分类和分类发现

参数

[发现列表或来源类型]

首先将/model设置为Haiku
然后读取todos/目录中的所有待处理待办事项

在此逐一呈现所有发现、决策或问题，以便进行分类。目标是检查每个项目，并决定是否将其添加到CLI待办系统中。

重要：在分类过程中不要编写任何代码！

此命令用于：

分类代码审查发现
处理安全审计结果
审查性能分析
处理任何其他需要跟踪的分类发现

工作流

步骤1：呈现每个发现

对于每个发现，按以下格式呈现：

---
问题 #X: [简要标题]

严重性：🔴 P1（关键） / 🟡 P2（重要） / 🔵 P3（可有可无）

类别：[安全/性能/架构/错误/功能/等]

描述：
[问题或改进的详细解释]

位置：[文件路径:行号]

问题场景：
[逐步说明错误或可能发生的情况]

建议解决方案：
[如何修复]

预估工作量：[小（<2小时）/中（2-8小时）/大（>8小时）]

---
您想将此添加到待办列表吗？
1. 是 - 创建待办文件
2. 下一个 - 跳过此项
3. 自定义 - 在创建前修改

步骤2：处理用户决策

当用户说“是”时：

更新现有待办文件（如果存在）或创建新文件名：

如果待办已存在（来自代码审查）：
- 将文件从 {id}-pending-{priority}-{desc}.md 重命名为 {id}-ready-{priority}-{desc}.md
- 更新YAML frontmatter：status: pending → status: ready
- 保持issue_id、priority和description不变
如果创建新待办：
```
{next_id}-ready-{priority}-{简要描述}.md
```
优先级映射：
- 🔴 P1（关键） → p1
- 🟡 P2（重要） → p2
- 🔵 P3（可有可无） → p3
示例：042-ready-p1-transaction-boundaries.md

更新YAML frontmatter：

---
status: ready # 重要：从“pending”更改为“ready”
priority: p1 # 或p2、p3，基于严重性
issue_id: "042"
tags: [category, relevant-tags]
dependencies: []
---

填充或更新文件：

# [问题标题]

## 问题陈述
[来自发现的描述]

## 发现
- [关键发现]
- 位置：[文件路径:行号]
- [场景详情]

## 建议解决方案

### 选项1：[主要解决方案]
- **优点**：[益处]
- **缺点**：[如果有]
- **工作量**：[小/中/大]
- **风险**：[低/中/高]

## 推荐操作
[在分类过程中填写 - 具体行动计划]

## 技术细节
- **受影响的文件**：[列出文件]
- **相关组件**：[受影响的组件]
- **数据库变更**：[是/否 - 如果是则描述]

## 资源
- 原始发现：[此问题的来源]
- 相关问题：[如果有]

## 验收标准
- [ ] [具体成功标准]
- [ ] 测试通过
- [ ] 代码已审查

## 工作日志

### {日期} - 批准工作
**由：** Claude故障分类系统
**操作：**
- 在分类会话中批准了问题
- 状态从pending更改为ready
- 准备被拾取和工作

**学习点：**
- [上下文和见解]

## 笔记
来源：{日期}的分类会话

确认批准： “✅ 批准：{新文件名}（问题 #{issue_id}） - 状态：ready → 准备开始工作”

当用户说“下一个”时：

删除待办文件 - 从todos/目录中移除，因为它不相关
跳到下一项
跟踪跳过的项以进行摘要

当用户说“自定义”时：

询问修改内容（优先级、描述、细节）
更新信息
呈现修订版本
再次询问：是/下一个/自定义

步骤3：继续直到所有处理完毕

逐一处理所有项目
使用TodoWrite进行可见性跟踪
不要等待项之间的批准 - 继续前进

步骤4：最终摘要

处理完所有项目后：

## 分类完成

**总项数：**[X] **已批准待办（ready）：**[Y] **已跳过：**[Z]

### 已批准待办（准备工作）：

- `042-ready-p1-transaction-boundaries.md` - 交易边界问题
- `043-ready-p2-cache-optimization.md` - 缓存性能改进 ...

### 跳过项（已删除）：

- 项 #5：[原因] - 从todos/中移除
- 项 #12：[原因] - 从todos/中移除

### 所做更改摘要：

在分类过程中，发生了以下状态更新：

- **Pending → Ready：** 文件名和frontmatter更新以反映批准状态
- **已删除：** 跳过发现的待办文件从todos/目录中移除
- 每个批准的文件现在在YAML frontmatter中都有 `status: ready`

### 下一步：

1. 查看已批准待办准备工作：
   ```bash
   ls todos/*-ready-*.md
   ```

开始处理已批准项：

/resolve_todo_parallel  # 高效处理多个已批准项

或选择单个项处理
当您工作时，更新待办状态：
- Ready → In Progress（在您的本地上下文中）
- In Progress → Complete（重命名文件：ready → complete，更新frontmatter）


## 示例响应格式

问题 #5：多步操作缺少交易边界

严重性：🔴 P1（关键）

类别：数据完整性 / 安全

描述：GoogleOauthCallbacks concern中的google_oauth2_connected回调在没有交易保护的情况下执行多个数据库操作。如果任何步骤中途失败，数据库将处于不一致状态。

位置：app/controllers/concerns/google_oauth_callbacks.rb:13-50

问题场景：

User.update成功（电子邮件更改）
Account.save!失败（验证错误）
结果：用户更改了电子邮件但没有关联的Account
下一次登录尝试完全失败

无交易操作：

用户确认（第13行）
等待列表移除（第14行）
用户配置文件更新（第21-23行）
账户创建（第28-37行）
头像附件（第39-45行）
旅程创建（第47行）

建议解决方案：将所有操作包装在ApplicationRecord.transaction do … end块中

预估工作量：小（30分钟）

您想将此添加到待办列表吗？

是 - 创建待办文件
下一个 - 跳过此项
自定义 - 在创建前修改


## 重要实施细节

### 分类期间的状态转换

**当选择“是”时：**
1. 重命名文件：`{id}-pending-{priority}-{desc}.md` → `{id}-ready-{priority}-{desc}.md`
2. 更新YAML frontmatter：`status: pending` → `status: ready`
3. 在工作日志中添加分类批准条目
4. 确认：“✅ 批准：`{文件名}`（问题 #{issue_id}） - 状态：**ready**”

**当选择“下一个”时：**
1. 从todos/目录中删除待办文件
2. 跳到下一项
3. 系统中没有文件保留

### 进度跟踪

每次您将待办作为标题呈现时，包括：
- **进度：** X/Y完成（例如，“3/10完成”）
- **预估剩余时间：** 基于您的进度速度
- **节奏：** 监控每个发现的时间并相应调整预估

示例：

进度：3/10完成 | 预估时间：约2分钟剩余


### 分类期间不要编码

- ✅ 呈现发现
- ✅ 做出是/下一个/自定义决策
- ✅ 更新待办文件（重命名、frontmatter、工作日志）
- ❌ 不要实施修复或编写代码
- ❌ 不要添加详细实施细节
- ❌ 那是/resolve_todo_parallel阶段的工作

完成后给出这些选项

您接下来想做什么？

1. 运行/resolve_todo_parallel来解决待办
2. 提交待办
3. 什么都不做，去放松