@zeyue0329/xiaoma-cli 1.0.49 → 6.0.0-alpha.13

package/xiaoma-core/workflows/automated-requirements-analysis.yaml

@@ -1,2149 +0,0 @@
-# <!-- Powered by XIAOMA™ Core -->
-workflow:
-  id: automated-requirements-analysis
-  name: 自动化需求分析和架构设计流程
-  description: >-
-    从 req.txt 需求文档到 PRD 生成和 Epic 拆分的全自动化流程。
-    包含现有架构分析、PRD 创建、Epic 拆分、技术架构设计等完整环节。
-    适用于现有 Java 后端项目的迭代需求开发（Brownfield 项目）。
-  type: automated-requirements-analysis
-  project_types:
-    - java-backend
-    - brownfield-project
-    - enterprise-app
-    - api-first
-
-  # 工作流增强特性
-  optimizations:
-    - existing_architecture_analysis: true
-    - brownfield_prd_creation: true
-    - automatic_epic_sharding: true
-    - incremental_architecture_design: true
-    - quality_self_validation: true
-
-  sequence:
-    # ================================
-    # 🆕 前置步骤：环境和依赖验证
-    # ================================
-    - step: pre_workflow_validation
-      action: validate_environment_and_dependencies
-      run_once: true
-      duration: 1m
-      detailed_steps:
-        - step: check_req_file
-          description: "验证 req.txt 需求文档是否存在"
-          required_files:
-            - docs/req.txt
-          on_missing:
-            action: halt_workflow
-            message: "❌ 未找到 docs/req.txt 文件，请确保产品经理已提供需求文档"
-
-        - step: check_project_structure
-          description: "验证项目基本结构"
-          required_directories:
-            - src/
-            - docs/
-          validation:
-            - check_java_source_exists
-            - check_pom_or_gradle_exists
-          on_missing:
-            action: halt_workflow
-            message: "❌ 项目结构不完整，请确保这是一个有效的 Java 项目"
-
-        - step: check_xiaoma_core_installed
-          description: "验证 xiaoma-core 是否已安装"
-          required_directories:
-            - .xiaoma-core/
-          on_missing:
-            action: halt_workflow
-            message: "❌ 未检测到 .xiaoma-core/ 目录，请先运行 'npm run install:xiaoma' 安装"
-
-        - step: create_required_directories
-          description: "创建必要的文档目录结构"
-          action: create_if_missing
-          directories:
-            - docs/requirements/
-            - docs/prd/
-            - docs/architecture/
-            - docs/epics/
-            - docs/stories/
-          notes: "自动创建需求分析所需的文档目录"
-
-      on_success:
-        message: "✅ 环境验证通过，开始自动化需求分析流程"
-      on_failure:
-        action: halt_with_instructions
-        instructions: |
-          ❌ 环境验证失败，请完成以下前置工作：
-          1. 确保 docs/req.txt 文件存在且包含 PM 提供的需求
-          2. 确保项目是有效的 Java 项目（包含 src/ 和 pom.xml）
-          3. 运行 'npm run install:xiaoma' 安装 xiaoma-core
-          4. 确保所有依赖就绪后重新启动工作流
-
-    # ================================
-    # 第1步：Analyst 需求分析和澄清
-    # ================================
-    - step: requirements_analysis_and_elicitation
-      agent: analyst
-      action: analyze_and_clarify_requirements
-      duration: 15-25m
-      detailed_steps:
-        - step: switch_to_analyst_agent
-          command: "/analyst"
-          description: "切换到 Analyst（业务分析师）智能体"
-          notes: "激活业务分析师角色，准备分析和澄清需求"
-
-        - step: analyze_requirements
-          action: execute_requirements_analysis
-          input:
-            - req_file: "docs/req.txt"
-          prompt_template: |
-            我需要对产品经理提供的需求文档进行深度分析和澄清。
-
-            **需求文档**：
-            请阅读当前项目的 docs/req.txt 文件内容
-
-            **分析任务**：
-            1. 需求理解和解析
-               - 识别业务目标和价值主张
-               - 提取核心功能需求
-               - 识别非功能需求（性能、安全、兼容性）
-               - 识别隐含需求和假设
-
-            2. 需求澄清和细化
-               - 识别模糊或不清晰的需求点
-               - 提出澄清问题（假设用户回答）
-               - 补充缺失的需求细节
-               - 明确需求优先级
-
-            3. 用户和场景分析
-               - 识别目标用户角色
-               - 分析典型使用场景
-               - 绘制用户旅程地图
-
-            4. 需求分类和结构化
-               - 按功能模块分类需求
-               - 识别需求间的依赖关系
-               - 评估需求复杂度
-               - 建议实施优先级
-
-            5. 风险和约束识别
-               - 识别业务风险
-               - 识别技术约束
-               - 识别资源约束
-               - 提出风险缓解建议
-
-            **输出要求**：
-            请生成一份结构化的需求分析报告，包含：
-
-            ## 1. 需求概览
-            - 项目背景和目标
-            - 业务价值主张
-            - 核心功能摘要
-
-            ## 2. 需求分类清单
-            - 功能需求（按模块分类）
-            - 非功能需求
-            - 数据需求
-            - 接口需求
-            - 约束条件
-
-            ## 3. 用户和场景
-            - 目标用户角色定义
-            - 典型使用场景
-            - 用户旅程地图
-
-            ## 4. 需求澄清记录
-            - 原始需求中的不明确点
-            - 澄清后的明确需求
-            - 补充的需求细节
-
-            ## 5. 需求优先级
-            - 高优先级需求（Must Have）
-            - 中优先级需求（Should Have）
-            - 低优先级需求（Could Have）
-            - 未来考虑（Won't Have This Time）
-
-            ## 6. 依赖关系分析
-            - 功能依赖关系图
-            - 技术依赖识别
-            - 数据依赖识别
-
-            ## 7. 风险和约束
-            - 识别的业务风险
-            - 识别的技术约束
-            - 资源和时间约束
-            - 风险缓解建议
-
-            ## 8. 实施建议
-            - 建议的开发阶段划分
-            - MVP（最小可行产品）范围
-            - 迭代计划建议
-
-            **保存位置**：`docs/requirements/requirements-analysis.md`
-
-          execution_process:
-            phase_1: parse_and_understand_requirements
-            phase_2: identify_ambiguities_and_gaps
-            phase_3: clarify_and_refine_requirements
-            phase_4: classify_and_structure_requirements
-            phase_5: analyze_users_and_scenarios
-            phase_6: identify_dependencies_and_priorities
-            phase_7: assess_risks_and_constraints
-            phase_8: generate_analysis_report
-
-          validation_criteria:
-            - all_requirements_captured
-            - ambiguities_clarified
-            - requirements_classified
-            - users_and_scenarios_defined
-            - priorities_assigned
-            - dependencies_identified
-            - risks_assessed
-
-          output:
-            file: "docs/requirements/requirements-analysis.md"
-            format: "structured_markdown"
-            sections:
-              - requirements_overview
-              - classified_requirements
-              - users_and_scenarios
-              - clarification_records
-              - priority_ranking
-              - dependency_analysis
-              - risks_and_constraints
-              - implementation_recommendations
-
-          notes: |
-            Analyst 进行需求分析的关键任务：
-            - 深度理解 req.txt 中的原始需求
-            - 识别并澄清模糊不清的需求点
-            - 补充隐含需求和缺失细节
-            - 结构化分类需求
-            - 分析用户和使用场景
-            - 识别依赖关系和优先级
-            - 评估风险和约束
-
-            此步骤为后续 PRD 创建提供清晰的需求基础。
-
-        - step: create_project_brief_optional
-          command: "*create-project-brief"
-          description: "可选：创建项目简报"
-          optional: true
-          prompt_template: |
-            基于需求分析，创建一份简洁的项目简报。
-
-            **任务要求**：
-            请执行 *create-project-brief 命令，生成项目简报文档。
-
-            **项目简报应包含**：
-            1. 项目概述（1-2段）
-            2. 业务目标和成功标准
-            3. 核心功能清单（项目符号）
-            4. 目标用户和使用场景
-            5. 关键里程碑和时间线
-            6. 主要风险和缓解措施
-            7. 资源需求概要
-
-            请执行命令。
-
-          notes: |
-            项目简报是可选步骤，适用于：
-            - 需要向利益相关者汇报的情况
-            - 需要快速概览项目全貌
-            - 作为 PRD 的高层摘要
-
-        - step: validate_analysis_quality
-          action: self_review_analysis_quality
-          prompt_template: |
-            请审查刚才创建的需求分析报告，确认：
-
-            **完整性检查**：
-            1. ✓ 所有需求都已从 req.txt 中提取
-            2. ✓ 需求分类清晰完整
-            3. ✓ 用户角色和场景已定义
-            4. ✓ 需求优先级已明确
-            5. ✓ 依赖关系已识别
-            6. ✓ 风险和约束已评估
-
-            **质量检查**：
-            7. ✓ 需求描述清晰无歧义
-            8. ✓ 模糊需求已澄清
-            9. ✓ 隐含需求已显性化
-            10. ✓ 需求可测量可验证
-            11. ✓ 实施建议合理可行
-
-            如果有遗漏或不清晰的地方，请指出并补充。
-            如果所有检查项都通过，请确认需求分析质量合格。
-
-          validation_process:
-            step_1: completeness_check
-            step_2: clarity_check
-            step_3: priority_validation
-            step_4: dependency_validation
-            step_5: risk_assessment_validation
-
-          quality_criteria:
-            - requirements_completeness: "100%"
-            - clarity_score: ">=9/10"
-            - priority_coverage: "100%"
-            - dependency_mapping: ">=90%"
-
-          on_issues_found:
-            action: refine_analysis
-            max_iterations: 2
-            notes: "Analyst 自我修正需求分析中发现的问题"
-
-          on_all_checks_passed:
-            action: mark_analysis_validated
-            message: "✅ 需求分析质量检查通过，准备架构分析"
-
-          notes: |
-            Analyst 自检需求分析质量：
-            - 确保需求完整覆盖
-            - 验证需求清晰度
-            - 确认优先级合理
-            - 检查依赖关系完整
-
-            质量标准：
-            - 需求完整性 100%
-            - 清晰度评分 ≥9/10
-            - 优先级覆盖 100%
-            - 依赖映射 ≥90%
-
-      validation_criteria:
-        - requirements_analysis_complete
-        - all_requirements_extracted
-        - ambiguities_resolved
-        - requirements_classified
-        - priorities_assigned
-        - dependencies_mapped
-        - risks_identified
-        - quality_self_check_passed
-        - file_created: "docs/requirements/requirements-analysis.md"
-
-      on_failure:
-        action: retry_analysis
-        max_retries: 2
-        escalation: "需求分析失败，需要人工审查 req.txt 的质量"
-
-      on_success:
-        action: proceed_to_architecture_analysis
-        message: "✅ 需求分析完成，准备分析现有架构"
-
-      notes: |
-        Analyst 进行需求分析的完整流程：
-        1. 执行 /analyst 切换到业务分析师智能体
-        2. 读取并深度分析 docs/req.txt
-        3. 识别并澄清模糊需求
-        4. 结构化分类需求（功能、非功能、数据、接口）
-        5. 分析用户和使用场景
-        6. 确定需求优先级和依赖关系
-        7. 识别风险和约束
-        8. 可选：创建项目简报
-        9. 自检需求分析质量
-        10. 保存到 docs/requirements/requirements-analysis.md
-
-        关键输出：
-        - 结构化的需求分析报告
-        - 明确的需求分类和优先级
-        - 用户角色和场景定义
-        - 依赖关系图
-        - 风险和约束清单
-
-        此步骤为 PM 创建 PRD 提供清晰的需求基础。
-
-    # ================================
-    # 第2步：Architect 分析现有架构
-    # ================================
-    - step: analyze_existing_architecture
-      agent: architect
-      action: analyze_current_system_architecture
-      duration: 10-20m
-      detailed_steps:
-        - step: switch_to_architect_agent
-          command: "/architect"
-          description: "切换到 Architect 智能体"
-          notes: "激活架构师角色，准备分析现有系统架构"
-
-        - step: analyze_architecture
-          action: execute_architecture_analysis
-          input:
-            - project_source_code: "src/"
-            - project_config: "pom.xml"
-            - existing_docs: "docs/"
-          prompt_template: |
-            请分析当前项目的后端架构。
-
-            **项目信息**：
-            - 项目类型：Java 后端项目（现有代码库）
-            - 项目路径：{project_root}
-            - 技术栈：从项目配置文件中自动识别
-
-            **分析任务**：
-            1. 扫描项目目录结构
-               - 识别源码组织方式（Maven）
-               - 识别包结构和分层架构
-
-            2. 识别技术栈和框架
-               - Spring Boot 版本
-               - 持久化框架（MyBatis/MyBatis-Plus/JPA/Hibernate）
-               - 数据库类型和版本（MySQL/PostgreSQL等）
-               - 其他关键依赖（Redis/Kafka/等）
-
-            3. 分析现有数据库设计
-               - 扫描 Entity/Model 类
-               - 识别现有数据表清单（可以检查有无数据库链接的 mcp 服务，如果有，可以从数据库链接的 mcp 服务中获取现有数据表清单，如果没有，则从 Entity/Model 类中获取）
-               - 分析表之间的关联关系
-               - 识别数据库命名规范
-
-            4. 识别现有 API 端点
-               - 扫描 Controller 类
-               - 提取 RESTful API 端点清单
-               - 分析 API 版本策略
-               - 识别请求/响应 DTO 模式
-
-            5. 总结架构模式和设计原则
-               - 分层架构分析（Controller-Application(如有此层)-Service-Mapper/Repository）
-               - 事务管理策略
-               - 异常处理机制
-               - 安全认证/授权方式
-               - 日志记录规范
-               - 代码风格和命名约定
-
-            **输出要求**：
-            请生成一份结构化的架构分析报告，包含：
-
-            ## 1. 项目概览
-            - 项目名称
-            - 技术栈版本清单
-            - 项目规模统计（类数量、接口数量等）
-
-            ## 2. 技术架构
-            - 框架和依赖清单
-            - 分层架构说明
-            - 关键技术组件
-
-            ## 3. 数据库架构
-            - 数据库类型和版本
-            - 现有数据表清单（表名、用途、主要字段）
-            - ER 关系说明
-            - 数据库设计模式
-
-            ## 4. API 架构
-            - API 模块清单
-            - RESTful 端点统计
-            - API 版本策略
-            - 请求/响应规范
-
-            ## 5. 代码组织
-            - 包结构说明
-            - 分层职责定义
-            - 公共组件和工具类
-
-            ## 6. 架构特点和注意事项
-            - 遵循的设计原则
-            - 编码规范要点
-            - 技术约束
-            - 已知技术债务
-
-            ## 7. 迭代开发建议
-            - 新增功能的集成点
-            - 需要遵循的规范
-            - 兼容性注意事项
-
-            **保存位置**：`docs/architecture/current-architecture-analysis.md`
-
-          execution_process:
-            phase_1: scan_project_structure
-            phase_2: identify_tech_stack
-            phase_3: analyze_database_design
-            phase_4: extract_api_endpoints
-            phase_5: summarize_architecture_patterns
-            phase_6: generate_analysis_report
-
-          validation_criteria:
-            - tech_stack_identified
-            - database_entities_listed
-            - api_endpoints_documented
-            - architecture_patterns_described
-            - coding_standards_documented
-
-          output:
-            file: "docs/architecture/current-architecture-analysis.md"
-            format: "structured_markdown"
-            sections:
-              - project_overview
-              - technical_architecture
-              - database_architecture
-              - api_architecture
-              - code_organization
-              - architecture_characteristics
-              - iteration_development_recommendations
-
-          notes: |
-            架构分析是整个需求分析流程的基础。
-
-            分析重点：
-            - 自动扫描项目代码识别技术栈
-            - 提取现有数据模型和 API 清单
-            - 总结架构模式和编码规范
-            - 为后续 PRD 和架构设计提供技术上下文
-
-            输出的架构分析报告将被后续步骤引用：
-            - PM 创建 PRD 时需要了解技术约束
-            - Architect 设计增量架构时需要保持一致性
-
-      validation_criteria:
-        - architecture_analysis_complete
-        - tech_stack_documented
-        - existing_entities_listed
-        - existing_apis_documented
-        - file_created: "docs/architecture/current-architecture-analysis.md"
-
-      on_failure:
-        action: retry_analysis
-        max_retries: 2
-        escalation: "架构分析失败，可能需要人工介入"
-
-      on_success:
-        action: proceed_to_prd_creation
-        message: "✅ 现有架构分析完成，准备创建 PRD"
-
-      notes: |
-        Architect 分析现有架构的完整流程：
-        1. 执行 /architect 切换到架构师智能体
-        2. 自动扫描项目代码和配置文件
-        3. 识别技术栈、数据模型、API 端点
-        4. 生成结构化的架构分析报告
-        5. 保存到 docs/architecture/current-architecture-analysis.md
-
-        架构分析是 Brownfield 项目的关键步骤：
-        - 确保新需求与现有架构兼容
-        - 识别现有技术约束
-        - 为增量设计提供基础
-
-    # ================================
-    # 第3步：PM 创建 Brownfield PRD
-    # ================================
-    - step: create_brownfield_prd
-      agent: pm
-      action: create_product_requirements_document
-      requires:
-        - docs/req.txt
-        - docs/requirements/requirements-analysis.md
-        - docs/architecture/current-architecture-analysis.md
-      duration: 20-30m
-      detailed_steps:
-        - step: switch_to_pm_agent
-          command: "/pm"
-          description: "切换到 PM（产品经理）智能体"
-          notes: "激活产品经理角色，准备创建 Brownfield PRD"
-
-        - step: load_requirements_and_context
-          action: load_input_documents
-          inputs:
-            req_file: "docs/req.txt"
-            architecture_analysis: "docs/architecture/current-architecture-analysis.md"
-          notes: "加载 PM 提供的需求文档和架构分析报告"
-
-        - step: execute_create_brownfield_prd
-          command: "*create-brownfield-prd"
-          description: "执行 *create-brownfield-prd 命令创建现有项目迭代需求的 PRD"
-          action: create_prd_for_existing_project
-          prompt_template: |
-            我需要为现有 Java 后端项目创建一份迭代需求的 PRD 文档。
-
-            **项目背景**：
-            - 项目名称：从当前项目的实际名称（可从 pom.xml 中获取）
-            - 项目类型：现有 Java 后端项目（Brownfield）
-            - 技术栈：从当前项目的 docs/architecture/current-architecture-analysis.md 中获取
-            - 现有功能：从当前项目的 docs/architecture/current-architecture-analysis.md 中获取功能概述
-
-            **需求来源**：
-            产品经理提供的需求文档内容如下：
-            ---
-            当前项目的 docs/req.txt 文档中需求内容
-            ---
-
-            **任务要求**：
-            请使用 *create-brownfield-prd 命令创建 PRD 文档。
-
-            **PRD 应包含**：
-            1. 需求概述
-               - 迭代背景和目标
-               - 目标用户群体
-               - 业务价值说明
-
-            2. 目标用户和使用场景
-               - 用户角色定义
-               - 典型使用场景描述
-               - 用户旅程地图
-
-            3. 功能需求详细描述
-               - 功能模块清单
-               - 每个功能的详细描述
-               - 业务规则和约束
-               - 数据流和处理逻辑
-
-            4. 非功能需求
-               - 性能要求（响应时间、并发量）
-               - 安全要求（认证、授权、数据保护）
-               - 兼容性要求（浏览器、移动端、API版本）
-               - 可用性和可维护性要求
-
-            5. 技术约束（基于现有架构）
-               - 必须使用的技术栈
-               - 必须遵循的架构模式
-               - 不能修改的现有组件
-               - 技术兼容性约束
-
-            6. 数据需求（数据库变更）
-               - 新增数据表清单
-               - 修改现有表的变更说明
-               - 数据迁移策略
-               - 数据关联关系
-
-            7. API 需求（新增/修改的接口）
-               - RESTful API 端点清单
-               - 请求/响应数据结构
-               - API 版本策略
-               - 与现有 API 的集成点
-
-            8. 验收标准
-               - 功能验收标准（可测试、可验证）
-               - 性能验收标准
-               - 质量验收标准
-
-            9. 实施计划（模块拆分建议）
-               - 建议的模块划分
-               - 优先级排序
-               - 依赖关系说明
-               - 预估工作量
-
-            **特别注意**：
-            - 这是现有项目的迭代需求，需要考虑与现有系统的兼容性
-            - 数据库设计需要考虑数据迁移策略
-            - API 设计需要遵循现有的 RESTful 规范
-            - 所有新功能都要说明如何与现有功能集成
-
-            请开始执行 *create-brownfield-prd
-
-          execution_process:
-            phase_1: parse_req_txt_requirements
-            phase_2: extract_technical_constraints_from_architecture
-            phase_3: identify_functional_modules
-            phase_4: define_database_changes
-            phase_5: design_api_specifications
-            phase_6: define_acceptance_criteria
-            phase_7: suggest_epic_breakdown
-            phase_8: generate_prd_document
-
-          prd_structure_template:
-            metadata:
-              - title: "PRD标题"
-              - version: "版本号"
-              - author: "PM Agent"
-              - created_date: "创建日期"
-              - status: "Draft"
-
-            sections:
-              section_1_overview:
-                - 迭代背景
-                - 目标和价值
-                - 范围说明
-
-              section_2_users_and_scenarios:
-                - 用户角色
-                - 使用场景
-                - 用户旅程
-
-              section_3_functional_requirements:
-                - 功能模块清单
-                - 详细功能描述
-                - 业务规则
-
-              section_4_non_functional_requirements:
-                - 性能要求
-                - 安全要求
-                - 兼容性要求
-
-              section_5_technical_constraints:
-                - 技术栈约束
-                - 架构约束
-                - 兼容性约束
-
-              section_6_data_requirements:
-                - 数据库变更清单
-                - 数据迁移策略
-
-              section_7_api_requirements:
-                - API 端点清单
-                - 接口规范
-
-              section_8_acceptance_criteria:
-                - 功能验收标准
-                - 质量验收标准
-
-              section_9_implementation_plan:
-                - 模块拆分建议
-                - 优先级排序
-                - 依赖关系
-
-          validation_criteria:
-            - all_requirements_from_req_captured
-            - technical_constraints_aligned_with_architecture
-            - database_changes_clearly_defined
-            - api_specifications_complete
-            - acceptance_criteria_testable
-            - epic_breakdown_suggested
-
-          output:
-            file: "docs/prd/brownfield-iteration-prd.md"
-            format: "structured_markdown"
-            status: "Draft"
-
-          notes: |
-            使用 *create-brownfield-prd 命令创建 PRD：
-
-            输入来源：
-            - req.txt：PM 提供的原始需求
-            - current-architecture-analysis.md：现有架构上下文
-
-            处理流程：
-            1. 解析 req.txt 中的业务需求
-            2. 提取架构分析中的技术约束
-            3. 识别功能模块和依赖关系
-            4. 定义数据库变更（DDL）
-            5. 设计 API 规范（RESTful）
-            6. 定义可测试的验收标准
-            7. 建议模块拆分方案
-            8. 生成结构化的 PRD 文档
-
-            特别关注：
-            - Brownfield 项目的兼容性约束
-            - 数据迁移的风险和策略
-            - 与现有 API 的集成点
-
-        - step: validate_prd_quality
-          action: self_review_prd_quality
-          prompt_template: |
-            请审查刚才创建的 PRD 文档，确认：
-
-            **完整性检查**：
-            1. ✓ 所有功能需求都已覆盖（对照 req.txt）
-            2. ✓ 需求描述清晰无歧义
-            3. ✓ 技术约束与现有架构兼容
-            4. ✓ 数据库变更已明确定义（表名、字段、类型、约束）
-            5. ✓ API 接口需求清晰（端点、方法、参数、响应）
-            6. ✓ 验收标准可测试（具体、可量化）
-            7. ✓ 模块拆分建议合理（规模适当、依赖清晰）
-
-            **质量检查**：
-            8. ✓ 用户价值明确
-            9. ✓ 业务流程完整
-            10. ✓ 非功能需求充分
-            11. ✓ 技术可行性已评估
-            12. ✓ 风险和注意事项已识别
-
-            **Brownfield 特定检查**：
-            13. ✓ 与现有系统的集成点已说明
-            14. ✓ 数据迁移策略已定义
-            15. ✓ API 版本策略已考虑
-            16. ✓ 向后兼容性已保证
-
-            如果有遗漏或不清晰的地方，请指出并补充。
-            如果所有检查项都通过，请确认 PRD 质量合格。
-
-          validation_process:
-            step_1: completeness_check
-            step_2: clarity_check
-            step_3: technical_feasibility_check
-            step_4: brownfield_compatibility_check
-            step_5: acceptance_criteria_testability_check
-
-          quality_criteria:
-            - requirements_coverage: "100%"
-            - clarity_score: ">=9/10"
-            - technical_alignment: "100%"
-            - testability_score: ">=9/10"
-
-          on_issues_found:
-            action: fix_prd_issues
-            max_iterations: 2
-            notes: "PM 自我修正 PRD 中发现的问题"
-
-          on_all_checks_passed:
-            action: mark_prd_as_validated
-            message: "✅ PRD 质量检查通过，准备拆分模块"
-
-          notes: |
-            PM 自检 PRD 质量：
-            - 对照 req.txt 确保需求完整覆盖
-            - 验证技术约束与架构分析一致
-            - 确认验收标准可测试
-            - 检查 Brownfield 特定的兼容性考虑
-
-            质量标准：
-            - 需求覆盖率 100%
-            - 清晰度评分 ≥9/10
-            - 技术对齐度 100%
-            - 可测试性 ≥9/10
-
-      validation_criteria:
-        - prd_document_created
-        - all_requirements_covered
-        - technical_constraints_defined
-        - database_changes_specified
-        - api_specifications_complete
-        - acceptance_criteria_testable
-        - epic_breakdown_suggested
-        - quality_self_check_passed
-        - file_created: "docs/prd/brownfield-iteration-prd.md"
-
-      on_failure:
-        action: retry_prd_creation
-        max_retries: 2
-        escalation: "PRD 创建失败，需要人工审查 req.txt 和架构分析"
-
-      on_success:
-        action: proceed_to_epic_sharding
-        message: "✅ Brownfield PRD 创建完成，准备拆分模块"
-
-      notes: |
-        PM 创建 Brownfield PRD 的完整流程：
-        1. 执行 /pm 切换到产品经理智能体
-        2. 加载 req.txt 和 current-architecture-analysis.md
-        3. 执行 *create-brownfield-prd 命令
-           - 解析业务需求
-           - 结合技术约束
-           - 定义功能模块、数据变更、API 规范
-           - 制定验收标准
-           - 建议模块拆分
-        4. 自检 PRD 质量（16项检查）
-        5. 输出到 docs/prd/brownfield-iteration-prd.md
-
-        关键输出：
-        - 结构化的 PRD 文档
-        - 数据库变更清单
-        - API 接口规范
-        - 模块拆分建议
-
-    # ================================
-    # 第3步：PM 拆分模块（循环）
-    # ================================
-    - step: epic_sharding_cycle
-      action: create_epics_from_prd
-      requires:
-        - docs/prd/brownfield-iteration-prd.md
-      condition: has_epics_to_create
-      notes: "根据 PRD 中的模块拆分建议，循环创建每个模块文档"
-
-      epic_creation_loop:
-        - step: identify_next_epic
-          action: determine_next_epic_to_create
-          source: "docs/prd/brownfield-iteration-prd.md"
-          extraction_logic: |
-            从 PRD 的"实施计划（模块拆分建议）"部分提取：
-            - 模块清单
-            - 已创建的模块（检查 docs/epics/ 目录）
-            - 确定下一个待创建的模块
-
-          decision_logic: |
-            IF 还有未创建的模块 THEN
-              继续创建下一个模块
-            ELSE
-              模块拆分完成，进入下一阶段
-            END IF
-
-          notes: "按照 PRD 建议的优先级和依赖关系顺序创建模块"
-
-        - step: create_single_epic
-          agent: pm
-          action: create_epic_document
-          command: "*create-epic"
-          prompt_template: |
-            基于刚才创建的 PRD，我需要创建模块。
-
-            **模块拆分建议**：
-            根据 PRD 的功能模块，建议拆分为以下模块：
-            {从 PRD 中提取的模块清单}
-
-            **当前任务**：
-            请为第 {epic_index} 个模块"{epic_name}"创建模块文档。
-
-            **模块信息**：
-            - 模块名称：{epic_name}
-            - 模块编号：Epic-{epic_index:02d}
-            - 功能范围：{从 PRD 中提取此模块的功能描述}
-            - 业务价值：{业务价值说明}
-            - 优先级：高/中/低（从 PRD 建议中获取）
-            - 依赖关系：{是否依赖其他模块，从 PRD 中获取}
-
-            **模块文档要求**：
-            1. 模块级别的目标和价值
-               - 模块的业务目标
-               - 为用户/业务带来的价值
-               - 成功标准
-
-            2. 包含的用户故事清单（初步识别）
-               - 根据功能范围识别用户故事
-               - 每个故事的简要描述
-               - 故事优先级
-               - 故事间依赖关系
-
-            3. 技术设计概要（针对此模块）
-               - 涉及的技术组件
-               - 架构设计要点
-               - 技术方案概要
-
-            4. 数据库变更（针对此模块）
-               - 新增的数据表
-               - 修改的现有表
-               - 数据迁移需求
-
-            5. API 接口清单（针对此模块）
-               - 新增的 API 端点
-               - 修改的现有 API
-               - API 版本策略
-
-            6. 验收标准（模块级别）
-               - 模块完成的验收标准
-               - 关键功能验证点
-               - 质量标准
-
-            7. 估算工作量
-               - 预估的故事数量
-               - 预估的开发时间
-               - 风险和不确定性
-
-            8. 风险和注意事项
-               - 技术风险
-               - 业务风险
-               - 依赖风险
-               - 缓解措施
-
-            请执行 *create-epic 命令。
-
-          execution_process:
-            phase_1: extract_epic_scope_from_prd
-            phase_2: identify_user_stories
-            phase_3: define_technical_design_overview
-            phase_4: extract_database_changes
-            phase_5: extract_api_endpoints
-            phase_6: define_epic_acceptance_criteria
-            phase_7: estimate_effort
-            phase_8: identify_risks
-            phase_9: generate_epic_document
-
-          epic_structure_template:
-            metadata:
-              - epic_id: "Epic-{index:02d}"
-              - epic_name: "模块名称"
-              - status: "Planned"
-              - priority: "高/中/低"
-              - created_date: "创建日期"
-
-            sections:
-              section_1_overview:
-                - 模块目标
-                - 业务价值
-                - 成功标准
-
-              section_2_user_stories:
-                - 故事清单（初步识别）
-                - 故事优先级
-                - 故事依赖关系
-
-              section_3_technical_design:
-                - 技术组件
-                - 架构设计
-                - 技术方案
-
-              section_4_database_changes:
-                - 新增表
-                - 修改表
-                - 数据迁移
-
-              section_5_api_specifications:
-                - API 端点清单
-                - 接口概要
-
-              section_6_acceptance_criteria:
-                - 模块验收标准
-                - 质量标准
-
-              section_7_estimation:
-                - 故事数量
-                - 工作量预估
-
-              section_8_risks:
-                - 风险清单
-                - 缓解措施
-
-          validation_criteria:
-            - epic_scope_clearly_defined
-            - user_stories_identified
-            - technical_design_outlined
-            - database_changes_listed
-            - api_endpoints_listed
-            - acceptance_criteria_defined
-            - effort_estimated
-            - risks_identified
-
-          output:
-            file: "docs/epics/Epic{epic_name}.md"
-            format: "structured_markdown"
-            status: "Planned"
-
-          notes: |
-            使用 *create-epic 命令创建单个模块：
-
-            输入来源：
-            - PRD 文档中的模块拆分建议
-            - PRD 中对应模块的详细需求
-
-            创建流程：
-            1. 从 PRD 提取模块范围和功能描述
-            2. 初步识别用户故事清单
-            3. 定义技术设计概要
-            4. 提取此模块相关的数据库变更
-            5. 提取此模块相关的 API 端点
-            6. 定义模块级别的验收标准
-            7. 估算工作量和识别风险
-            8. 生成结构化的模块文档
-
-            每个模块是一个独立的功能模块：
-            - 规模适中（2-4周完成）
-            - 业务价值独立
-            - 包含多个用户故事
-            - 可独立验收
-
-        - step: validate_epic_quality
-          action: quick_epic_validation
-          validation_checks:
-            - epic_scope_appropriate: "模块规模适中"
-            - user_stories_count_reasonable: "故事数量合理（5-15个）"
-            - technical_design_consistent: "技术设计与架构一致"
-            - database_changes_isolated: "数据库变更相对独立"
-            - api_endpoints_cohesive: "API 端点内聚"
-
-          on_issues_found:
-            action: fix_epic_issues
-            notes: "PM 调整模块范围或细节"
-
-          on_validation_passed:
-            action: mark_epic_created
-            message: "✅ 模块 {epic_name} 创建完成"
-
-          notes: "快速验证模块质量，确保范围和内容合理"
-
-        - step: loop_check
-          description: "检查是否还有更多模块需要创建"
-          decision_logic: |
-            IF 所有模块都已创建 THEN
-              退出循环，进入架构设计阶段
-            ELSE
-              返回 identify_next_epic 步骤，创建下一个模块
-            END IF
-
-      validation_criteria:
-        - all_suggested_epics_created
-        - epic_files_exist: "docs/epics/Epic-*.md"
-        - each_epic_validated
-
-      on_failure:
-        action: retry_epic_creation
-        max_retries: 2
-        escalation: "模块创建失败，需要审查 PRD 的模块拆分建议"
-
-      on_success:
-        action: proceed_to_architecture_design
-        message: "✅ 所有模块创建完成，准备进行技术架构设计"
-
-      detailed_notes: |
-        PM 拆分模块的完整流程：
-        1. 保持 PM Agent 激活状态
-        2. 从 PRD 的"实施计划"部分提取模块清单
-        3. 循环创建每个模块：
-           a. 识别下一个待创建的模块
-           b. 执行 *create-epic 命令
-           c. 从 PRD 提取相关内容
-           d. 初步识别用户故事
-           e. 定义技术设计概要和数据库/API 变更
-           f. 快速验证模块质量
-           g. 保存模块文档
-        4. 所有模块创建完成后，进入下一阶段
-
-        模块拆分原则：
-        - 每个模块是一个独立的功能模块
-        - 规模适中（2-4周，5-15个用户故事）
-        - 业务价值独立可验收
-        - 技术上相对内聚
-        - 考虑优先级和依赖关系
-
-    # ================================
-    # 第4步：Architect 后端架构增量设计
-    # ================================
-    - step: design_incremental_backend_architecture
-      agent: architect
-      action: create_incremental_architecture_design
-      requires:
-        - docs/prd/brownfield-iteration-prd.md
-        - docs/epics/Epic-*.md
-        - docs/architecture/current-architecture-analysis.md
-      duration: 30-40m
-      detailed_steps:
-        - step: switch_to_architect_agent
-          command: "/architect"
-          description: "切换到 Architect 智能体"
-          notes: "激活架构师角色，准备设计增量架构"
-
-        - step: execute_create_backend_architecture
-          command: "*create-backend-architecture"
-          description: "执行 *create-backend-architecture 命令，进行后端增量架构设计"
-          action: design_backend_architecture
-          prompt_template: |
-            基于现有系统架构，我需要设计此次迭代需求的技术实现方案。
-
-            **现有架构**：
-            当前项目的 docs/architecture/current-architecture-analysis.md 文档中架构分析报告摘要
-
-            **新需求概述**：
-            当前项目的 docs/prd/brownfield-iteration-prd.md 中功能需求摘要
-
-            **模块清单**：
-            {列出所有已创建的模块文件和简要描述}
-
-            **设计任务**：
-            请基于 *create-backend-architecture 命令，但聚焦于增量设计，包括：
-
-            **1. 新增数据模型设计**：
-            - 新增 Entity 实体类（Java Entity）
-              - 类名、包名
-              - 字段定义（类型、注解）
-              - 关联关系（@OneToMany, @ManyToOne, @ManyToMany）
-              - JPA/Hibernate 注解配置
-
-            - 数据表结构设计（DDL）
-              - 完整的 CREATE TABLE 语句
-              - 主键、外键、索引定义
-              - 字段类型、长度、默认值、注释
-              - 约束条件（唯一、非空等）
-
-            - 与现有实体的关联关系
-              - 外键关系
-              - 关联表设计（多对多）
-              - 级联操作策略
-
-            - 数据迁移策略
-              - 新表创建脚本
-              - 现有表修改脚本（ALTER TABLE）
-              - 数据初始化脚本
-              - 回滚方案
-
-            **2. API 设计**：
-            - 新增 RESTful API 端点列表
-              - HTTP 方法（GET/POST/PUT/DELETE）
-              - URL 路径设计
-              - 路径参数和查询参数
-              - 请求 Body 结构
-              - 响应数据结构
-              - HTTP 状态码
-
-            - 请求/响应 DTO 设计
-              - DTO 类名和包名
-              - 字段定义和验证注解
-              - DTO 与 Entity 的映射关系
-
-            - API 版本策略（如需要）
-              - 版本号规则
-              - 向后兼容性保证
-              - 废弃策略
-
-            - 与现有 API 的集成点
-              - 复用现有 API
-              - 扩展现有 API
-              - API 组合调用
-
-            **3. 服务层设计**：
-            - 新增 Service 接口和实现
-              - Service 接口定义
-              - 方法签名和 JavaDoc
-              - 业务逻辑流程
-              - Service 实现类结构
-
-            - 业务逻辑流程图
-              - 关键业务流程的流程图
-              - 决策点和分支逻辑
-              - 异常处理流程
-
-            - 事务边界设计
-              - 事务传播策略
-              - 事务隔离级别
-              - 事务回滚规则
-
-            - 与现有服务的交互
-              - 依赖的现有 Service
-              - 服务间调用关系
-              - 数据流转
-
-            **4. 技术决策**：
-            - 新技术/组件的引入（如需要）
-              - 新增依赖说明
-              - 版本选择理由
-              - 与现有技术栈的兼容性
-
-            - 性能优化策略
-              - 数据库查询优化（索引、分页）
-              - 缓存策略（Redis/本地缓存）
-              - 异步处理（线程池、消息队列）
-
-            - 安全性考虑
-              - 认证和授权策略
-              - 数据加密
-              - SQL 注入防护
-              - XSS 防护
-
-            - 缓存策略
-              - 缓存位置（本地/分布式）
-              - 缓存粒度
-              - 缓存更新策略
-              - 缓存失效策略
-
-            **5. 数据库变更脚本**：
-            - 新增表的 DDL
-              ```sql
-              CREATE TABLE xxx (
-                ...
-              ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
-              ```
-
-            - 现有表的 ALTER 脚本
-              ```sql
-              ALTER TABLE xxx ADD COLUMN yyy ...;
-              ALTER TABLE xxx ADD INDEX idx_zzz (...);
-              ```
-
-            - 索引优化
-              - 新增索引
-              - 修改索引
-              - 复合索引设计
-
-            - 数据迁移脚本
-              - 数据初始化
-              - 数据转换
-              - 数据清理
-
-            **6. 技术风险和注意事项**：
-            - 兼容性风险
-              - API 兼容性
-              - 数据库向后兼容
-              - 依赖版本冲突
-
-            - 性能影响
-              - 新增查询的性能评估
-              - 数据量增长预测
-              - 性能瓶颈识别
-
-            - 技术债务
-              - 已知的设计妥协
-              - 需要重构的遗留代码
-              - 后续优化计划
-
-            **7. 实施指导**：
-            - 开发顺序建议
-              - 模块开发顺序
-              - 依赖关系处理
-              - 集成测试策略
-
-            - 测试策略
-              - 单元测试覆盖率目标
-              - 集成测试场景
-              - 性能测试基准
-
-            - 部署注意事项
-              - 数据库迁移步骤
-              - 配置变更
-              - 灰度发布建议
-
-            **特别要求**：
-            - 遵循现有项目的编码规范和架构模式
-            - 确保向后兼容
-            - 考虑可测试性
-            - 所有设计决策都要有理由说明
-
-            **输出文件**：
-            - 架构设计文档: docs/architecture/iteration-backend-design.md
-            - 数据库脚本: docs/architecture/db-migration-scripts.sql
-
-            请执行设计并将架构文档保存到 docs/architecture/iteration-backend-design.md。
-
-          execution_process:
-            phase_1: analyze_prd_and_epics
-            phase_2: design_data_models_and_entities
-            phase_3: design_api_specifications
-            phase_4: design_service_layer
-            phase_5: make_technical_decisions
-            phase_6: generate_database_migration_scripts
-            phase_7: identify_risks_and_constraints
-            phase_8: create_implementation_guidance
-            phase_9: generate_architecture_document
-
-          architecture_design_structure:
-            metadata:
-              - title: "迭代后端架构增量设计"
-              - version: "版本号"
-              - architect: "Architect Agent"
-              - created_date: "创建日期"
-              - based_on:
-                  - current_architecture_analysis
-                  - prd_document
-                  - epic_documents
-
-            sections:
-              section_1_overview:
-                - 设计概述
-                - 设计原则
-                - 技术选型
-
-              section_2_data_model:
-                - 新增 Entity 类设计
-                - 数据表结构（DDL）
-                - 与现有数据模型的关系
-                - 数据迁移策略
-
-              section_3_api_design:
-                - RESTful API 端点清单
-                - 请求/响应 DTO 设计
-                - API 版本策略
-                - 与现有 API 的集成
-
-              section_4_service_layer:
-                - Service 接口和实现设计
-                - 业务逻辑流程图
-                - 事务边界设计
-                - 与现有服务的交互
-
-              section_5_technical_decisions:
-                - 新技术组件引入
-                - 性能优化策略
-                - 安全性设计
-                - 缓存策略
-
-              section_6_database_changes:
-                - CREATE TABLE 脚本
-                - ALTER TABLE 脚本
-                - 索引优化脚本
-                - 数据迁移脚本
-
-              section_7_risks_and_constraints:
-                - 兼容性风险
-                - 性能影响评估
-                - 技术债务
-
-              section_8_implementation_guidance:
-                - 开发顺序建议
-                - 测试策略
-                - 部署注意事项
-
-          validation_criteria:
-            - data_models_designed
-            - api_specifications_complete
-            - service_layer_designed
-            - database_scripts_generated
-            - technical_decisions_documented
-            - risks_identified
-            - implementation_guidance_provided
-
-          output_files:
-            architecture_doc: "docs/architecture/iteration-backend-design.md"
-            database_scripts: "docs/architecture/db-migration-scripts.sql"
-
-          notes: |
-            使用 *create-backend-architecture 命令设计增量架构：
-
-            输入来源：
-            - current-architecture-analysis.md：现有架构基线
-            - PRD 文档：功能需求和技术约束
-            - Epic 文档：功能模块划分
-
-            设计重点：
-            1. 新增数据模型（Entity + DDL）
-            2. RESTful API 规范（端点 + DTO）
-            3. Service 层业务逻辑
-            4. 技术决策和优化策略
-            5. 数据库迁移脚本
-            6. 风险和注意事项
-
-            增量设计原则：
-            - 与现有架构保持一致
-            - 向后兼容
-            - 可测试性优先
-            - 关注性能和安全
-            - 提供清晰的实施指导
-
-        - step: validate_architecture_design
-          action: self_review_architecture_quality
-          prompt_template: |
-            请对刚才的架构设计进行自我评审，检查：
-
-            **一致性检查**：
-            1. ✓ 是否与现有架构模式一致（分层、命名、技术栈）
-            2. ✓ 新增组件是否遵循现有编码规范
-            3. ✓ API 设计是否符合 RESTful 最佳实践
-            4. ✓ 数据库设计是否符合现有命名规范
-
-            **完整性检查**：
-            5. ✓ 所有 PRD 功能都有对应的技术设计
-            6. ✓ Entity 类与数据表 DDL 一致
-            7. ✓ API 端点与 DTO 设计匹配
-            8. ✓ Service 层涵盖所有业务逻辑
-            9. ✓ 数据库迁移脚本完整（CREATE + ALTER）
-
-            **质量检查**：
-            10. ✓ 数据模型是否合理（范式、性能）
-            11. ✓ API 设计是否合理（粒度、一致性）
-            12. ✓ 索引设计是否合理（查询优化）
-            13. ✓ 事务边界是否合理
-            14. ✓ 是否有性能瓶颈风险
-
-            **可行性检查**：
-            15. ✓ 是否有技术风险未识别
-            16. ✓ 数据迁移策略是否可行
-            17. ✓ 是否考虑了向后兼容性
-            18. ✓ 是否考虑了可测试性
-
-            如有问题，请指出并提供改进建议。
-            如果所有检查项都通过，请确认架构设计质量合格。
-
-          validation_process:
-            step_1: consistency_check
-            step_2: completeness_check
-            step_3: quality_check
-            step_4: feasibility_check
-            step_5: risk_assessment
-
-          quality_criteria:
-            - consistency_score: ">=9/10"
-            - completeness_score: "100%"
-            - quality_score: ">=9/10"
-            - feasibility_score: ">=8/10"
-
-          on_issues_found:
-            action: refine_architecture_design
-            max_iterations: 2
-            notes: "Architect 根据评审结果优化设计"
-
-          on_all_checks_passed:
-            action: mark_architecture_validated
-            message: "✅ 架构设计质量检查通过"
-
-          notes: |
-            Architect 自评审架构设计：
-            - 一致性：与现有架构保持一致
-            - 完整性：覆盖所有功能需求
-            - 质量：数据模型、API、索引设计合理
-            - 可行性：技术风险可控，迁移策略可行
-
-            质量标准：
-            - 一致性评分 ≥9/10
-            - 完整性 100%
-            - 质量评分 ≥9/10
-            - 可行性 ≥8/10
-
-        - step: shard_architecture_document
-          command: "*shard-doc"
-          description: "将架构文档按技术模块切分"
-          action: shard_architecture_by_modules
-          prompt_template: |
-            架构设计文档已完成，现在需要将其按技术模块切分为多个子文档，便于开发团队查阅和维护。
-
-            **源文档**：
-            docs/architecture/iteration-backend-design.md
-
-            **切分方法**：
-
-            方法一（推荐）：使用 *shard-doc 命令自动切分
-            首先，请确认源文档 docs/architecture/iteration-backend-design.md 已经存在。
-            然后执行：*shard-doc docs/architecture/iteration-backend-design.md docs/architecture
-
-            方法二（如果自动切分不满足需求）：手动按照以下策略切分
-            如果自动切分生成的文档与期望的7个模块文档不匹配，请手动创建以下文档：
-
-            1. **数据库设计** (database-design.md)
-               - 从【第2节 新增数据模型设计】提取
-               - 包含：Entity 类设计、数据表 DDL、关联关系、数据迁移策略
-               - 切分标记：`## 2. 新增数据模型设计` 到 `## 3. API 设计` 之前
-
-            2. **API 设计** (api-design.md)
-               - 从【第3节 API 设计】提取
-               - 包含：RESTful API 端点、DTO 设计、API 版本策略、集成点
-               - 切分标记：`## 3. API 设计` 到 `## 4. 服务层设计` 之前
-
-            3. **服务集成** (service-integration.md)
-               - 从【第4节 服务层设计】提取
-               - 包含：Service 接口、业务逻辑流程、事务设计、服务交互
-               - 切分标记：`## 4. 服务层设计` 到 `## 5. 技术决策` 之前
-
-            4. **迁移计划** (migration-plan.md)
-               - 从【第6节 数据库变更脚本】和【第8.3节 部署注意事项】提取
-               - 包含：数据库迁移脚本、数据迁移策略、部署步骤、回滚方案
-               - 切分标记：`## 6. 数据库变更脚本` + `### 8.3 部署注意事项`
-
-            5. **编码规范** (coding-standards.md)
-               - 从【第1节 设计概述】和【第7节 技术风险和注意事项】提取
-               - 包含：设计原则、编码约定、技术约束、注意事项
-               - 切分标记：`## 1. 设计概述` + `## 7. 技术风险和注意事项`
-
-            6. **技术栈** (tech-stack.md)
-               - 从【第1节 设计概述 - 技术选型】和【第5节 技术决策】提取
-               - 包含：框架和依赖、新技术组件、性能优化、安全策略、缓存策略
-               - 切分标记：`### 1.3 技术选型` + `## 5. 技术决策`
-
-            7. **项目结构** (project-structure.md)
-               - 从【第1节 设计概述】和【第8.1节 开发顺序建议】提取
-               - 包含：包结构、模块组织、开发顺序、集成策略
-               - 切分标记：`### 1.2 设计原则` + `### 8.1 开发顺序建议`
-
-            **切分指令**：
-            请严格按照以下映射关系进行切分：
-
-            | 目标文件 | 源章节 | 内容范围 |
-            |---------|--------|---------|
-            | database-design.md | 第2节 | 完整的数据模型设计章节 |
-            | api-design.md | 第3节 | 完整的 API 设计章节 |
-            | service-integration.md | 第4节 | 完整的服务层设计章节 |
-            | migration-plan.md | 第6节 + 第8.3节 | 数据库变更脚本 + 部署注意事项 |
-            | coding-standards.md | 第1节 + 第7节 | 设计概述 + 技术风险和注意事项 |
-            | tech-stack.md | 第1.3节 + 第5节 | 技术选型 + 技术决策 |
-            | project-structure.md | 第1.2节 + 第8.1节 | 设计原则 + 开发顺序 |
-
-            **切分要求**：
-            1. 保持每个子文档的独立性和完整性
-            2. 保留原文档的所有内容（不丢失信息）
-            3. 在每个子文档开头添加元数据和来源说明
-            4. 保持 Markdown 格式的正确性
-            5. 保留代码块、表格、列表等格式
-            6. 为每个子文档添加适当的标题和说明
-
-            **子文档模板格式**：
-            ```markdown
-            # {模块名称}
-
-            > **来源**: iteration-backend-design.md - {对应章节}
-            > **最后更新**: {日期}
-            > **状态**: Validated
-
-            ## 概述
-            简要说明本文档的范围和用途
-
-            ## {具体内容章节}
-            （从源文档提取的内容）
-            ```
-
-            **执行确认**：
-            切分完成后，请确认：
-            1. ✓ 所有7个子文档已创建
-            2. ✓ 每个子文档内容完整
-            3. ✓ 没有内容丢失
-            4. ✓ 格式正确无误
-            5. ✓ 交叉引用已更新
-
-            请开始执行 shard-doc 命令。
-
-          execution_process:
-            phase_1: load_source_architecture_document
-            phase_2: identify_section_boundaries
-            phase_3: extract_content_by_modules
-            phase_4: create_individual_module_documents
-            phase_5: add_metadata_and_headers
-            phase_6: validate_content_completeness
-            phase_7: save_sharded_documents
-
-          output_files:
-            - "docs/architecture/database-design.md"
-            - "docs/architecture/api-design.md"
-            - "docs/architecture/service-integration.md"
-            - "docs/architecture/migration-plan.md"
-            - "docs/architecture/coding-standards.md"
-            - "docs/architecture/tech-stack.md"
-            - "docs/architecture/project-structure.md"
-
-          notes: |
-            架构文档切分步骤：
-            1. 使用 shard-doc 命令
-            2. 源文档：iteration-backend-design.md
-            3. 目标目录：docs/architecture/
-            4. 按技术模块切分为7个子文档
-            5. 保持内容完整性和格式正确性
-
-            切分后的好处：
-            - 开发人员可以快速找到特定模块的设计文档
-            - 每个子文档聚焦单一技术关注点
-            - 便于团队分工和并行开发
-            - 降低文档维护的复杂度
-            - 提高文档的可读性和可用性
-
-        - step: validate_sharded_documents
-          action: verify_sharding_quality
-          prompt_template: |
-            请验证架构文档切分的质量，确认：
-
-            **完整性检查**：
-            1. ✓ docs/architecture/database-design.md 已创建
-            2. ✓ docs/architecture/api-design.md 已创建
-            3. ✓ docs/architecture/service-integration.md 已创建
-            4. ✓ docs/architecture/migration-plan.md 已创建
-            5. ✓ docs/architecture/coding-standards.md 已创建
-            6. ✓ docs/architecture/tech-stack.md 已创建
-            7. ✓ docs/architecture/project-structure.md 已创建
-
-            **内容检查**：
-            8. ✓ 每个文档包含完整的相关内容
-            9. ✓ 没有内容丢失或重复
-            10. ✓ 格式正确（Markdown、代码块、表格）
-            11. ✓ 元数据已添加（来源、日期、状态）
-
-            **可用性检查**：
-            12. ✓ 每个文档独立可读
-            13. ✓ 交叉引用清晰
-            14. ✓ 技术细节完整
-            15. ✓ 适合开发团队使用
-
-            如有问题，请指出并修正。
-            如果所有检查项都通过，请确认切分质量合格。
-
-          validation_process:
-            step_1: check_all_files_exist
-            step_2: verify_content_completeness
-            step_3: validate_markdown_format
-            step_4: check_cross_references
-            step_5: ensure_usability
-
-          on_issues_found:
-            action: fix_sharding_issues
-            max_iterations: 1
-            notes: "修正切分中的问题"
-
-          on_all_checks_passed:
-            action: mark_sharding_validated
-            message: "✅ 架构文档切分完成并验证通过"
-
-          notes: |
-            验证切分后的架构文档：
-            - 确认所有7个子文档已创建
-            - 验证内容完整性
-            - 检查格式正确性
-            - 确保开发团队可用性
-
-            质量标准：
-            - 文件完整性 100%
-            - 内容完整性 100%
-            - 格式正确性 100%
-            - 可用性 ≥9/10
-
-      validation_criteria:
-        - architecture_design_complete
-        - data_models_designed
-        - api_specifications_complete
-        - service_layer_designed
-        - database_scripts_generated
-        - risks_identified
-        - quality_self_check_passed
-        - architecture_documents_sharded
-        - seven_module_documents_created
-        - files_created:
-            - "docs/architecture/iteration-backend-design.md"
-            - "docs/architecture/db-migration-scripts.sql"
-            - "docs/architecture/database-design.md"
-            - "docs/architecture/api-design.md"
-            - "docs/architecture/service-integration.md"
-            - "docs/architecture/migration-plan.md"
-            - "docs/architecture/coding-standards.md"
-            - "docs/architecture/tech-stack.md"
-            - "docs/architecture/project-structure.md"
-
-      on_failure:
-        action: retry_architecture_design
-        max_retries: 2
-        escalation: "架构设计失败，需要人工审查 PRD 和现有架构"
-
-      on_success:
-        action: finalize_requirements_analysis
-        message: "✅ 后端架构增量设计完成，架构文档已按模块切分"
-
-      notes: |
-        Architect 后端架构增量设计的完整流程：
-        1. 执行 *agent architect 切换到架构师智能体
-        2. 加载 PRD、Epic 文档和现有架构分析
-        3. 执行 *create-backend-architecture 命令
-           - 设计新增数据模型（Entity + DDL）
-           - 设计 RESTful API（端点 + DTO）
-           - 设计 Service 层业务逻辑
-           - 做出技术决策（性能、安全、缓存）
-           - 生成数据库迁移脚本
-           - 识别技术风险
-           - 提供实施指导
-        4. 自评审架构设计质量（18项检查）
-        5. 输出架构设计文档和数据库脚本
-        6. 执行 shard-doc 切分架构文档
-           - 将 iteration-backend-design.md 按技术模块切分
-           - 生成7个子文档：database-design, api-design, service-integration,
-             migration-plan, coding-standards, tech-stack, project-structure
-        7. 验证切分质量（15项检查）
-
-        关键输出：
-        - iteration-backend-design.md：完整的架构设计文档
-        - db-migration-scripts.sql：数据库变更脚本
-        - 7个技术模块子文档：便于开发团队查阅
-
-        增量设计要点：
-        - 基于现有架构扩展
-        - 保持一致性和兼容性
-        - 关注性能和安全
-        - 提供清晰的实施路径
-        - 模块化文档便于团队协作
-
-    # ================================
-    # 完成：需求分析工作流结束
-    # ================================
-    - step: finalize_requirements_analysis_workflow
-      action: generate_completion_report
-      detailed_steps:
-        - step: generate_summary_report
-          action: create_workflow_completion_summary
-          output_file: "docs/requirements-analysis-completion-report.md"
-          report_structure:
-            section_1_overview:
-              - 工作流执行概况
-              - 总耗时
-              - 成功完成的步骤
-
-            section_2_outputs:
-              - 需求分析报告: "docs/requirements/requirements-analysis.md"
-              - 架构分析报告: "docs/architecture/current-architecture-analysis.md"
-              - PRD 文档: "docs/prd/brownfield-iteration-prd.md"
-              - Epic 文档清单: "docs/epics/Epic-*.md"
-              - 架构设计文档: "docs/architecture/iteration-backend-design.md"
-              - 数据库脚本: "docs/architecture/db-migration-scripts.sql"
-              - 架构模块文档:
-                  - 数据库设计: "docs/architecture/database-design.md"
-                  - API 设计: "docs/architecture/api-design.md"
-                  - 服务集成: "docs/architecture/service-integration.md"
-                  - 迁移计划: "docs/architecture/migration-plan.md"
-                  - 编码规范: "docs/architecture/coding-standards.md"
-                  - 技术栈: "docs/architecture/tech-stack.md"
-                  - 项目结构: "docs/architecture/project-structure.md"
-
-            section_3_next_steps:
-              - 下一阶段：用户故事创建和细化
-              - 建议使用：automated-story-development.yaml 工作流
-              - 前置条件已满足：
-                - Epic 文档已创建
-                - 数据库设计已完成
-                - 架构设计已完成
-
-            section_4_metrics:
-              - 识别的 Epic 数量
-              - 识别的数据表数量
-              - 识别的 API 端点数量
-              - 预估的用户故事数量
-
-          notes: "生成需求分析完成报告"
-
-        - step: notify_completion
-          action: display_completion_message
-          message: |
-            🎉 需求分析自动化工作流完成！
-
-            ✅ 已完成的工作：
-            1. 需求分析和澄清（Analyst）
-            2. 现有架构分析（Architect）
-            3. Brownfield PRD 创建（PM）
-            4. Epic 模块拆分（PM）
-            5. 后端架构增量设计（Architect）
-            6. 数据库迁移脚本生成
-            7. 架构文档按模块切分
-            8. 切分文档质量验证
-
-            📄 生成的文档：
-            - docs/requirements/requirements-analysis.md
-            - docs/architecture/current-architecture-analysis.md
-            - docs/prd/brownfield-iteration-prd.md
-            - docs/epics/Epic-*.md ({epic_count} 个模块)
-            - docs/architecture/iteration-backend-design.md
-            - docs/architecture/db-migration-scripts.sql
-            - docs/architecture/database-design.md (数据库设计)
-            - docs/architecture/api-design.md (API 设计)
-            - docs/architecture/service-integration.md (服务集成)
-            - docs/architecture/migration-plan.md (迁移计划)
-            - docs/architecture/coding-standards.md (编码规范)
-            - docs/architecture/tech-stack.md (技术栈)
-            - docs/architecture/project-structure.md (项目结构)
-
-            🚀 下一步：
-            可以启动 automated-story-development.yaml 工作流进行用户故事开发。
-
-            前置条件检查：
-            ✅ Epic 文档已创建
-            ✅ 数据库设计已完成
-            ✅ 架构设计已完成
-
-            准备就绪！可以开始用户故事自动化开发流程。
-
-      on_success:
-        message: "✅ 需求分析工作流成功完成"
-
-      notes: |
-        需求分析工作流完成：
-        - 生成完成报告
-        - 列出所有输出文档
-        - 提供下一步指引
-        - 确认 automated-story-development.yaml 的前置条件
-
-  # ================================
-  # 状态管理
-  # ================================
-  document_states:
-    - Draft: "文档已创建，等待验证"
-    - Validated: "文档已验证，质量合格"
-    - Approved: "文档已批准，可以使用"
-
-  # ================================
-  # 质量门控
-  # ================================
-  quality_gates:
-    architecture_analysis:
-      required_content:
-        - 技术栈清单
-        - 数据库实体清单
-        - API 模块清单
-        - 架构模式说明
-      validation_rules:
-        - 技术栈识别完整
-        - 现有数据表已列出
-        - 现有 API 已记录
-        - 编码规范已说明
-
-    prd_creation:
-      required_sections:
-        - 需求概述
-        - 功能需求详细描述
-        - 非功能需求
-        - 技术约束
-        - 数据需求
-        - API 需求
-        - 验收标准
-        - 实施计划（模块拆分建议）
-      validation_rules:
-        - 所有需求已覆盖（对照 req.txt）
-        - 技术约束与架构一致
-        - 数据库变更明确
-        - API 接口清晰
-        - 验收标准可测试
-        - 模块拆分合理
-
-    epic_sharding:
-      validation_rules:
-        - 模块范围适中（2-4周）
-        - 用户故事数量合理（5-15个）
-        - 技术设计一致
-        - 数据库变更相对独立
-        - API 端点内聚
-
-    architecture_design:
-      required_content:
-        - 数据模型设计（Entity + DDL）
-        - API 设计（端点 + DTO）
-        - Service 层设计
-        - 技术决策
-        - 数据库变更脚本
-        - 风险和注意事项
-        - 实施指导
-      validation_rules:
-        - 与现有架构一致
-        - 数据模型合理（范式、性能）
-        - API 设计符合 RESTful 规范
-        - 技术风险已识别
-        - 可测试性已考虑
-
-    architecture_sharding:
-      required_files:
-        - docs/architecture/database-design.md
-        - docs/architecture/api-design.md
-        - docs/architecture/service-integration.md
-        - docs/architecture/migration-plan.md
-        - docs/architecture/coding-standards.md
-        - docs/architecture/tech-stack.md
-        - docs/architecture/project-structure.md
-      validation_rules:
-        - 所有7个模块文档已创建
-        - 内容完整性 100%（无内容丢失）
-        - 模块文档格式规范
-        - 章节边界准确识别
-        - 模块文档独立可读
-        - 交叉引用清晰标注
-        - 元数据标题包含源文档和日期
-
-  # ================================
-  # 错误处理和重试策略
-  # ================================
-  error_handling:
-    architecture_analysis_failure:
-      max_retries: 2
-      escalation: "架构分析失败，可能需要人工检查项目结构"
-
-    prd_creation_failure:
-      max_retries: 2
-      escalation: "PRD 创建失败，需要审查 req.txt 和架构分析质量"
-
-    epic_sharding_failure:
-      max_retries: 2
-      escalation: "Epic 拆分失败，需要审查 PRD 的模块拆分建议"
-
-    architecture_design_failure:
-      max_retries: 2
-      escalation: "架构设计失败，需要人工审查 PRD 和现有架构的兼容性"
-
-    architecture_sharding_failure:
-      max_retries: 1
-      escalation: "架构文档切分失败，需要检查 iteration-backend-design.md 的章节结构"
-
-  # ================================
-  # 进度追踪
-  # ================================
-  progress_tracking:
-    metrics:
-      - architecture_analysis_completed
-      - prd_created
-      - epics_created_count
-      - architecture_design_completed
-      - architecture_sharding_completed
-      - module_documents_count
-      - total_duration
-      - identified_tables_count
-      - identified_apis_count
-      - identified_stories_count
-
-    reporting:
-      frequency: "每个主要步骤完成后"
-      format: "markdown报告"
-      location: "docs/requirements-analysis-completion-report.md"
-
-  # ================================
-  # 自动化流程图
-  # ================================
-  flow_diagram: |
-    ```mermaid
-    graph TD
-        A[开始: 需求分析自动化] --> B{前置验证}
-        B -->|失败| B1[提示缺失依赖]
-        B -->|通过| C[Analyst: 需求分析和澄清]
-
-        C --> D[生成需求分析报告]
-        D --> E[Architect: 分析现有架构]
-
-        E --> F[生成架构分析报告]
-        F --> G[PM: 创建 Brownfield PRD]
-
-        G --> H[执行 *create-brownfield-prd]
-        H --> I{PM 自检 PRD}
-        I -->|有问题| J[修复 PRD]
-        J --> I
-        I -->|通过| K[PRD 创建完成]
-
-        K --> L{识别模块清单}
-        L --> M[循环: 创建每个模块]
-        M --> N[执行 *create-epic]
-        N --> O{模块质量验证}
-        O -->|有问题| P[调整模块]
-        P --> O
-        O -->|通过| Q[模块创建完成]
-
-        Q --> R{还有模块?}
-        R -->|是| M
-        R -->|否| S[所有模块创建完成]
-
-        S --> T[Architect: 后端架构增量设计]
-        T --> U[执行 *create-backend-architecture]
-        U --> V{Architect 自评审}
-        V -->|有问题| W[优化设计]
-        W --> V
-        V -->|通过| X[架构设计完成]
-
-        X --> Y[生成数据库迁移脚本]
-        Y --> Y1[Architect: 切分架构文档]
-        Y1 --> Y2[执行 shard-doc 命令]
-        Y2 --> Y3{验证切分质量}
-        Y3 -->|有问题| Y4[调整切分]
-        Y4 --> Y3
-        Y3 -->|通过| Y5[切分完成: 7个模块文档]
-        Y5 --> Z[生成完成报告]
-        Z --> AA[🎉 需求分析完成]
-
-        style C fill:#E6E6FA
-        style E fill:#FFE4B5
-        style G fill:#ADD8E6
-        style M fill:#98FB98
-        style T fill:#FFE4B5
-        style Y1 fill:#FFE4B5
-        style AA fill:#90EE90
-    ```
-
-  # ================================
-  # 决策指导
-  # ================================
-  decision_guidance:
-    when_to_use:
-      - 现有 Java 后端项目的迭代需求开发
-      - PM 已提供 req.txt 需求文档
-      - 需要从需求到技术设计的完整自动化
-      - 需要标准化的需求分析流程
-
-    prerequisites:
-      - 现有的 Java 项目代码库
-      - req.txt 需求文档（由 PM 提供）
-      - xiaoma-core 已安装
-      - 项目基本目录结构存在
-
-    outputs:
-      - 需求分析报告
-      - 现有架构分析报告
-      - Brownfield PRD 文档
-      - Epic 模块文档（多个）
-      - 后端架构增量设计文档
-      - 数据库迁移脚本
-      - 架构模块文档（7个）:
-          - 数据库设计
-          - API 设计
-          - 服务集成
-          - 迁移计划
-          - 编码规范
-          - 技术栈
-          - 项目结构
-
-  # ================================
-  # 流程交接提示
-  # ================================
-  handoff_prompts:
-    start_workflow: "开始需求分析自动化工作流..."
-    requirements_analysis_start: "Analyst 开始需求分析和澄清..."
-    requirements_analysis_complete: "✅ 需求分析和澄清完成"
-    architecture_analysis_start: "Architect 开始分析现有架构..."
-    architecture_analysis_complete: "✅ 现有架构分析完成"
-    prd_creation_start: "PM 开始创建 Brownfield PRD..."
-    prd_created: "✅ Brownfield PRD 创建完成"
-    epic_sharding_start: "PM 开始拆分模块..."
-    epic_created: "✅ 模块 {epic_name} 创建完成"
-    all_epics_created: "✅ 所有模块创建完成"
-    architecture_design_start: "Architect 开始后端架构增量设计..."
-    architecture_design_complete: "✅ 后端架构增量设计完成"
-    architecture_sharding_start: "Architect 开始按模块切分架构文档..."
-    architecture_sharding_complete: "✅ 架构文档按模块切分完成"
-    sharding_validation_start: "开始验证切分文档质量..."
-    sharding_validation_complete: "✅ 切分文档质量验证通过"
-    workflow_complete: "🎉 需求分析自动化工作流完成！可以启动用户故事开发流程。"
-
-  # ================================
-  # 最佳实践和注意事项
-  # ================================
-  best_practices:
-    before_starting:
-      - "✅ 确保 req.txt 文件内容完整清晰"
-      - "✅ 确保项目是有效的 Java 项目"
-      - "✅ 安装 xiaoma-core 到项目"
-      - "✅ 创建必要的文档目录"
-
-    during_execution:
-      - "✅ 信任 Agent 的自动化能力"
-      - "✅ 关注质量门控的验证结果"
-      - "✅ 允许 Agent 自我修正和优化"
-      - "✅ 观察每个步骤的输出质量"
-
-    quality_focus:
-      - "✅ Architect: 架构一致性是关键"
-      - "✅ PM: PRD 需求完整性和可测试性"
-      - "✅ PM: Epic 拆分的规模和内聚性"
-      - "✅ Architect: 增量设计的兼容性和可行性"
-
-    after_completion:
-      - "✅ 审查所有生成的文档"
-      - "✅ 验证 PRD 与 req.txt 的一致性"
-      - "✅ 确认架构设计的可行性"
-      - "✅ 准备启动用户故事开发流程"
-
-  # ================================
-  # 与其他工作流的集成
-  # ================================
-  workflow_integration:
-    upstream_workflows:
-      - none: "这是需求分析的起点工作流"
-      - prerequisites:
-          - req_txt_from_pm: "PM 提供的需求文档"
-          - existing_java_project: "现有的 Java 项目代码库"
-
-    downstream_workflows:
-      - automated_story_development:
-          trigger: "需求分析完成后"
-          workflow_file: "automated-story-development.yaml"
-          prerequisites_provided:
-            - requirements_analysis: "docs/requirements/requirements-analysis.md"
-            - epic_documents: "docs/epics/Epic-*.md"
-            - database_design: "docs/architecture/iteration-backend-design.md"
-            - architecture_analysis: "docs/architecture/current-architecture-analysis.md"
-          notes: "无缝衔接到用户故事自动化开发流程"
-
-  # ================================
-  # 成功标准
-  # ================================
-  success_criteria:
-    requirements_analysis:
-      - all_requirements_extracted_from_req_txt
-      - ambiguities_clarified
-      - requirements_classified_and_structured
-      - users_and_scenarios_defined
-      - priorities_assigned
-      - dependencies_identified
-      - risks_assessed
-
-    architecture_analysis:
-      - tech_stack_fully_identified
-      - existing_entities_documented
-      - existing_apis_documented
-      - architecture_patterns_described
-
-    prd_quality:
-      - requirements_coverage: "100%"
-      - clarity_score: ">=9/10"
-      - testability_score: ">=9/10"
-      - epic_breakdown_reasonable
-
-    epic_sharding:
-      - all_epics_created
-      - epic_scope_appropriate
-      - user_stories_count_reasonable: "5-15 per epic"
-      - dependencies_clearly_defined
-
-    architecture_design:
-      - data_models_complete
-      - api_specifications_complete
-      - service_layer_designed
-      - database_scripts_generated
-      - consistency_score: ">=9/10"
-      - feasibility_score: ">=8/10"
-
-    architecture_sharding:
-      - all_seven_modules_created
-      - content_completeness: "100%"
-      - no_information_loss
-      - module_documents_independently_readable
-      - cross_references_clear
-      - metadata_headers_present
-
-    overall_workflow:
-      - all_documents_generated
-      - all_quality_gates_passed
-      - architecture_modules_sharded
-      - ready_for_story_development: true
-      - total_duration: "1.5-2.5 hours"