标准开发流程

主要适用于两种场景：

已有需求分析结果或研发计划：以已有文档为输入，自动走完编码→测试→审查→回归的完整闭环
极简功能或 bugfix：不需要复杂的需求或规划文档，以会话背景沟通为基础直接开始，跳过文档规划中不适用的部分

适用时机

用户说"按标准流程开发" / "走完整流程" / "开始开发这个功能"
需求分析（/go-backend-requirement-analysis）或技术设计（/go-backend-technical-design）已完成，进入实施阶段
极简功能或 bugfix，无需正式设计文档，直接用会话描述驱动开发

调用方式

/go-backend-dev-workflow [docs/feature-dir]

提供目录名：使用该目录作为功能文档目录
不提供目录名：在 docs/ 下基于功能名自动创建子目录

Phase 0：文档目录规划

极简功能 / bugfix 跳过此 Phase：如果当前任务是单文件修改、参数调整、简单 bugfix 等无需专属文档集的情况，跳过 Phase 0，直接进入 Phase 1，以会话背景为实施依据。

读取项目文件放置规范

读取项目根目录的 tasks/todo.md，定位 ## 参考文档 小节。

小节存在：继续下一步
小节不存在（首次使用或 todo.md 中没有该小节）：在文件末尾追加空的 ## 参考文档 小节，再继续

确定功能文档目录

如果调用时提供了目录名：

将提供的目录名和 ## 参考文档 小节中已记录的目录名均转换为相对项目根目录的路径后再比较：

一致：沿用已有规划，确认文档路径列表
不一致或小节为空：清空 ## 参考文档 小节，按新目录名重新生成（见下方模板）

如果调用时未提供目录名：

根据当前功能名（从会话上下文或需求分析/技术设计文档标题提取）在 docs/ 下确定子目录名，格式：docs/{feature-name}。

生成参考文档清单

先扫描已解析的目录路径是否已有同类文件，再决定填写哪条文件名：

# resolved_dir 为上一步确定的实际目录路径（相对或绝对）
ls "$resolved_dir"/ 2>/dev/null

对每类文档，按 glob 模式匹配目录中的文件名，确定写入 todo.md 的条目：

对每类文档，按以下逻辑确定路径：

类型	已有匹配文件？	操作
架构文档（`arch-*`）	是	记录已有文件路径，不新建
操作手册（`ops-*.md`）	是	记录已有文件路径，不新建
操作脚本（`ops-*.sh`）	是	记录已有文件路径，不新建
测试记录（`report-*`）	是	记录已有文件路径，不新建
评审记录（`review-*`）	是	记录已有文件路径，不新建
任意类型	否	按命名规范生成新路径（文件在后续阶段按需创建）

将结果写入 tasks/todo.md 的 ## 参考文档 小节。目录名填绝对路径或相对项目根目录的路径，文件名只填文件名（均位于该目录下，不重复写路径）：

## 参考文档

- 当前功能文档目录：docs/{feature-name}
- 当前功能架构文档：arch-{feature-name}-{yyyy-mm-dd}.md
- 当前功能操作手册：ops-{feature-name}-{yyyy-mm-dd}.md
- 当前功能操作脚本：ops-{feature-name}-{yyyy-mm-dd}.sh
- 当前功能测试记录文档：report-{feature-name}-{yyyy-mm-dd}.md
- 当前功能评审记录文档：review-{feature-name}-{yyyy-mm-dd}.md

创建目录（文档在后续阶段按需创建，不需要全部预先创建）：

mkdir -p docs/{feature-name}

确认后向用户展示路径清单，等待用户确认或调整，再进入 Phase 1。

Phase 1：按设计实施

实施依据（按优先级）

会话中有需求分析或技术设计结果：直接以当前会话中的文档内容为准
提供了文档路径：读取对应的需求分析或架构文档（arch-*.md）
极简功能或 bugfix：以会话中的问题描述和沟通背景为基础，不需要正式设计文档

极简 / bugfix 路径的作用域确认：在动手前，用一句话向用户确认改动范围（如"将修改 X 文件的 Y 函数，不涉及其他模块"），等用户确认后再开始。

实施原则

有需求映射表（Req# → 组件）时，逐 Req# 实施，完成后在 tasks/todo.md 更新状态
极简功能或 bugfix 无需映射表，按会话描述直接实施，改动范围最小化
遇到可能导致产品无法使用的不合理因素时，立即停止并等待人工确认，描述具体问题和影响范围，不得自行假设绕过

Phase 2：操作手册和脚本补充

实施完成后，为新增功能补充操作手册和配套脚本。

写入操作手册

路径以 tasks/todo.md 参考文档清单中记录的为准（可能是已有文件，也可能是新建路径）。在该文件中追加新功能的测试用例，不覆盖已有内容：

## 测试用例

### 正常路径

| TC# | 前置条件 | 操作 | 预期结果 |
|-----|---------|------|---------|

### 边界/异常路径

| TC# | 前置条件 | 操作 | 预期结果 |
|-----|---------|------|---------|

### 回归用例（历史功能）

| TC# | 覆盖场景 | 验证点 |
|-----|---------|-------|

写入操作脚本

路径同上，以参考文档清单为准，追加新用例到已有脚本末尾，不覆盖已有函数：

每个测试用例对应一个可独立执行的函数或命令块
脚本头部包含环境变量说明和前置依赖检查
包含回归测试用例，覆盖受影响的历史功能路径

Phase 3：代码自查

对本次实施的所有变更文件进行自查，将所有发现记录到参考文档清单中的评审记录文档（tasks/todo.md → 当前功能评审记录文档）。

自查要点（通用）：

逻辑正确性：边界条件、空值/null 检查、错误处理
并发安全：共享状态的访问控制、异步操作的生命周期
资源管理：连接/文件/句柄是否正确关闭，定时器/任务是否可取消
接口契约：是否与设计文档的 API 规范一致
测试覆盖：新增代码是否有对应的测试用例

评审文档结构：

# 评审记录

## 自查（Phase 3）

| # | 文件:行号 | 问题描述 | 严重级别 | 状态 |
|---|---------|---------|---------|------|
| 1 | pkg/foo/bar.go:42 | nil 未检查 | High | ✅ 已修复 |

自查发现的问题逐一核实，确认真实存在后立即修复，并在表格中标记状态。

Phase 4：操作脚本执行

运行参考文档清单中的操作脚本（tasks/todo.md → 当前功能操作脚本），覆盖新功能和回归路径。

执行要求

逐一运行每个测试用例
记录每个用例的详细执行过程到参考文档清单中的测试记录文档（tasks/todo.md → 当前功能测试记录文档）：

# 测试记录

## TC-{id}: {用例名称}

**执行命令：**
```bash
# 具体命令

返回结果：

# 实际输出

分析： 简要说明结果是否符合预期，如有异常说明根因 状态： ✅ 通过 / ❌ 失败（已修复）


- 对所有失败用例，逐一核实后修复真实存在的问题（区分测试脚本问题和代码问题）
- 修复后重新运行受影响的用例，直到全部通过

---

## Phase 5：专项审查

根据项目语言/技术栈选择对应的审查工具：

- **Go 项目**：调用 `/go-backend-reviewer` 进行专项审查
- **其他语言项目**：跳过本 Phase，或根据项目实际情况选用合适的审查手段

> 判断依据：项目根目录存在 `go.mod` 则为 Go 项目。

将所有反馈追加到参考文档清单中的**评审记录文档**：

```markdown
## 专项审查（Phase 5）

| # | 文件:行号 | 审查反馈 | 严重级别 | 状态 |
|---|---------|---------|---------|------|

逐一核实审查反馈，确认真实存在的问题后修复，并在表格中标记状态。

Phase 6：回归测试

修复 Phase 5 审查问题后，重新运行参考文档清单中的操作脚本（tasks/todo.md → 当前功能操作脚本），覆盖所有回归用例。

全部通过：在参考文档清单中的测试记录文档末尾追加"回归测试：✅ 全部通过"
有失败：定位根因，修复，再次回归，直到全部通过

完成标准

有需求分析 / 研发计划的功能：

tasks/todo.md 参考文档小节已更新，路径清单已确认
代码实现覆盖全部 Req#
操作手册和操作脚本已编写（ops- 前缀）
评审文档记录了自查 + 专项审查的所有发现及修复状态
测试记录文档包含每个用例的执行过程和结论
回归测试全部通过

极简功能 / bugfix：

代码改动最小化，仅触及必要部分
评审文档（或会话中）记录了自查发现及修复状态
测试记录包含验证命令、返回结果和分析
回归测试全部通过