@zeyue0329/xiaoma-cli 1.0.41 → 1.0.42
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/.idea/workspace.xml +8 -2
- package/dist/agents/workflow-executor.txt +151 -1
- package/dist/teams/team-all.txt +151 -1
- package/package.json +6 -1
- package/tools/api-server.js +367 -0
- package/xiaoma-core/agents/workflow-executor.md +155 -1
- package/xiaoma-core/workflows/automated-requirements-development.yaml +739 -0
package/.idea/workspace.xml
CHANGED
|
@@ -4,7 +4,13 @@
|
|
|
4
4
|
<option name="autoReloadType" value="SELECTIVE" />
|
|
5
5
|
</component>
|
|
6
6
|
<component name="ChangeListManager">
|
|
7
|
-
<list default="true" id="4ca3d6ad-bc27-4e67-9acd-07dccd21dd95" name="Changes" comment="drop unchecked message"
|
|
7
|
+
<list default="true" id="4ca3d6ad-bc27-4e67-9acd-07dccd21dd95" name="Changes" comment="drop unchecked message">
|
|
8
|
+
<change beforePath="$PROJECT_DIR$/dist/agents/architect.txt" beforeDir="false" afterPath="$PROJECT_DIR$/dist/agents/architect.txt" afterDir="false" />
|
|
9
|
+
<change beforePath="$PROJECT_DIR$/dist/teams/team-all.txt" beforeDir="false" afterPath="$PROJECT_DIR$/dist/teams/team-all.txt" afterDir="false" />
|
|
10
|
+
<change beforePath="$PROJECT_DIR$/dist/teams/team-fullstack-with-database.txt" beforeDir="false" afterPath="$PROJECT_DIR$/dist/teams/team-fullstack-with-database.txt" afterDir="false" />
|
|
11
|
+
<change beforePath="$PROJECT_DIR$/dist/teams/team-fullstack.txt" beforeDir="false" afterPath="$PROJECT_DIR$/dist/teams/team-fullstack.txt" afterDir="false" />
|
|
12
|
+
<change beforePath="$PROJECT_DIR$/dist/teams/team-no-ui.txt" beforeDir="false" afterPath="$PROJECT_DIR$/dist/teams/team-no-ui.txt" afterDir="false" />
|
|
13
|
+
</list>
|
|
8
14
|
<option name="SHOW_DIALOG" value="false" />
|
|
9
15
|
<option name="HIGHLIGHT_CONFLICTS" value="true" />
|
|
10
16
|
<option name="HIGHLIGHT_NON_ACTIVE_CHANGELIST" value="false" />
|
|
@@ -67,7 +73,7 @@
|
|
|
67
73
|
<workItem from="1762494963355" duration="2769000" />
|
|
68
74
|
<workItem from="1762781553645" duration="3390000" />
|
|
69
75
|
<workItem from="1762933631198" duration="16000" />
|
|
70
|
-
<workItem from="1763045898895" duration="
|
|
76
|
+
<workItem from="1763045898895" duration="4599000" />
|
|
71
77
|
</task>
|
|
72
78
|
<task id="LOCAL-00001" summary="drop unchecked message">
|
|
73
79
|
<option name="closed" value="true" />
|
|
@@ -83,6 +83,7 @@ commands:
|
|
|
83
83
|
- help: 显示以下命令的编号列表以供选择
|
|
84
84
|
- run-requirements-analysis: 🔥 自动化需求分析工作流(完全自动执行,不暂停)- 加载 automated-requirements-analysis.yaml 并连续执行所有 6 个步骤,从 req.txt 到最终的架构设计文档,全程自动化无需人工干预
|
|
85
85
|
- run-story-development: 🔥 自动化用户故事开发工作流(完全自动执行,不暂停)- 加载 automated-story-development.yaml 并循环执行所有用户故事的 SM→PO→Dev→QA 完整开发周期,全程自动化无需人工干预
|
|
86
|
+
- run-requirements-development: '🔥🔥🔥 端到端全自动化工作流(完全自动执行,不暂停)- 加载 automated-requirements-development.yaml 并连续执行从需求分析到用户故事开发完成的完整流程 (阶段1: 需求分析 6步 + 阶段2: 用户故事开发循环), 实现从 req.txt 到所有代码完成的端到端自动化'
|
|
86
87
|
- status: 显示当前工作流执行状态和进度
|
|
87
88
|
- validate-prerequisites: 验证工作流执行的前置条件
|
|
88
89
|
- resume-workflow: 从上次中断的位置恢复工作流执行(同样会自动连续执行剩余步骤)
|
|
@@ -92,6 +93,7 @@ dependencies:
|
|
|
92
93
|
workflows:
|
|
93
94
|
- automated-requirements-analysis.yaml
|
|
94
95
|
- automated-story-development.yaml
|
|
96
|
+
- automated-requirements-development.yaml
|
|
95
97
|
```
|
|
96
98
|
|
|
97
99
|
---
|
|
@@ -205,7 +207,77 @@ workflow_stages:
|
|
|
205
207
|
|
|
206
208
|
---
|
|
207
209
|
|
|
208
|
-
### 2.
|
|
210
|
+
### 2. 🔥🔥🔥 端到端全自动化工作流 (新增)
|
|
211
|
+
|
|
212
|
+
**命令**: `*run-requirements-development`
|
|
213
|
+
|
|
214
|
+
**功能**: 执行从需求分析到用户故事开发完成的完整端到端自动化流程
|
|
215
|
+
|
|
216
|
+
**工作流文件**: `xiaoma-core/workflows/automated-requirements-development.yaml`
|
|
217
|
+
|
|
218
|
+
**核心价值**:
|
|
219
|
+
- ✅ **一键启动**: 只需执行一个命令,完成从 req.txt 到所有代码的端到端开发
|
|
220
|
+
- ✅ **无缝衔接**: 需求分析阶段自动衔接用户故事开发阶段,无需人工干预
|
|
221
|
+
- ✅ **全程自动化**: 整合了两个子工作流的所有优势,实现完整的自动化流程
|
|
222
|
+
- ✅ **质量保证**: 两个阶段的所有质量门控都会自动执行
|
|
223
|
+
|
|
224
|
+
**执行流程**:
|
|
225
|
+
|
|
226
|
+
```yaml
|
|
227
|
+
端到端工作流结构:
|
|
228
|
+
|
|
229
|
+
阶段 1: 需求分析阶段 (1.5-2.5小时)
|
|
230
|
+
├─ 步骤 0/6: 前置环境验证
|
|
231
|
+
├─ 步骤 1/6: Analyst 需求分析
|
|
232
|
+
├─ 步骤 2/6: Architect 架构分析
|
|
233
|
+
├─ 步骤 3/6: PM 创建 PRD
|
|
234
|
+
├─ 步骤 4/6: PM 拆分史诗
|
|
235
|
+
├─ 步骤 5/6: Architect 架构设计
|
|
236
|
+
└─ 步骤 6/6: 生成需求分析报告
|
|
237
|
+
↓
|
|
238
|
+
阶段间验证(无缝衔接)
|
|
239
|
+
↓
|
|
240
|
+
阶段 2: 用户故事开发阶段 (40-70分钟/故事)
|
|
241
|
+
循环执行(直到所有用户故事完成):
|
|
242
|
+
├─ 步骤 1: SM 创建用户故事
|
|
243
|
+
├─ 步骤 1.5: 快速构建验证
|
|
244
|
+
├─ 步骤 2: PO 验证故事
|
|
245
|
+
├─ 步骤 2.5: 预开发构建检查
|
|
246
|
+
├─ 步骤 3: Dev 开发故事
|
|
247
|
+
├─ 步骤 4: QA 测试验证
|
|
248
|
+
└─ 步骤 5: 质量门控决策
|
|
249
|
+
↓
|
|
250
|
+
生成端到端完成报告
|
|
251
|
+
```
|
|
252
|
+
|
|
253
|
+
**总耗时**:
|
|
254
|
+
- 阶段 1(需求分析): 约 1.5-2.5 小时
|
|
255
|
+
- 阶段 2(用户故事开发): 约 40-70 分钟 × 用户故事数量
|
|
256
|
+
- **典型小型项目(5-10个故事)**: 4-8 小时
|
|
257
|
+
- **典型中型项目(10-20个故事)**: 8-16 小时
|
|
258
|
+
|
|
259
|
+
**成功标准**:
|
|
260
|
+
|
|
261
|
+
阶段 1 成功标准:
|
|
262
|
+
- ✅ 所有需求分析文档生成完成
|
|
263
|
+
- ✅ PRD 和 Epic 文档创建完成
|
|
264
|
+
- ✅ 架构设计和数据库脚本生成完成
|
|
265
|
+
- ✅ 所有质量门控通过
|
|
266
|
+
|
|
267
|
+
阶段 2 成功标准:
|
|
268
|
+
- ✅ 所有用户故事状态为 Done
|
|
269
|
+
- ✅ 所有测试通过(覆盖率 ≥80%)
|
|
270
|
+
- ✅ 所有 QA 质量门控通过
|
|
271
|
+
- ✅ 代码质量达标
|
|
272
|
+
|
|
273
|
+
整体成功标准:
|
|
274
|
+
- ✅ 两个阶段全部完成
|
|
275
|
+
- ✅ 完整的文档和代码生成
|
|
276
|
+
- ✅ 准备就绪进入集成测试和部署阶段
|
|
277
|
+
|
|
278
|
+
---
|
|
279
|
+
|
|
280
|
+
### 3. 自动化用户故事开发工作流
|
|
209
281
|
|
|
210
282
|
**命令**: `*run-story-development`
|
|
211
283
|
|
|
@@ -391,6 +463,84 @@ quality_gates:
|
|
|
391
463
|
|
|
392
464
|
## 📊 使用示例
|
|
393
465
|
|
|
466
|
+
### 🔥🔥🔥 执行端到端全自动化工作流(推荐)
|
|
467
|
+
|
|
468
|
+
```bash
|
|
469
|
+
# 1. 准备工作
|
|
470
|
+
# 确保 docs/req.txt 文件存在且包含 PM 提供的需求
|
|
471
|
+
|
|
472
|
+
# 2. 激活工作流执行器
|
|
473
|
+
/workflow-executor
|
|
474
|
+
|
|
475
|
+
# 3. 执行端到端全自动化工作流(完全自动化,一键到底)
|
|
476
|
+
*run-requirements-development
|
|
477
|
+
|
|
478
|
+
# ⚡ 核心优势:一个命令完成从需求分析到代码实现的全部工作!
|
|
479
|
+
# ⚠️ 重要提示:工作流执行器会自动连续执行两个阶段的所有步骤,不会在中间暂停
|
|
480
|
+
# 如果工作流在某个步骤停止,说明遇到了错误或质量门控失败,请查看错误信息
|
|
481
|
+
|
|
482
|
+
# 工作流执行器将自动完成以下所有工作(典型小项目 4-8 小时):
|
|
483
|
+
#
|
|
484
|
+
# 【阶段 1: 需求分析】(约 1.5-2.5 小时)
|
|
485
|
+
# ✓ 步骤 0/6: 前置环境验证
|
|
486
|
+
# ✓ 步骤 1/6: Analyst 需求分析 → 生成需求分析报告
|
|
487
|
+
# ✓ 步骤 2/6: Architect 架构分析 → 生成架构分析报告
|
|
488
|
+
# ✓ 步骤 3/6: PM 创建 PRD → 生成 Brownfield PRD
|
|
489
|
+
# ✓ 步骤 4/6: PM 拆分史诗 → 生成 Epic 文档
|
|
490
|
+
# ✓ 步骤 5/6: Architect 架构设计 → 生成架构设计和数据库脚本
|
|
491
|
+
# ✓ 步骤 6/6: 生成需求分析完成报告
|
|
492
|
+
# ↓
|
|
493
|
+
# ✓ 阶段间无缝衔接验证
|
|
494
|
+
# ↓
|
|
495
|
+
# 【阶段 2: 用户故事开发】(约 40-70 分钟 × 故事数量)
|
|
496
|
+
# 对每个用户故事循环执行:
|
|
497
|
+
# ✓ SM 创建用户故事 → 快速构建验证
|
|
498
|
+
# ✓ PO 验证故事(10步验证)
|
|
499
|
+
# ✓ 预开发构建检查
|
|
500
|
+
# ✓ Dev 开发实现 + 自测
|
|
501
|
+
# ✓ QA 测试验证(真实数据测试)
|
|
502
|
+
# ✓ 质量门控决策 → Done
|
|
503
|
+
# 直到所有用户故事完成
|
|
504
|
+
# ↓
|
|
505
|
+
# ✓ 生成端到端完成报告
|
|
506
|
+
|
|
507
|
+
# 4. 工作流完成后检查所有输出
|
|
508
|
+
# 阶段 1 输出:
|
|
509
|
+
# - docs/requirements/requirements-analysis.md
|
|
510
|
+
# - docs/architecture/current-architecture-analysis.md
|
|
511
|
+
# - docs/prd/brownfield-iteration-prd.md
|
|
512
|
+
# - docs/epics/史诗-*.md
|
|
513
|
+
# - docs/architecture/iteration-backend-design.md
|
|
514
|
+
# - docs/architecture/db-migration-scripts.sql
|
|
515
|
+
# - docs/architecture/*.md (7个模块文档)
|
|
516
|
+
#
|
|
517
|
+
# 阶段 2 输出:
|
|
518
|
+
# - docs/stories/epic{X}-story{Y}.md (所有故事状态: Done)
|
|
519
|
+
# - src/ 目录下的实现代码
|
|
520
|
+
# - 测试报告
|
|
521
|
+
# - QA gate 文件
|
|
522
|
+
#
|
|
523
|
+
# 完成报告:
|
|
524
|
+
# - docs/end-to-end-completion-report.md
|
|
525
|
+
```
|
|
526
|
+
|
|
527
|
+
**🌟 端到端工作流的特殊优势**:
|
|
528
|
+
|
|
529
|
+
- ✅ **一键到底**: 只需一个命令,无需在两个阶段间手动切换
|
|
530
|
+
- ✅ **无缝衔接**: 阶段1完成后自动验证并进入阶段2,完全自动化
|
|
531
|
+
- ✅ **全程监控**: 统一的进度追踪和质量控制
|
|
532
|
+
- ✅ **完整报告**: 生成包含两个阶段的综合完成报告
|
|
533
|
+
- ✅ **节省时间**: 避免手动操作和阶段间切换的开销
|
|
534
|
+
- ⚠️ **执行时长**: 适合有充足时间的场景(典型小项目 4-8 小时)
|
|
535
|
+
|
|
536
|
+
**🔥 适用场景**:
|
|
537
|
+
- 从零开始的新需求迭代
|
|
538
|
+
- 需要完整的需求分析和代码实现
|
|
539
|
+
- 有充足的执行时间(半天到一天)
|
|
540
|
+
- 希望最小化人工干预
|
|
541
|
+
|
|
542
|
+
---
|
|
543
|
+
|
|
394
544
|
### 执行需求分析工作流
|
|
395
545
|
|
|
396
546
|
```bash
|
package/dist/teams/team-all.txt
CHANGED
|
@@ -1528,6 +1528,7 @@ commands:
|
|
|
1528
1528
|
- help: 显示以下命令的编号列表以供选择
|
|
1529
1529
|
- run-requirements-analysis: 🔥 自动化需求分析工作流(完全自动执行,不暂停)- 加载 automated-requirements-analysis.yaml 并连续执行所有 6 个步骤,从 req.txt 到最终的架构设计文档,全程自动化无需人工干预
|
|
1530
1530
|
- run-story-development: 🔥 自动化用户故事开发工作流(完全自动执行,不暂停)- 加载 automated-story-development.yaml 并循环执行所有用户故事的 SM→PO→Dev→QA 完整开发周期,全程自动化无需人工干预
|
|
1531
|
+
- run-requirements-development: '🔥🔥🔥 端到端全自动化工作流(完全自动执行,不暂停)- 加载 automated-requirements-development.yaml 并连续执行从需求分析到用户故事开发完成的完整流程 (阶段1: 需求分析 6步 + 阶段2: 用户故事开发循环), 实现从 req.txt 到所有代码完成的端到端自动化'
|
|
1531
1532
|
- status: 显示当前工作流执行状态和进度
|
|
1532
1533
|
- validate-prerequisites: 验证工作流执行的前置条件
|
|
1533
1534
|
- resume-workflow: 从上次中断的位置恢复工作流执行(同样会自动连续执行剩余步骤)
|
|
@@ -1537,6 +1538,7 @@ dependencies:
|
|
|
1537
1538
|
workflows:
|
|
1538
1539
|
- automated-requirements-analysis.yaml
|
|
1539
1540
|
- automated-story-development.yaml
|
|
1541
|
+
- automated-requirements-development.yaml
|
|
1540
1542
|
```
|
|
1541
1543
|
|
|
1542
1544
|
---
|
|
@@ -1650,7 +1652,77 @@ workflow_stages:
|
|
|
1650
1652
|
|
|
1651
1653
|
---
|
|
1652
1654
|
|
|
1653
|
-
### 2.
|
|
1655
|
+
### 2. 🔥🔥🔥 端到端全自动化工作流 (新增)
|
|
1656
|
+
|
|
1657
|
+
**命令**: `*run-requirements-development`
|
|
1658
|
+
|
|
1659
|
+
**功能**: 执行从需求分析到用户故事开发完成的完整端到端自动化流程
|
|
1660
|
+
|
|
1661
|
+
**工作流文件**: `xiaoma-core/workflows/automated-requirements-development.yaml`
|
|
1662
|
+
|
|
1663
|
+
**核心价值**:
|
|
1664
|
+
- ✅ **一键启动**: 只需执行一个命令,完成从 req.txt 到所有代码的端到端开发
|
|
1665
|
+
- ✅ **无缝衔接**: 需求分析阶段自动衔接用户故事开发阶段,无需人工干预
|
|
1666
|
+
- ✅ **全程自动化**: 整合了两个子工作流的所有优势,实现完整的自动化流程
|
|
1667
|
+
- ✅ **质量保证**: 两个阶段的所有质量门控都会自动执行
|
|
1668
|
+
|
|
1669
|
+
**执行流程**:
|
|
1670
|
+
|
|
1671
|
+
```yaml
|
|
1672
|
+
端到端工作流结构:
|
|
1673
|
+
|
|
1674
|
+
阶段 1: 需求分析阶段 (1.5-2.5小时)
|
|
1675
|
+
├─ 步骤 0/6: 前置环境验证
|
|
1676
|
+
├─ 步骤 1/6: Analyst 需求分析
|
|
1677
|
+
├─ 步骤 2/6: Architect 架构分析
|
|
1678
|
+
├─ 步骤 3/6: PM 创建 PRD
|
|
1679
|
+
├─ 步骤 4/6: PM 拆分史诗
|
|
1680
|
+
├─ 步骤 5/6: Architect 架构设计
|
|
1681
|
+
└─ 步骤 6/6: 生成需求分析报告
|
|
1682
|
+
↓
|
|
1683
|
+
阶段间验证(无缝衔接)
|
|
1684
|
+
↓
|
|
1685
|
+
阶段 2: 用户故事开发阶段 (40-70分钟/故事)
|
|
1686
|
+
循环执行(直到所有用户故事完成):
|
|
1687
|
+
├─ 步骤 1: SM 创建用户故事
|
|
1688
|
+
├─ 步骤 1.5: 快速构建验证
|
|
1689
|
+
├─ 步骤 2: PO 验证故事
|
|
1690
|
+
├─ 步骤 2.5: 预开发构建检查
|
|
1691
|
+
├─ 步骤 3: Dev 开发故事
|
|
1692
|
+
├─ 步骤 4: QA 测试验证
|
|
1693
|
+
└─ 步骤 5: 质量门控决策
|
|
1694
|
+
↓
|
|
1695
|
+
生成端到端完成报告
|
|
1696
|
+
```
|
|
1697
|
+
|
|
1698
|
+
**总耗时**:
|
|
1699
|
+
- 阶段 1(需求分析): 约 1.5-2.5 小时
|
|
1700
|
+
- 阶段 2(用户故事开发): 约 40-70 分钟 × 用户故事数量
|
|
1701
|
+
- **典型小型项目(5-10个故事)**: 4-8 小时
|
|
1702
|
+
- **典型中型项目(10-20个故事)**: 8-16 小时
|
|
1703
|
+
|
|
1704
|
+
**成功标准**:
|
|
1705
|
+
|
|
1706
|
+
阶段 1 成功标准:
|
|
1707
|
+
- ✅ 所有需求分析文档生成完成
|
|
1708
|
+
- ✅ PRD 和 Epic 文档创建完成
|
|
1709
|
+
- ✅ 架构设计和数据库脚本生成完成
|
|
1710
|
+
- ✅ 所有质量门控通过
|
|
1711
|
+
|
|
1712
|
+
阶段 2 成功标准:
|
|
1713
|
+
- ✅ 所有用户故事状态为 Done
|
|
1714
|
+
- ✅ 所有测试通过(覆盖率 ≥80%)
|
|
1715
|
+
- ✅ 所有 QA 质量门控通过
|
|
1716
|
+
- ✅ 代码质量达标
|
|
1717
|
+
|
|
1718
|
+
整体成功标准:
|
|
1719
|
+
- ✅ 两个阶段全部完成
|
|
1720
|
+
- ✅ 完整的文档和代码生成
|
|
1721
|
+
- ✅ 准备就绪进入集成测试和部署阶段
|
|
1722
|
+
|
|
1723
|
+
---
|
|
1724
|
+
|
|
1725
|
+
### 3. 自动化用户故事开发工作流
|
|
1654
1726
|
|
|
1655
1727
|
**命令**: `*run-story-development`
|
|
1656
1728
|
|
|
@@ -1836,6 +1908,84 @@ quality_gates:
|
|
|
1836
1908
|
|
|
1837
1909
|
## 📊 使用示例
|
|
1838
1910
|
|
|
1911
|
+
### 🔥🔥🔥 执行端到端全自动化工作流(推荐)
|
|
1912
|
+
|
|
1913
|
+
```bash
|
|
1914
|
+
# 1. 准备工作
|
|
1915
|
+
# 确保 docs/req.txt 文件存在且包含 PM 提供的需求
|
|
1916
|
+
|
|
1917
|
+
# 2. 激活工作流执行器
|
|
1918
|
+
/workflow-executor
|
|
1919
|
+
|
|
1920
|
+
# 3. 执行端到端全自动化工作流(完全自动化,一键到底)
|
|
1921
|
+
*run-requirements-development
|
|
1922
|
+
|
|
1923
|
+
# ⚡ 核心优势:一个命令完成从需求分析到代码实现的全部工作!
|
|
1924
|
+
# ⚠️ 重要提示:工作流执行器会自动连续执行两个阶段的所有步骤,不会在中间暂停
|
|
1925
|
+
# 如果工作流在某个步骤停止,说明遇到了错误或质量门控失败,请查看错误信息
|
|
1926
|
+
|
|
1927
|
+
# 工作流执行器将自动完成以下所有工作(典型小项目 4-8 小时):
|
|
1928
|
+
#
|
|
1929
|
+
# 【阶段 1: 需求分析】(约 1.5-2.5 小时)
|
|
1930
|
+
# ✓ 步骤 0/6: 前置环境验证
|
|
1931
|
+
# ✓ 步骤 1/6: Analyst 需求分析 → 生成需求分析报告
|
|
1932
|
+
# ✓ 步骤 2/6: Architect 架构分析 → 生成架构分析报告
|
|
1933
|
+
# ✓ 步骤 3/6: PM 创建 PRD → 生成 Brownfield PRD
|
|
1934
|
+
# ✓ 步骤 4/6: PM 拆分史诗 → 生成 Epic 文档
|
|
1935
|
+
# ✓ 步骤 5/6: Architect 架构设计 → 生成架构设计和数据库脚本
|
|
1936
|
+
# ✓ 步骤 6/6: 生成需求分析完成报告
|
|
1937
|
+
# ↓
|
|
1938
|
+
# ✓ 阶段间无缝衔接验证
|
|
1939
|
+
# ↓
|
|
1940
|
+
# 【阶段 2: 用户故事开发】(约 40-70 分钟 × 故事数量)
|
|
1941
|
+
# 对每个用户故事循环执行:
|
|
1942
|
+
# ✓ SM 创建用户故事 → 快速构建验证
|
|
1943
|
+
# ✓ PO 验证故事(10步验证)
|
|
1944
|
+
# ✓ 预开发构建检查
|
|
1945
|
+
# ✓ Dev 开发实现 + 自测
|
|
1946
|
+
# ✓ QA 测试验证(真实数据测试)
|
|
1947
|
+
# ✓ 质量门控决策 → Done
|
|
1948
|
+
# 直到所有用户故事完成
|
|
1949
|
+
# ↓
|
|
1950
|
+
# ✓ 生成端到端完成报告
|
|
1951
|
+
|
|
1952
|
+
# 4. 工作流完成后检查所有输出
|
|
1953
|
+
# 阶段 1 输出:
|
|
1954
|
+
# - docs/requirements/requirements-analysis.md
|
|
1955
|
+
# - docs/architecture/current-architecture-analysis.md
|
|
1956
|
+
# - docs/prd/brownfield-iteration-prd.md
|
|
1957
|
+
# - docs/epics/史诗-*.md
|
|
1958
|
+
# - docs/architecture/iteration-backend-design.md
|
|
1959
|
+
# - docs/architecture/db-migration-scripts.sql
|
|
1960
|
+
# - docs/architecture/*.md (7个模块文档)
|
|
1961
|
+
#
|
|
1962
|
+
# 阶段 2 输出:
|
|
1963
|
+
# - docs/stories/epic{X}-story{Y}.md (所有故事状态: Done)
|
|
1964
|
+
# - src/ 目录下的实现代码
|
|
1965
|
+
# - 测试报告
|
|
1966
|
+
# - QA gate 文件
|
|
1967
|
+
#
|
|
1968
|
+
# 完成报告:
|
|
1969
|
+
# - docs/end-to-end-completion-report.md
|
|
1970
|
+
```
|
|
1971
|
+
|
|
1972
|
+
**🌟 端到端工作流的特殊优势**:
|
|
1973
|
+
|
|
1974
|
+
- ✅ **一键到底**: 只需一个命令,无需在两个阶段间手动切换
|
|
1975
|
+
- ✅ **无缝衔接**: 阶段1完成后自动验证并进入阶段2,完全自动化
|
|
1976
|
+
- ✅ **全程监控**: 统一的进度追踪和质量控制
|
|
1977
|
+
- ✅ **完整报告**: 生成包含两个阶段的综合完成报告
|
|
1978
|
+
- ✅ **节省时间**: 避免手动操作和阶段间切换的开销
|
|
1979
|
+
- ⚠️ **执行时长**: 适合有充足时间的场景(典型小项目 4-8 小时)
|
|
1980
|
+
|
|
1981
|
+
**🔥 适用场景**:
|
|
1982
|
+
- 从零开始的新需求迭代
|
|
1983
|
+
- 需要完整的需求分析和代码实现
|
|
1984
|
+
- 有充足的执行时间(半天到一天)
|
|
1985
|
+
- 希望最小化人工干预
|
|
1986
|
+
|
|
1987
|
+
---
|
|
1988
|
+
|
|
1839
1989
|
### 执行需求分析工作流
|
|
1840
1990
|
|
|
1841
1991
|
```bash
|
package/package.json
CHANGED
|
@@ -1,7 +1,7 @@
|
|
|
1
1
|
{
|
|
2
2
|
"$schema": "https://json.schemastore.org/package.json",
|
|
3
3
|
"name": "@zeyue0329/xiaoma-cli",
|
|
4
|
-
"version": "1.0.
|
|
4
|
+
"version": "1.0.42",
|
|
5
5
|
"description": "XiaoMa Cli: Universal AI Agent Framework",
|
|
6
6
|
"keywords": [
|
|
7
7
|
"agile",
|
|
@@ -24,6 +24,8 @@
|
|
|
24
24
|
"xiaoma-cli": "tools/xiaoma-npx-wrapper.js"
|
|
25
25
|
},
|
|
26
26
|
"scripts": {
|
|
27
|
+
"api:start": "node tools/api-server.js",
|
|
28
|
+
"api:dev": "nodemon tools/api-server.js",
|
|
27
29
|
"build": "node tools/cli.js build --no-expansions",
|
|
28
30
|
"build:agents": "node tools/cli.js build --agents-only",
|
|
29
31
|
"build:teams": "node tools/cli.js build --teams-only",
|
|
@@ -73,8 +75,11 @@
|
|
|
73
75
|
},
|
|
74
76
|
"dependencies": {
|
|
75
77
|
"@kayvan/markdown-tree-parser": "^1.6.1",
|
|
78
|
+
"body-parser": "^2.2.0",
|
|
76
79
|
"chalk": "^4.1.2",
|
|
77
80
|
"commander": "^14.0.0",
|
|
81
|
+
"cors": "^2.8.5",
|
|
82
|
+
"express": "^5.1.0",
|
|
78
83
|
"fs-extra": "^11.3.1",
|
|
79
84
|
"glob": "^11.0.3",
|
|
80
85
|
"ignore": "^7.0.5",
|