RainLib 全栈开发工作流
用户通过 /dev-workflow 启动。可选传入 iteration-id 恢复已有迭代。
启动流程
- 调用
history-managerskill 执行init（确保docs/history.json存在）。 - 若传入
$ARGUMENTS且为有效 iteration id，恢复该迭代；否则调用history-manager执行new-iter创建新迭代。 - 调用
history-manager执行status读取当前迭代的state，从该阶段继续执行。
阶段执行顺序
| 顺序 | 阶段 | Skill | 执行方式 | 说明 |
|---|---|---|---|---|
| 1 | 需求分析 | requirements-analysis | inline | 与用户对话，梳理功能点 |
| 2 | 技术选型 | technology-selection | inline | 询问全栈/前端/后端，选定技术栈 |
| 3 | 技术评审 | technical-review | fork/Explore | 评审架构可行性、API 契约、风险项 |
| 4 | 程序设计 | program-design | inline | 设计模块分层、流程、工程目录 |
| 5 | 任务拆分 | task-breakdown | fork/Plan | 将设计拆为可管理的开发单元 |
| 6 | 单元测试 | unit-testing | fork | 按任务单元设计测试用例 |
| 7 | 代码开发 | code-development | inline | 按测试驱动实现代码 |
| 8 | 自我验证 | self-verification | fork/Explore | 运行测试、集成验证、质量自检 |
执行规则
- Inline 阶段必须与用户对话：需求分析、技术选型、程序设计、代码开发（阶段 1、2、4、7）均在主对话中执行。所有决策点以结构化选项呈现（编号选项，让用户选择而非自由输入），等待用户选择后再产出/推进，不得跳过用户直接生成结果。每轮不超过 3 个问题。
- 状态恢复：每个阶段开始前，调用
history-manager的get-phase和check-file检查该阶段是否已完成。若已完成则跳过，直接进入下一阶段。 - 状态写入：每个阶段完成后，调用
history-manager的set-phase <phase> <phase_id>更新 history。 - 阶段 id 生成：使用
{阶段缩写}-001格式（如req-001、ts-001）。同一迭代内递增。 - 自我验证失败：若 self-verification 报告有未通过项，回退到 code-development 修复后重新验证。
- 产出位置：所有阶段文档写入
docs/{current_iteration_id}/。