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

package/xiaoma-core/checklists/po-master-checklist.md

@@ -1,434 +0,0 @@
-<!-- Powered by XiaoMa™ Core -->
-
-# Product Owner (PO) Master Validation Checklist
-
-This checklist serves as a comprehensive framework for the Product Owner to validate project plans before development execution. It adapts intelligently based on project type (greenfield vs brownfield) and includes UI/UX considerations when applicable.
-
-[[LLM: INITIALIZATION INSTRUCTIONS - PO MASTER CHECKLIST
-
-PROJECT TYPE DETECTION:
-First, determine the project type by checking:
-
-1. Is this a GREENFIELD project (new from scratch)?
-   - Look for: New project initialization, no existing codebase references
-   - Check for: prd.md, architecture.md, new project setup stories
-
-2. Is this a BROWNFIELD project (enhancing existing system)?
-   - Look for: References to existing codebase, enhancement/modification language
-   - Check for: brownfield-prd.md, brownfield-architecture.md, existing system analysis
-
-3. Does the project include UI/UX components?
-   - Check for: frontend-architecture.md, UI/UX specifications, design files
-   - Look for: Frontend stories, component specifications, user interface mentions
-
-DOCUMENT REQUIREMENTS:
-Based on project type, ensure you have access to:
-
-For GREENFIELD projects:
-
-- prd.md - The Product Requirements Document
-- architecture.md - The system architecture
-- frontend-architecture.md - If UI/UX is involved
-- All epic and story definitions
-
-For BROWNFIELD projects:
-
-- brownfield-prd.md - The brownfield enhancement requirements
-- brownfield-architecture.md - The enhancement architecture
-- Existing project codebase access (CRITICAL - cannot proceed without this)
-- Current deployment configuration and infrastructure details
-- Database schemas, API documentation, monitoring setup
-
-SKIP INSTRUCTIONS:
-
-- Skip sections marked [[BROWNFIELD ONLY]] for greenfield projects
-- Skip sections marked [[GREENFIELD ONLY]] for brownfield projects
-- Skip sections marked [[UI/UX ONLY]] for backend-only projects
-- Note all skipped sections in your final report
-
-VALIDATION APPROACH:
-
-1. Deep Analysis - Thoroughly analyze each item against documentation
-2. Evidence-Based - Cite specific sections or code when validating
-3. Critical Thinking - Question assumptions and identify gaps
-4. Risk Assessment - Consider what could go wrong with each decision
-
-EXECUTION MODE:
-Ask the user if they want to work through the checklist:
-
-- Section by section (interactive mode) - Review each section, get confirmation before proceeding
-- All at once (comprehensive mode) - Complete full analysis and present report at end]]
-
-## 1. PROJECT SETUP & INITIALIZATION
-
-[[LLM: Project setup is the foundation. For greenfield, ensure clean start. For brownfield, ensure safe integration with existing system. Verify setup matches project type.]]
-
-### 1.1 Project Scaffolding [[GREENFIELD ONLY]]
-
-- [ ] Epic 1 includes explicit steps for project creation/initialization
-- [ ] If using a starter template, steps for cloning/setup are included
-- [ ] If building from scratch, all necessary scaffolding steps are defined
-- [ ] Initial README or documentation setup is included
-- [ ] Repository setup and initial commit processes are defined
-
-### 1.2 Existing System Integration [[BROWNFIELD ONLY]]
-
-- [ ] Existing project analysis has been completed and documented
-- [ ] Integration points with current system are identified
-- [ ] Development environment preserves existing functionality
-- [ ] Local testing approach validated for existing features
-- [ ] Rollback procedures defined for each integration point
-
-### 1.3 Development Environment
-
-- [ ] Local development environment setup is clearly defined
-- [ ] Required tools and versions are specified
-- [ ] Steps for installing dependencies are included
-- [ ] Configuration files are addressed appropriately
-- [ ] Development server setup is included
-
-### 1.4 Core Dependencies
-
-- [ ] All critical packages/libraries are installed early
-- [ ] Package management is properly addressed
-- [ ] Version specifications are appropriately defined
-- [ ] Dependency conflicts or special requirements are noted
-- [ ] [[BROWNFIELD ONLY]] Version compatibility with existing stack verified
-
-## 2. INFRASTRUCTURE & DEPLOYMENT
-
-[[LLM: Infrastructure must exist before use. For brownfield, must integrate with existing infrastructure without breaking it.]]
-
-### 2.1 Database & Data Store Setup
-
-- [ ] Database selection/setup occurs before any operations
-- [ ] Schema definitions are created before data operations
-- [ ] Migration strategies are defined if applicable
-- [ ] Seed data or initial data setup is included if needed
-- [ ] [[BROWNFIELD ONLY]] Database migration risks identified and mitigated
-- [ ] [[BROWNFIELD ONLY]] Backward compatibility ensured
-
-### 2.2 API & Service Configuration
-
-- [ ] API frameworks are set up before implementing endpoints
-- [ ] Service architecture is established before implementing services
-- [ ] Authentication framework is set up before protected routes
-- [ ] Middleware and common utilities are created before use
-- [ ] [[BROWNFIELD ONLY]] API compatibility with existing system maintained
-- [ ] [[BROWNFIELD ONLY]] Integration with existing authentication preserved
-
-### 2.3 Deployment Pipeline
-
-- [ ] CI/CD pipeline is established before deployment actions
-- [ ] Infrastructure as Code (IaC) is set up before use
-- [ ] Environment configurations are defined early
-- [ ] Deployment strategies are defined before implementation
-- [ ] [[BROWNFIELD ONLY]] Deployment minimizes downtime
-- [ ] [[BROWNFIELD ONLY]] Blue-green or canary deployment implemented
-
-### 2.4 Testing Infrastructure
-
-- [ ] Testing frameworks are installed before writing tests
-- [ ] Test environment setup precedes test implementation
-- [ ] Mock services or data are defined before testing
-- [ ] [[BROWNFIELD ONLY]] Regression testing covers existing functionality
-- [ ] [[BROWNFIELD ONLY]] Integration testing validates new-to-existing connections
-
-## 3. EXTERNAL DEPENDENCIES & INTEGRATIONS
-
-[[LLM: External dependencies often block progress. For brownfield, ensure new dependencies don't conflict with existing ones.]]
-
-### 3.1 Third-Party Services
-
-- [ ] Account creation steps are identified for required services
-- [ ] API key acquisition processes are defined
-- [ ] Steps for securely storing credentials are included
-- [ ] Fallback or offline development options are considered
-- [ ] [[BROWNFIELD ONLY]] Compatibility with existing services verified
-- [ ] [[BROWNFIELD ONLY]] Impact on existing integrations assessed
-
-### 3.2 External APIs
-
-- [ ] Integration points with external APIs are clearly identified
-- [ ] Authentication with external services is properly sequenced
-- [ ] API limits or constraints are acknowledged
-- [ ] Backup strategies for API failures are considered
-- [ ] [[BROWNFIELD ONLY]] Existing API dependencies maintained
-
-### 3.3 Infrastructure Services
-
-- [ ] Cloud resource provisioning is properly sequenced
-- [ ] DNS or domain registration needs are identified
-- [ ] Email or messaging service setup is included if needed
-- [ ] CDN or static asset hosting setup precedes their use
-- [ ] [[BROWNFIELD ONLY]] Existing infrastructure services preserved
-
-## 4. UI/UX CONSIDERATIONS [[UI/UX ONLY]]
-
-[[LLM: Only evaluate this section if the project includes user interface components. Skip entirely for backend-only projects.]]
-
-### 4.1 Design System Setup
-
-- [ ] UI framework and libraries are selected and installed early
-- [ ] Design system or component library is established
-- [ ] Styling approach (CSS modules, styled-components, etc.) is defined
-- [ ] Responsive design strategy is established
-- [ ] Accessibility requirements are defined upfront
-
-### 4.2 Frontend Infrastructure
-
-- [ ] Frontend build pipeline is configured before development
-- [ ] Asset optimization strategy is defined
-- [ ] Frontend testing framework is set up
-- [ ] Component development workflow is established
-- [ ] [[BROWNFIELD ONLY]] UI consistency with existing system maintained
-
-### 4.3 User Experience Flow
-
-- [ ] User journeys are mapped before implementation
-- [ ] Navigation patterns are defined early
-- [ ] Error states and loading states are planned
-- [ ] Form validation patterns are established
-- [ ] [[BROWNFIELD ONLY]] Existing user workflows preserved or migrated
-
-## 5. USER/AGENT RESPONSIBILITY
-
-[[LLM: Clear ownership prevents confusion. Ensure tasks are assigned appropriately based on what only humans can do.]]
-
-### 5.1 User Actions
-
-- [ ] User responsibilities limited to human-only tasks
-- [ ] Account creation on external services assigned to users
-- [ ] Purchasing or payment actions assigned to users
-- [ ] Credential provision appropriately assigned to users
-
-### 5.2 Developer Agent Actions
-
-- [ ] All code-related tasks assigned to developer agents
-- [ ] Automated processes identified as agent responsibilities
-- [ ] Configuration management properly assigned
-- [ ] Testing and validation assigned to appropriate agents
-
-## 6. FEATURE SEQUENCING & DEPENDENCIES
-
-[[LLM: Dependencies create the critical path. For brownfield, ensure new features don't break existing ones.]]
-
-### 6.1 Functional Dependencies
-
-- [ ] Features depending on others are sequenced correctly
-- [ ] Shared components are built before their use
-- [ ] User flows follow logical progression
-- [ ] Authentication features precede protected features
-- [ ] [[BROWNFIELD ONLY]] Existing functionality preserved throughout
-
-### 6.2 Technical Dependencies
-
-- [ ] Lower-level services built before higher-level ones
-- [ ] Libraries and utilities created before their use
-- [ ] Data models defined before operations on them
-- [ ] API endpoints defined before client consumption
-- [ ] [[BROWNFIELD ONLY]] Integration points tested at each step
-
-### 6.3 Cross-Epic Dependencies
-
-- [ ] Later epics build upon earlier epic functionality
-- [ ] No epic requires functionality from later epics
-- [ ] Infrastructure from early epics utilized consistently
-- [ ] Incremental value delivery maintained
-- [ ] [[BROWNFIELD ONLY]] Each epic maintains system integrity
-
-## 7. RISK MANAGEMENT [[BROWNFIELD ONLY]]
-
-[[LLM: This section is CRITICAL for brownfield projects. Think pessimistically about what could break.]]
-
-### 7.1 Breaking Change Risks
-
-- [ ] Risk of breaking existing functionality assessed
-- [ ] Database migration risks identified and mitigated
-- [ ] API breaking change risks evaluated
-- [ ] Performance degradation risks identified
-- [ ] Security vulnerability risks evaluated
-
-### 7.2 Rollback Strategy
-
-- [ ] Rollback procedures clearly defined per story
-- [ ] Feature flag strategy implemented
-- [ ] Backup and recovery procedures updated
-- [ ] Monitoring enhanced for new components
-- [ ] Rollback triggers and thresholds defined
-
-### 7.3 User Impact Mitigation
-
-- [ ] Existing user workflows analyzed for impact
-- [ ] User communication plan developed
-- [ ] Training materials updated
-- [ ] Support documentation comprehensive
-- [ ] Migration path for user data validated
-
-## 8. MVP SCOPE ALIGNMENT
-
-[[LLM: MVP means MINIMUM viable product. For brownfield, ensure enhancements are truly necessary.]]
-
-### 8.1 Core Goals Alignment
-
-- [ ] All core goals from PRD are addressed
-- [ ] Features directly support MVP goals
-- [ ] No extraneous features beyond MVP scope
-- [ ] Critical features prioritized appropriately
-- [ ] [[BROWNFIELD ONLY]] Enhancement complexity justified
-
-### 8.2 User Journey Completeness
-
-- [ ] All critical user journeys fully implemented
-- [ ] Edge cases and error scenarios addressed
-- [ ] User experience considerations included
-- [ ] [[UI/UX ONLY]] Accessibility requirements incorporated
-- [ ] [[BROWNFIELD ONLY]] Existing workflows preserved or improved
-
-### 8.3 Technical Requirements
-
-- [ ] All technical constraints from PRD addressed
-- [ ] Non-functional requirements incorporated
-- [ ] Architecture decisions align with constraints
-- [ ] Performance considerations addressed
-- [ ] [[BROWNFIELD ONLY]] Compatibility requirements met
-
-## 9. DOCUMENTATION & HANDOFF
-
-[[LLM: Good documentation enables smooth development. For brownfield, documentation of integration points is critical.]]
-
-### 9.1 Developer Documentation
-
-- [ ] API documentation created alongside implementation
-- [ ] Setup instructions are comprehensive
-- [ ] Architecture decisions documented
-- [ ] Patterns and conventions documented
-- [ ] [[BROWNFIELD ONLY]] Integration points documented in detail
-
-### 9.2 User Documentation
-
-- [ ] User guides or help documentation included if required
-- [ ] Error messages and user feedback considered
-- [ ] Onboarding flows fully specified
-- [ ] [[BROWNFIELD ONLY]] Changes to existing features documented
-
-### 9.3 Knowledge Transfer
-
-- [ ] [[BROWNFIELD ONLY]] Existing system knowledge captured
-- [ ] [[BROWNFIELD ONLY]] Integration knowledge documented
-- [ ] Code review knowledge sharing planned
-- [ ] Deployment knowledge transferred to operations
-- [ ] Historical context preserved
-
-## 10. POST-MVP CONSIDERATIONS
-
-[[LLM: Planning for success prevents technical debt. For brownfield, ensure enhancements don't limit future growth.]]
-
-### 10.1 Future Enhancements
-
-- [ ] Clear separation between MVP and future features
-- [ ] Architecture supports planned enhancements
-- [ ] Technical debt considerations documented
-- [ ] Extensibility points identified
-- [ ] [[BROWNFIELD ONLY]] Integration patterns reusable
-
-### 10.2 Monitoring & Feedback
-
-- [ ] Analytics or usage tracking included if required
-- [ ] User feedback collection considered
-- [ ] Monitoring and alerting addressed
-- [ ] Performance measurement incorporated
-- [ ] [[BROWNFIELD ONLY]] Existing monitoring preserved/enhanced
-
-## VALIDATION SUMMARY
-
-[[LLM: FINAL PO VALIDATION REPORT GENERATION
-
-Generate a comprehensive validation report that adapts to project type:
-
-1. Executive Summary
-   - Project type: [Greenfield/Brownfield] with [UI/No UI]
-   - Overall readiness (percentage)
-   - Go/No-Go recommendation
-   - Critical blocking issues count
-   - Sections skipped due to project type
-
-2. Project-Specific Analysis
-
-   FOR GREENFIELD:
-   - Setup completeness
-   - Dependency sequencing
-   - MVP scope appropriateness
-   - Development timeline feasibility
-
-   FOR BROWNFIELD:
-   - Integration risk level (High/Medium/Low)
-   - Existing system impact assessment
-   - Rollback readiness
-   - User disruption potential
-
-3. Risk Assessment
-   - Top 5 risks by severity
-   - Mitigation recommendations
-   - Timeline impact of addressing issues
-   - [BROWNFIELD] Specific integration risks
-
-4. MVP Completeness
-   - Core features coverage
-   - Missing essential functionality
-   - Scope creep identified
-   - True MVP vs over-engineering
-
-5. Implementation Readiness
-   - Developer clarity score (1-10)
-   - Ambiguous requirements count
-   - Missing technical details
-   - [BROWNFIELD] Integration point clarity
-
-6. Recommendations
-   - Must-fix before development
-   - Should-fix for quality
-   - Consider for improvement
-   - Post-MVP deferrals
-
-7. [BROWNFIELD ONLY] Integration Confidence
-   - Confidence in preserving existing functionality
-   - Rollback procedure completeness
-   - Monitoring coverage for integration points
-   - Support team readiness
-
-After presenting the report, ask if the user wants:
-
-- Detailed analysis of any failed sections
-- Specific story reordering suggestions
-- Risk mitigation strategies
-- [BROWNFIELD] Integration risk deep-dive]]
-
-### Category Statuses
-
-| Category                                | Status | Critical Issues |
-| --------------------------------------- | ------ | --------------- |
-| 1. Project Setup & Initialization       | _TBD_  |                 |
-| 2. Infrastructure & Deployment          | _TBD_  |                 |
-| 3. External Dependencies & Integrations | _TBD_  |                 |
-| 4. UI/UX Considerations                 | _TBD_  |                 |
-| 5. User/Agent Responsibility            | _TBD_  |                 |
-| 6. Feature Sequencing & Dependencies    | _TBD_  |                 |
-| 7. Risk Management (Brownfield)         | _TBD_  |                 |
-| 8. MVP Scope Alignment                  | _TBD_  |                 |
-| 9. Documentation & Handoff              | _TBD_  |                 |
-| 10. Post-MVP Considerations             | _TBD_  |                 |
-
-### Critical Deficiencies
-
-(To be populated during validation)
-
-### Recommendations
-
-(To be populated during validation)
-
-### Final Decision
-
-- **APPROVED**: The plan is comprehensive, properly sequenced, and ready for implementation.
-- **CONDITIONAL**: The plan requires specific adjustments before proceeding.
-- **REJECTED**: The plan requires significant revision to address critical deficiencies.

package/xiaoma-core/checklists/po-story-validation-checklist.md

@@ -1,219 +0,0 @@
-# PO故事验证检查清单
-
-## 检查清单概述
-
-本检查清单用于Product Owner验证用户故事的质量和完整性，确保故事符合业务需求并可以被开发团队正确实施。
-
-## 必填信息检查
-
-### 基础信息完整性
-
-- [ ] **用户故事**: 包含角色、行动、收益的完整描述
-- [ ] **验收标准**: 明确、可测试的验收条件
-- [ ] **优先级**: 业务优先级明确标注
-- [ ] **估算**: 开发工作量估算合理
-
-### 数据库设计相关
-
-- [ ] **相关实体**: 涉及的数据库实体全部识别
-- [ ] **数据操作**: CRUD操作类型明确定义
-- [ ] **业务规则**: 数据验证和业务约束清晰
-- [ ] **实体关系**: 与其他实体的关联关系准确
-
-### API接口规范
-
-- [ ] **端点定义**: API端点路径和HTTP方法正确
-- [ ] **请求参数**: 输入参数格式和验证规则完整
-- [ ] **响应格式**: 输出数据结构和格式明确
-- [ ] **错误处理**: 错误码和错误信息定义充分
-
-## 业务需求验证
-
-### PRD对齐检查
-
-- [ ] **需求匹配**: 故事内容与PRD需求完全对应
-- [ ] **功能边界**: 功能范围定义清晰，不超出边界
-- [ ] **业务价值**: 能够清晰表达对用户的价值
-- [ ] **用户角色**: 目标用户角色定义准确
-
-### 业务逻辑验证
-
-- [ ] **流程正确**: 业务流程逻辑正确无误
-- [ ] **规则完整**: 业务规则和约束考虑周全
-- [ ] **异常处理**: 异常和边界情况处理适当
-- [ ] **数据一致性**: 保证数据的一致性和完整性
-
-### 用户体验验证
-
-- [ ] **易用性**: 功能设计符合用户习惯
-- [ ] **可访问性**: 考虑不同用户群体的需求
-- [ ] **响应性能**: 性能要求符合用户期望
-- [ ] **错误提示**: 错误信息用户友好
-
-## 技术实现可行性
-
-### 架构兼容性
-
-- [ ] **系统架构**: 与现有系统架构兼容
-- [ ] **技术栈**: 使用的技术栈合适
-- [ ] **依赖关系**: 外部依赖关系明确
-- [ ] **扩展性**: 设计具备良好的扩展性
-
-### 数据库设计合理性
-
-- [ ] **表结构**: 数据库表结构设计合理
-- [ ] **索引策略**: 查询索引策略适当
-- [ ] **性能考虑**: 数据库操作性能可接受
-- [ ] **数据迁移**: 数据迁移方案可行
-
-### API设计规范性
-
-- [ ] **RESTful规范**: 遵循RESTful设计原则
-- [ ] **版本控制**: API版本控制策略明确
-- [ ] **安全性**: API安全认证和授权完备
-- [ ] **文档完整**: API文档详细准确
-
-## 可测试性验证
-
-### 验收标准质量
-
-- [ ] **明确性**: 验收标准表述清晰无歧义
-- [ ] **可验证**: 每个标准都可以通过测试验证
-- [ ] **完整性**: 覆盖所有主要功能点
-- [ ] **独立性**: 各个标准相互独立可单独测试
-
-### 测试场景覆盖
-
-- [ ] **正常流程**: 正常业务流程测试场景
-- [ ] **边界条件**: 边界值和临界条件测试
-- [ ] **异常情况**: 异常和错误情况处理测试
-- [ ] **性能测试**: 性能和负载测试场景
-
-### 测试数据准备
-
-- [ ] **测试数据**: 测试所需数据清晰定义
-- [ ] **数据依赖**: 数据依赖关系明确
-- [ ] **数据清理**: 测试后数据清理方案
-- [ ] **数据隐私**: 敏感数据处理符合规范
-
-## 依赖关系和风险评估
-
-### 依赖关系检查
-
-- [ ] **前置条件**: 开发前置条件全部满足
-- [ ] **依赖故事**: 依赖的其他故事状态确认
-- [ ] **外部依赖**: 外部系统和服务依赖明确
-- [ ] **资源依赖**: 所需资源和权限确认
-
-### 风险识别
-
-- [ ] **技术风险**: 技术实现风险评估
-- [ ] **业务风险**: 业务逻辑变更风险
-- [ ] **时间风险**: 开发时间估算风险
-- [ ] **质量风险**: 质量保证相关风险
-
-### 影响分析
-
-- [ ] **系统影响**: 对现有系统的影响分析
-- [ ] **数据影响**: 对现有数据的影响评估
-- [ ] **用户影响**: 对最终用户的影响评估
-- [ ] **运维影响**: 对系统运维的影响分析
-
-## 规模和复杂度评估
-
-### 故事规模检查
-
-- [ ] **适当规模**: 故事规模适合一个迭代完成
-- [ ] **原子性**: 故事不可再进一步合理拆分
-- [ ] **独立性**: 故事可以独立开发和测试
-- [ ] **价值完整**: 交付后能产生完整的业务价值
-
-### 复杂度评估
-
-- [ ] **技术复杂度**: 技术实现复杂度适中
-- [ ] **业务复杂度**: 业务逻辑复杂度可控
-- [ ] **集成复杂度**: 系统集成复杂度合理
-- [ ] **测试复杂度**: 测试验证复杂度适当
-
-## 质量标准检查
-
-### 文档质量
-
-- [ ] **语言表达**: 表述清晰准确无歧义
-- [ ] **结构完整**: 文档结构符合模板要求
-- [ ] **格式规范**: 格式和样式符合标准
-- [ ] **版本控制**: 版本信息和变更记录完整
-
-### 一致性检查
-
-- [ ] **内部一致**: 故事内部信息一致
-- [ ] **外部一致**: 与PRD和架构文档一致
-- [ ] **命名一致**: 术语和命名规范统一
-- [ ] **格式一致**: 与其他故事格式一致
-
-## 验证结果记录
-
-### 通过标准
-
-**当所有检查项都通过时**:
-
-- [ ] 更新故事状态: `Draft → Approved`
-- [ ] 记录验证通过时间: `{当前时间}`
-- [ ] 添加验证人员信息: `{PO姓名}`
-- [ ] 通知开发团队可以开始开发
-
-### 问题记录
-
-**当检查发现问题时**:
-
-- [ ] 详细记录具体问题描述
-- [ ] 标注问题的严重程度
-- [ ] 提供修复建议和指导
-- [ ] 设置重新验证的时间点
-
-### 修复跟踪
-
-- [ ] 问题修复后重新验证
-- [ ] 记录修复过程和结果
-- [ ] 确认所有问题都已解决
-- [ ] 验证修复没有引入新问题
-
-## 升级机制
-
-### 问题升级触发条件
-
-- [ ] 连续3次验证失败
-- [ ] 发现重大业务逻辑错误
-- [ ] 技术实现方案不可行
-- [ ] 涉及架构设计变更
-
-### 升级处理流程
-
-- [ ] 通知项目经理和产品经理
-- [ ] 组织相关方讨论解决方案
-- [ ] 必要时调整需求或设计
-- [ ] 重新评估故事优先级和计划
-
-## 使用说明
-
-### 验证流程
-
-1. 接收SM创建的用户故事(Draft状态)
-2. 逐项检查本清单的所有项目
-3. 记录检查结果和发现的问题
-4. 根据检查结果决定通过或修复
-5. 更新故事状态并通知相关方
-
-### 检查技巧
-
-- 站在最终用户的角度审视故事
-- 考虑功能的完整业务流程
-- 注意与其他功能的集成影响
-- 重点关注数据一致性和安全性
-
-### 常见问题
-
-- **验收标准不够具体**: 要求明确的可验证条件
-- **API设计不完整**: 确保包含完整的请求响应示例
-- **业务规则缺失**: 补充重要的业务逻辑约束
-- **依赖关系不明**: 明确前置条件和依赖的其他功能