222

bmad-core/checklists/architect-checklist.md

@@ -1,440 +1,440 @@
-<!-- Powered by BMAD™ Core -->
+<!-- 由 BMAD™ Core 驱动 -->
 
-# Architect Solution Validation Checklist
+# 架构师解决方案验证清单
 
-This checklist serves as a comprehensive framework for the Architect to validate the technical design and architecture before development execution. The Architect should systematically work through each item, ensuring the architecture is robust, scalable, secure, and aligned with the product requirements.
+本清单为架构师在开发执行前验证技术设计和架构提供了一个全面的框架。架构师应系统地审阅每个项目，确保架构的健壮性、可扩展性、安全性，并与产品需求保持一致。
 
-[[LLM: INITIALIZATION INSTRUCTIONS - REQUIRED ARTIFACTS
+[[LLM: 初始化说明 - 必要构件
 
-Before proceeding with this checklist, ensure you have access to:
+在开始使用此清单之前，请确保您能访问以下内容：
 
-1. architecture.md - The primary architecture document (check docs/architecture.md)
+1.  architecture.md - 主要架构文档 (检查 docs/architecture.md)
-2. prd.md - Product Requirements Document for requirements alignment (check docs/prd.md)
+2.  prd.md - 产品需求文档，用于需求对齐 (检查 docs/prd.md)
-3. frontend-architecture.md or fe-architecture.md - If this is a UI project (check docs/frontend-architecture.md)
+3.  frontend-architecture.md 或 fe-architecture.md - 如果是UI项目 (检查 docs/frontend-architecture.md)
-4. Any system diagrams referenced in the architecture
+4.  架构中引用的任何系统图
-5. API documentation if available
+5.  可用的API文档
-6. Technology stack details and version specifications
+6.  技术栈详情和版本规范
 
-IMPORTANT: If any required documents are missing or inaccessible, immediately ask the user for their location or content before proceeding.
+重要提示：如果任何所需文件缺失或无法访问，请在继续之前立即向用户询问其位置或内容。
 
-PROJECT TYPE DETECTION:
+项目类型检测：
-First, determine the project type by checking:
+首先，通过检查以下内容来确定项目类型：
 
-- Does the architecture include a frontend/UI component?
+- 架构是否包含前端/UI组件？
-- Is there a frontend-architecture.md document?
+- 是否有 frontend-architecture.md 文档？
-- Does the PRD mention user interfaces or frontend requirements?
+- PRD是否提及用户界面或前端需求？
 
-If this is a backend-only or service-only project:
+如果这是一个仅后端或仅服务的项目：
 
-- Skip sections marked with [[FRONTEND ONLY]]
+- 跳过标有 [[仅前端]] 的部分
-- Focus extra attention on API design, service architecture, and integration patterns
+- 特别关注API设计、服务架构和集成模式
-- Note in your final report that frontend sections were skipped due to project type
+- 在最终报告中注明由于项目类型而跳过了前端部分
 
-VALIDATION APPROACH:
+验证方法：
-For each section, you must:
+对于每个部分，您必须：
 
-1. Deep Analysis - Don't just check boxes, thoroughly analyze each item against the provided documentation
+1.  深入分析 - 不要只是勾选复选框，要根据提供的文档彻底分析每个项目
-2. Evidence-Based - Cite specific sections or quotes from the documents when validating
+2.  基于证据 - 验证时引用文档中的具体部分或引述
-3. Critical Thinking - Question assumptions and identify gaps, not just confirm what's present
+3.  批判性思维 - 质疑假设并识别差距，而不仅仅是确认已有的内容
-4. Risk Assessment - Consider what could go wrong with each architectural decision
+4.  风险评估 - 考虑每个架构决策可能出错的地方
 
-EXECUTION MODE:
+执行模式：
-Ask the user if they want to work through the checklist:
+询问用户是否希望通过以下方式审阅清单：
 
-- Section by section (interactive mode) - Review each section, present findings, get confirmation before proceeding
+- 逐节进行（互动模式） - 审阅每个部分，提出发现，在继续前获得确认
-- All at once (comprehensive mode) - Complete full analysis and present comprehensive report at end]]
+- 一次性完成（全面模式） - 完成全部分析并在最后提交综合报告]]
 
-## 1. REQUIREMENTS ALIGNMENT
+## 1. 需求对齐
 
-[[LLM: Before evaluating this section, take a moment to fully understand the product's purpose and goals from the PRD. What is the core problem being solved? Who are the users? What are the critical success factors? Keep these in mind as you validate alignment. For each item, don't just check if it's mentioned - verify that the architecture provides a concrete technical solution.]]
+[[LLM: 在评估本节之前，请花点时间从PRD中充分理解产品的目的和目标。要解决的核心问题是什么？用户是谁？关键成功因素是什么？在验证对齐性时请牢记这些。对于每个项目，不要只检查是否提及 - 验证架构是否提供了具体的技术解决方案。]]
 
-### 1.1 Functional Requirements Coverage
+### 1.1 功能性需求覆盖
 
-- [ ] Architecture supports all functional requirements in the PRD
+- [ ] 架构支持PRD中的所有功能性需求
-- [ ] Technical approaches for all epics and stories are addressed
+- [ ] 所有史诗和故事的技术方法都已解决
-- [ ] Edge cases and performance scenarios are considered
+- [ ] 已考虑边缘情况和性能场景
-- [ ] All required integrations are accounted for
+- [ ] 所有必需的集成都已考虑在内
-- [ ] User journeys are supported by the technical architecture
+- [ ] 技术架构支持用户旅程
 
-### 1.2 Non-Functional Requirements Alignment
+### 1.2 非功能性需求对齐
 
-- [ ] Performance requirements are addressed with specific solutions
+- [ ] 性能需求通过具体解决方案得到满足
-- [ ] Scalability considerations are documented with approach
+- [ ] 可扩展性考虑已记录并有相应方法
-- [ ] Security requirements have corresponding technical controls
+- [ ] 安全需求有相应的技术控制
-- [ ] Reliability and resilience approaches are defined
+- [ ] 可靠性和弹性方法已定义
-- [ ] Compliance requirements have technical implementations
+- [ ] 合规性需求有技术实现
 
-### 1.3 Technical Constraints Adherence
+### 1.3 技术约束遵守
 
-- [ ] All technical constraints from PRD are satisfied
+- [ ] 满足PRD中的所有技术约束
-- [ ] Platform/language requirements are followed
+- [ ] 遵循平台/语言要求
-- [ ] Infrastructure constraints are accommodated
+- [ ] 已适应基础设施约束
-- [ ] Third-party service constraints are addressed
+- [ ] 已解决第三方服务约束
-- [ ] Organizational technical standards are followed
+- [ ] 遵循组织技术标准
 
-## 2. ARCHITECTURE FUNDAMENTALS
+## 2. 架构基础
 
-[[LLM: Architecture clarity is crucial for successful implementation. As you review this section, visualize the system as if you were explaining it to a new developer. Are there any ambiguities that could lead to misinterpretation? Would an AI agent be able to implement this architecture without confusion? Look for specific diagrams, component definitions, and clear interaction patterns.]]
+[[LLM: 架构的清晰度对于成功实施至关重要。在审阅本节时，请想象一下您正在向新开发人员解释该系统。是否存在任何可能导致误解的模糊之处？AI代理能否在没有困惑的情况下实现此架构？寻找具体的图表、组件定义和清晰的交互模式。]]
 
-### 2.1 Architecture Clarity
+### 2.1 架构清晰度
 
-- [ ] Architecture is documented with clear diagrams
+- [ ] 架构以清晰的图表记录
-- [ ] Major components and their responsibilities are defined
+- [ ] 定义了主要组件及其职责
-- [ ] Component interactions and dependencies are mapped
+- [ ] 映射了组件交互和依赖关系
-- [ ] Data flows are clearly illustrated
+- [ ] 清晰地说明了数据流
-- [ ] Technology choices for each component are specified
+- [ ] 指定了每个组件的技术选择
 
-### 2.2 Separation of Concerns
+### 2.2 关注点分离
 
-- [ ] Clear boundaries between UI, business logic, and data layers
+- [ ] UI、业务逻辑和数据层之间有清晰的界限
-- [ ] Responsibilities are cleanly divided between components
+- [ ] 组件之间的职责划分清晰
-- [ ] Interfaces between components are well-defined
+- [ ] 组件之间的接口定义良好
-- [ ] Components adhere to single responsibility principle
+- [ ] 组件遵守单一职责原则
-- [ ] Cross-cutting concerns (logging, auth, etc.) are properly addressed
+- [ ] 横切关注点（日志、认证等）得到妥善处理
 
-### 2.3 Design Patterns & Best Practices
+### 2.3 设计模式与最佳实践
 
-- [ ] Appropriate design patterns are employed
+- [ ] 采用了适当的设计模式
-- [ ] Industry best practices are followed
+- [ ] 遵循了行业最佳实践
-- [ ] Anti-patterns are avoided
+- [ ] 避免了反模式
-- [ ] Consistent architectural style throughout
+- [ ] 整个架构风格一致
-- [ ] Pattern usage is documented and explained
+- [ ] 模式的使用已记录和解释
 
-### 2.4 Modularity & Maintainability
+### 2.4 模块化与可维护性
 
-- [ ] System is divided into cohesive, loosely-coupled modules
+- [ ] 系统被划分为内聚、松耦合的模块
-- [ ] Components can be developed and tested independently
+- [ ] 组件可以独立开发和测试
-- [ ] Changes can be localized to specific components
+- [ ] 变更可以本地化到特定组件
-- [ ] Code organization promotes discoverability
+- [ ] 代码组织促进可发现性
-- [ ] Architecture specifically designed for AI agent implementation
+- [ ] 专为AI代理实现而设计的架构
 
-## 3. TECHNICAL STACK & DECISIONS
+## 3. 技术栈与决策
 
-[[LLM: Technology choices have long-term implications. For each technology decision, consider: Is this the simplest solution that could work? Are we over-engineering? Will this scale? What are the maintenance implications? Are there security vulnerabilities in the chosen versions? Verify that specific versions are defined, not ranges.]]
+[[LLM: 技术选择具有长期影响。对于每个技术决策，请考虑：这是可行的最简单解决方案吗？我们是否过度设计了？这能扩展吗？维护 implications 是什么？所选版本是否存在安全漏洞？验证定义的版本是特定的，而不是范围。]]
 
-### 3.1 Technology Selection
+### 3.1 技术选型
 
-- [ ] Selected technologies meet all requirements
+- [ ] 所选技术满足所有要求
-- [ ] Technology versions are specifically defined (not ranges)
+- [ ] 技术版本已明确定义（非范围）
-- [ ] Technology choices are justified with clear rationale
+- [ ] 技术选择有明确的理由
-- [ ] Alternatives considered are documented with pros/cons
+- [ ] 记录了考虑的备选方案及其优缺点
-- [ ] Selected stack components work well together
+- [ ] 所选堆栈组件协同工作良好
 
-### 3.2 Frontend Architecture [[FRONTEND ONLY]]
+### 3.2 前端架构 [[仅前端]]
 
-[[LLM: Skip this entire section if this is a backend-only or service-only project. Only evaluate if the project includes a user interface.]]
+[[LLM: 如果这是仅后端或仅服务的项目，请跳过整个部分。仅当项目包含用户界面时才进行评估。]]
 
-- [ ] UI framework and libraries are specifically selected
+- [ ] UI框架和库已明确选择
-- [ ] State management approach is defined
+- [ ] 状态管理方法已定义
-- [ ] Component structure and organization is specified
+- [ ] 组件结构和组织已指定
-- [ ] Responsive/adaptive design approach is outlined
+- [ ] 响应式/自适应设计方法已概述
-- [ ] Build and bundling strategy is determined
+- [ ] 构建和打包策略已确定
 
-### 3.3 Backend Architecture
+### 3.3 后端架构
 
-- [ ] API design and standards are defined
+- [ ] API设计和标准已定义
-- [ ] Service organization and boundaries are clear
+- [ ] 服务组织和边界清晰
-- [ ] Authentication and authorization approach is specified
+- [ ] 认证和授权方法已指定
-- [ ] Error handling strategy is outlined
+- [ ] 错误处理策略已概述
-- [ ] Backend scaling approach is defined
+- [ ] 后端扩展方法已定义
 
-### 3.4 Data Architecture
+### 3.4 数据架构
 
-- [ ] Data models are fully defined
+- [ ] 数据模型已完全定义
-- [ ] Database technologies are selected with justification
+- [ ] 数据库技术已选择并有理由
-- [ ] Data access patterns are documented
+- [ ] 数据访问模式已记录
-- [ ] Data migration/seeding approach is specified
+- [ ] 数据迁移/种子方法已指定
-- [ ] Data backup and recovery strategies are outlined
+- [ ] 数据备份和恢复策略已概述
 
-## 4. FRONTEND DESIGN & IMPLEMENTATION [[FRONTEND ONLY]]
+## 4. 前端设计与实现 [[仅前端]]
 
-[[LLM: This entire section should be skipped for backend-only projects. Only evaluate if the project includes a user interface. When evaluating, ensure alignment between the main architecture document and the frontend-specific architecture document.]]
+[[LLM: 对于仅后端的项目，应跳过整个部分。仅当项目包含用户界面时才进行评估。评估时，请确保主架构文档和特定于前端的架构文档之间的一致性。]]
 
-### 4.1 Frontend Philosophy & Patterns
+### 4.1 前端理念与模式
 
-- [ ] Framework & Core Libraries align with main architecture document
+- [ ] 框架和核心库与主架构文档一致
-- [ ] Component Architecture (e.g., Atomic Design) is clearly described
+- [ ] 组件架构（例如，原子设计）有清晰描述
-- [ ] State Management Strategy is appropriate for application complexity
+- [ ] 状态管理策略适合应用程序复杂性
-- [ ] Data Flow patterns are consistent and clear
+- [ ] 数据流模式一致且清晰
-- [ ] Styling Approach is defined and tooling specified
+- [ ] 样式方法已定义并指定了工具
 
-### 4.2 Frontend Structure & Organization
+### 4.2 前端结构与组织
 
-- [ ] Directory structure is clearly documented with ASCII diagram
+- [ ] 目录结构以ASCII图清晰记录
-- [ ] Component organization follows stated patterns
+- [ ] 组件组织遵循所述模式
-- [ ] File naming conventions are explicit
+- [ ] 文件命名约定明确
-- [ ] Structure supports chosen framework's best practices
+- [ ] 结构支持所选框架的最佳实践
-- [ ] Clear guidance on where new components should be placed
+- [ ] 关于新组件应放置位置的明确指导
 
-### 4.3 Component Design
+### 4.3 组件设计
 
-- [ ] Component template/specification format is defined
+- [ ] 定义了组件模板/规范格式
-- [ ] Component props, state, and events are well-documented
+- [ ] 组件的props、state和events有详细文档
-- [ ] Shared/foundational components are identified
+- [ ] 已识别共享/基础组件
-- [ ] Component reusability patterns are established
+- [ ] 已建立组件可重用性模式
-- [ ] Accessibility requirements are built into component design
+- [ ] 可访问性要求已内置于组件设计中
 
-### 4.4 Frontend-Backend Integration
+### 4.4 前后端集成
 
-- [ ] API interaction layer is clearly defined
+- [ ] API交互层定义清晰
-- [ ] HTTP client setup and configuration documented
+- [ ] HTTP客户端设置和配置已记录
-- [ ] Error handling for API calls is comprehensive
+- [ ] API调用的错误处理全面
-- [ ] Service definitions follow consistent patterns
+- [ ] 服务定义遵循一致模式
-- [ ] Authentication integration with backend is clear
+- [ ] 与后端的认证集成清晰
 
-### 4.5 Routing & Navigation
+### 4.5 路由与导航
 
-- [ ] Routing strategy and library are specified
+- [ ] 路由策略和库已指定
-- [ ] Route definitions table is comprehensive
+- [ ] 路由定义表全面
-- [ ] Route protection mechanisms are defined
+- [ ] 路由保护机制已定义
-- [ ] Deep linking considerations addressed
+- [ ] 已解决深层链接问题
-- [ ] Navigation patterns are consistent
+- [ ] 导航模式一致
 
-### 4.6 Frontend Performance
+### 4.6 前端性能
 
-- [ ] Image optimization strategies defined
+- [ ] 定义了图像优化策略
-- [ ] Code splitting approach documented
+- [ ] 记录了代码拆分方法
-- [ ] Lazy loading patterns established
+- [ ] 建立了延迟加载模式
-- [ ] Re-render optimization techniques specified
+- [ ] 指定了重新渲染优化技术
-- [ ] Performance monitoring approach defined
+- [ ] 定义了性能监控方法
 
-## 5. RESILIENCE & OPERATIONAL READINESS
+## 5. 弹性和运营准备
 
-[[LLM: Production systems fail in unexpected ways. As you review this section, think about Murphy's Law - what could go wrong? Consider real-world scenarios: What happens during peak load? How does the system behave when a critical service is down? Can the operations team diagnose issues at 3 AM? Look for specific resilience patterns, not just mentions of "error handling".]]
+[[LLM: 生产系统会以意想不到的方式失败。在审阅本节时，请考虑墨菲定律 - 可能会出什么问题？考虑真实世界场景：高峰负载期间会发生什么？当关键服务宕机时系统如何表现？运营团队能在凌晨3点诊断问题吗？寻找特定的弹性模式，而不仅仅是提及“错误处理”。]]
 
-### 5.1 Error Handling & Resilience
+### 5.1 错误处理与弹性
 
-- [ ] Error handling strategy is comprehensive
+- [ ] 错误处理策略全面
-- [ ] Retry policies are defined where appropriate
+- [ ] 在适当情况下定义了重试策略
-- [ ] Circuit breakers or fallbacks are specified for critical services
+- [ ] 为关键服务指定了断路器或回退机制
-- [ ] Graceful degradation approaches are defined
+- [ ] 定义了优雅降级方法
-- [ ] System can recover from partial failures
+- [ ] 系统可以从部分故障中恢复
 
-### 5.2 Monitoring & Observability
+### 5.2 监控与可观察性
 
-- [ ] Logging strategy is defined
+- [ ] 定义了日志记录策略
-- [ ] Monitoring approach is specified
+- [ ] 指定了监控方法
-- [ ] Key metrics for system health are identified
+- [ ] 确定了系统健康的关键指标
-- [ ] Alerting thresholds and strategies are outlined
+- [ ] 概述了警报阈值和策略
-- [ ] Debugging and troubleshooting capabilities are built in
+- [ ] 内置了调试和故障排除功能
 
-### 5.3 Performance & Scaling
+### 5.3 性能与扩展
 
-- [ ] Performance bottlenecks are identified and addressed
+- [ ] 已识别并解决了性能瓶颈
-- [ ] Caching strategy is defined where appropriate
+- [ ] 在适当情况下定义了缓存策略
-- [ ] Load balancing approach is specified
+- [ ] 指定了负载均衡方法
-- [ ] Horizontal and vertical scaling strategies are outlined
+- [ ] 概述了水平和垂直扩展策略
-- [ ] Resource sizing recommendations are provided
+- [ ] 提供了资源规模建议
 
-### 5.4 Deployment & DevOps
+### 5.4 部署与DevOps
 
-- [ ] Deployment strategy is defined
+- [ ] 定义了部署策略
-- [ ] CI/CD pipeline approach is outlined
+- [ ] 概述了CI/CD管道方法
-- [ ] Environment strategy (dev, staging, prod) is specified
+- [ ] 指定了环境策略（开发、预发、生产）
-- [ ] Infrastructure as Code approach is defined
+- [ ] 定义了基础设施即代码（IaC）方法
-- [ ] Rollback and recovery procedures are outlined
+- [ ] 概述了回滚和恢复程序
 
-## 6. SECURITY & COMPLIANCE
+## 6. 安全与合规
 
-[[LLM: Security is not optional. Review this section with a hacker's mindset - how could someone exploit this system? Also consider compliance: Are there industry-specific regulations that apply? GDPR? HIPAA? PCI? Ensure the architecture addresses these proactively. Look for specific security controls, not just general statements.]]
+[[LLM: 安全不是可选项。以黑客的思维方式审阅本节 - 有人会如何利用此系统？还要考虑合规性：是否有适用的行业特定法规？GDPR？HIPAA？PCI？确保架构主动解决这些问题。寻找特定的安全控制，而不仅仅是笼统的陈述。]]
 
-### 6.1 Authentication & Authorization
+### 6.1 认证与授权
 
-- [ ] Authentication mechanism is clearly defined
+- [ ] 认证机制定义清晰
-- [ ] Authorization model is specified
+- [ ] 授权模型已指定
-- [ ] Role-based access control is outlined if required
+- [ ] 如果需要，概述了基于角色的访问控制
-- [ ] Session management approach is defined
+- [ ] 定义了会话管理方法
-- [ ] Credential management is addressed
+- [ ] 已解决凭证管理问题
 
-### 6.2 Data Security
+### 6.2 数据安全
 
-- [ ] Data encryption approach (at rest and in transit) is specified
+- [ ] 指定了数据加密方法（静态和传输中）
-- [ ] Sensitive data handling procedures are defined
+- [ ] 定义了敏感数据处理程序
-- [ ] Data retention and purging policies are outlined
+- [ ] 概述了数据保留和清除策略
-- [ ] Backup encryption is addressed if required
+- [ ] 如果需要，已解决备份加密问题
-- [ ] Data access audit trails are specified if required
+- [ ] 如果需要，指定了数据访问审计跟踪
 
-### 6.3 API & Service Security
+### 6.3 API与服务安全
 
-- [ ] API security controls are defined
+- [ ] 定义了API安全控制
-- [ ] Rate limiting and throttling approaches are specified
+- [ ] 指定了速率限制和节流方法
-- [ ] Input validation strategy is outlined
+- [ ] 概述了输入验证策略
-- [ ] CSRF/XSS prevention measures are addressed
+- [ ] 已解决CSRF/XSS预防措施
-- [ ] Secure communication protocols are specified
+- [ ] 指定了安全通信协议
 
-### 6.4 Infrastructure Security
+### 6.4 基础设施安全
 
-- [ ] Network security design is outlined
+- [ ] 概述了网络安全设计
-- [ ] Firewall and security group configurations are specified
+- [ ] 指定了防火墙和安全组配置
-- [ ] Service isolation approach is defined
+- [ ] 定义了服务隔离方法
-- [ ] Least privilege principle is applied
+- [ ] 应用了最小权限原则
-- [ ] Security monitoring strategy is outlined
+- [ ] 概述了安全监控策略
 
-## 7. IMPLEMENTATION GUIDANCE
+## 7. 实施指南
 
-[[LLM: Clear implementation guidance prevents costly mistakes. As you review this section, imagine you're a developer starting on day one. Do they have everything they need to be productive? Are coding standards clear enough to maintain consistency across the team? Look for specific examples and patterns.]]
+[[LLM: 清晰的实施指南可防止代价高昂的错误。在审阅本节时，请想象您是第一天开始工作的开发人员。他们是否拥有高效工作所需的一切？编码标准是否足够清晰以保持团队的一致性？寻找具体的示例和模式。]]
 
-### 7.1 Coding Standards & Practices
+### 7.1 编码标准与实践
 
-- [ ] Coding standards are defined
+- [ ] 定义了编码标准
-- [ ] Documentation requirements are specified
+- [ ] 指定了文档要求
-- [ ] Testing expectations are outlined
+- [ ] 概述了测试期望
-- [ ] Code organization principles are defined
+- [ ] 定义了代码组织原则
-- [ ] Naming conventions are specified
+- [ ] 指定了命名约定
 
-### 7.2 Testing Strategy
+### 7.2 测试策略
 
-- [ ] Unit testing approach is defined
+- [ ] 定义了单元测试方法
-- [ ] Integration testing strategy is outlined
+- [ ] 概述了集成测试策略
-- [ ] E2E testing approach is specified
+- [ ] 指定了端到端（E2E）测试方法
-- [ ] Performance testing requirements are outlined
+- [ ] 概述了性能测试要求
-- [ ] Security testing approach is defined
+- [ ] 定义了安全测试方法
 
-### 7.3 Frontend Testing [[FRONTEND ONLY]]
+### 7.3 前端测试 [[仅前端]]
 
-[[LLM: Skip this subsection for backend-only projects.]]
+[[LLM: 对于仅后端的项目，跳过此小节。]]
 
-- [ ] Component testing scope and tools defined
+- [ ] 定义了组件测试范围和工具
-- [ ] UI integration testing approach specified
+- [ ] 指定了UI集成测试方法
-- [ ] Visual regression testing considered
+- [ ] 考虑了可视化回归测试
-- [ ] Accessibility testing tools identified
+- [ ] 确定了可访问性测试工具
-- [ ] Frontend-specific test data management addressed
+- [ ] 已解决特定于前端的测试数据管理
 
-### 7.4 Development Environment
+### 7.4 开发环境
 
-- [ ] Local development environment setup is documented
+- [ ] 记录了本地开发环境设置
-- [ ] Required tools and configurations are specified
+- [ ] 指定了所需工具和配置
-- [ ] Development workflows are outlined
+- [ ] 概述了开发工作流程
-- [ ] Source control practices are defined
+- [ ] 定义了源代码控制实践
-- [ ] Dependency management approach is specified
+- [ ] 指定了依赖管理方法
 
-### 7.5 Technical Documentation
+### 7.5 技术文档
 
-- [ ] API documentation standards are defined
+- [ ] 定义了API文档标准
-- [ ] Architecture documentation requirements are specified
+- [ ] 指定了架构文档要求
-- [ ] Code documentation expectations are outlined
+- [ ] 概述了代码文档期望
-- [ ] System diagrams and visualizations are included
+- [ ] 包括了系统图和可视化
-- [ ] Decision records for key choices are included
+- [ ] 包括了关键选择的决策记录
 
-## 8. DEPENDENCY & INTEGRATION MANAGEMENT
+## 8. 依赖与集成管理
 
-[[LLM: Dependencies are often the source of production issues. For each dependency, consider: What happens if it's unavailable? Is there a newer version with security patches? Are we locked into a vendor? What's our contingency plan? Verify specific versions and fallback strategies.]]
+[[LLM: 依赖项通常是生产问题的根源。对于每个依赖项，请考虑：如果它不可用会怎样？是否有带安全补丁的新版本？我们是否被供应商锁定？我们的应急计划是什么？验证特定版本和回退策略。]]
 
-### 8.1 External Dependencies
+### 8.1 外部依赖
 
-- [ ] All external dependencies are identified
+- [ ] 已识别所有外部依赖项
-- [ ] Versioning strategy for dependencies is defined
+- [ ] 定义了依赖项的版本控制策略
-- [ ] Fallback approaches for critical dependencies are specified
+- [ ] 指定了关键依赖项的回退方法
-- [ ] Licensing implications are addressed
+- [ ] 已解决许可影响
-- [ ] Update and patching strategy is outlined
+- [ ] 概述了更新和修补策略
 
-### 8.2 Internal Dependencies
+### 8.2 内部依赖
 
-- [ ] Component dependencies are clearly mapped
+- [ ] 清晰映射了组件依赖关系
-- [ ] Build order dependencies are addressed
+- [ ] 已解决构建顺序依赖关系
-- [ ] Shared services and utilities are identified
+- [ ] 已识别共享服务和实用程序
-- [ ] Circular dependencies are eliminated
+- [ ] 消除了循环依赖
-- [ ] Versioning strategy for internal components is defined
+- [ ] 定义了内部组件的版本控制策略
 
-### 8.3 Third-Party Integrations
+### 8.3 第三方集成
 
-- [ ] All third-party integrations are identified
+- [ ] 已识别所有第三方集成
-- [ ] Integration approaches are defined
+- [ ] 定义了集成方法
-- [ ] Authentication with third parties is addressed
+- [ ] 已解决与第三方的认证问题
-- [ ] Error handling for integration failures is specified
+- [- ] 指定了集成失败的错误处理
-- [ ] Rate limits and quotas are considered
+- [ ] 考虑了速率限制和配额
 
-## 9. AI AGENT IMPLEMENTATION SUITABILITY
+## 9. AI代理实施适用性
 
-[[LLM: This architecture may be implemented by AI agents. Review with extreme clarity in mind. Are patterns consistent? Is complexity minimized? Would an AI agent make incorrect assumptions? Remember: explicit is better than implicit. Look for clear file structures, naming conventions, and implementation patterns.]]
+[[LLM: 此架构可能由AI代理实施。审阅时要特别注意清晰度。模式是否一致？复杂性是否最小化？AI代理会做出错误的假设吗？记住：显式优于隐式。寻找清晰的文件结构、命名约定和实施模式。]]
 
-### 9.1 Modularity for AI Agents
+### 9.1 AI代理的模块化
 
-- [ ] Components are sized appropriately for AI agent implementation
+- [ ] 组件大小适合AI代理实施
-- [ ] Dependencies between components are minimized
+- [ ] 组件之间的依赖关系最小化
-- [ ] Clear interfaces between components are defined
+- [ ] 定义了组件之间的清晰接口
-- [ ] Components have singular, well-defined responsibilities
+- [ ] 组件具有单一、明确定义的职责
-- [ ] File and code organization optimized for AI agent understanding
+- [ ] 为AI代理理解优化了文件和代码组织
 
-### 9.2 Clarity & Predictability
+### 9.2 清晰性与可预测性
 
-- [ ] Patterns are consistent and predictable
+- [ ] 模式一致且可预测
-- [ ] Complex logic is broken down into simpler steps
+- [ ] 复杂逻辑被分解为更简单的步骤
-- [ ] Architecture avoids overly clever or obscure approaches
+- [ ] 架构避免了过于聪明或晦涩的方法
-- [ ] Examples are provided for unfamiliar patterns
+- [ ] 为不熟悉的模式提供了示例
-- [ ] Component responsibilities are explicit and clear
+- [ ] 组件职责明确清晰
 
-### 9.3 Implementation Guidance
+### 9.3 实施指南
 
-- [ ] Detailed implementation guidance is provided
+- [ ] 提供了详细的实施指南
-- [ ] Code structure templates are defined
+- [ ] 定义了代码结构模板
-- [ ] Specific implementation patterns are documented
+- [ ] 记录了具体的实施模式
-- [ ] Common pitfalls are identified with solutions
+- [ ] 识别了常见陷阱并提供了解决方案
-- [ ] References to similar implementations are provided when helpful
+- [ ] 在有帮助时提供了类似实现的参考
 
-### 9.4 Error Prevention & Handling
+### 9.4 错误预防与处理
 
-- [ ] Design reduces opportunities for implementation errors
+- [ ] 设计减少了实施错误的机会
-- [ ] Validation and error checking approaches are defined
+- [ ] 定义了验证和错误检查方法
-- [ ] Self-healing mechanisms are incorporated where possible
+- [ ] 在可能的情况下加入了自愈机制
-- [ ] Testing patterns are clearly defined
+- [ ] 清晰定义了测试模式
-- [ ] Debugging guidance is provided
+- [ ] 提供了调试指南
 
-## 10. ACCESSIBILITY IMPLEMENTATION [[FRONTEND ONLY]]
+## 10. 可访问性实施 [[仅前端]]
 
-[[LLM: Skip this section for backend-only projects. Accessibility is a core requirement for any user interface.]]
+[[LLM: 对于仅后端的项目，跳过此部分。可访问性是任何用户界面的核心要求。]]
 
-### 10.1 Accessibility Standards
+### 10.1 可访问性标准
 
-- [ ] Semantic HTML usage is emphasized
+- [ ] 强调了语义化HTML的使用
-- [ ] ARIA implementation guidelines provided
+- [ ] 提供了ARIA实施指南
-- [ ] Keyboard navigation requirements defined
+- [ ] 定义了键盘导航要求
-- [ ] Focus management approach specified
+- [ ] 指定了焦点管理方法
-- [ ] Screen reader compatibility addressed
+- [ ] 已解决屏幕阅读器兼容性问题
 
-### 10.2 Accessibility Testing
+### 10.2 可访问性测试
 
-- [ ] Accessibility testing tools identified
+- [ ] 确定了可访问性测试工具
-- [ ] Testing process integrated into workflow
+- [ ] 测试过程已集成到工作流程中
-- [ ] Compliance targets (WCAG level) specified
+- [ ] 指定了合规性目标（WCAG级别）
-- [ ] Manual testing procedures defined
+- [ ] 定义了手动测试程序
-- [ ] Automated testing approach outlined
+- [ ] 概述了自动化测试方法
 
-[[LLM: FINAL VALIDATION REPORT GENERATION
+[[LLM: 最终验证报告生成
 
-Now that you've completed the checklist, generate a comprehensive validation report that includes:
+既然您已经完成了清单，请生成一份全面的验证报告，其中包括：
 
-1. Executive Summary
+1.  执行摘要
-   - Overall architecture readiness (High/Medium/Low)
+    -   整体架构准备情况（高/中/低）
-   - Critical risks identified
+    -   识别出的关键风险
-   - Key strengths of the architecture
+    -   架构的主要优势
-   - Project type (Full-stack/Frontend/Backend) and sections evaluated
+    -   项目类型（全栈/前端/后端）和评估的部分
 
-2. Section Analysis
+2.  部分分析
-   - Pass rate for each major section (percentage of items passed)
+    -   每个主要部分的通过率（通过项目百分比）
-   - Most concerning failures or gaps
+    -   最令人担忧的失败或差距
-   - Sections requiring immediate attention
+    -   需要立即关注的部分
-   - Note any sections skipped due to project type
+    -   注明因项目类型而跳过的任何部分
 
-3. Risk Assessment
+3.  风险评估
-   - Top 5 risks by severity
+    -   按严重性排名的前5大风险
-   - Mitigation recommendations for each
+    -   每个风险的缓解建议
-   - Timeline impact of addressing issues
+    -   解决问题对时间线的影响
 
-4. Recommendations
+4.  建议
-   - Must-fix items before development
+    -   开发前必须修复的项目
-   - Should-fix items for better quality
+    -   为提高质量应修复的项目
-   - Nice-to-have improvements
+    -   可有可无的改进
 
-5. AI Implementation Readiness
+5.  AI实施准备情况
-   - Specific concerns for AI agent implementation
+    -   对AI代理实施的具体担忧
-   - Areas needing additional clarification
+    -   需要额外说明的领域
-   - Complexity hotspots to address
+    -   需要解决的复杂性热点
 
-6. Frontend-Specific Assessment (if applicable)
+6.  前端特定评估（如果适用）
-   - Frontend architecture completeness
+    -   前端架构完整性
-   - Alignment between main and frontend architecture docs
+    -   主架构和前端架构文档之间的一致性
-   - UI/UX specification coverage
+    -   UI/UX规范覆盖范围
-   - Component design clarity
+    -   组件设计清晰度
 
-After presenting the report, ask the user if they would like detailed analysis of any specific section, especially those with warnings or failures.]]
+提交报告后，询问用户是否希望对任何特定部分进行详细分析，尤其是那些有警告或失败的部分。]]

bmad-core/checklists/change-checklist.md

@@ -1,184 +1,184 @@
-<!-- Powered by BMAD™ Core -->
+<!-- 由 BMAD™ Core 驱动 -->
 
-# Change Navigation Checklist
+# 变更导航清单
 
-**Purpose:** To systematically guide the selected Agent and user through the analysis and planning required when a significant change (pivot, tech issue, missing requirement, failed story) is identified during the BMad workflow.
+**目的：** 在BMad工作流中识别出重大变更（转向、技术问题、需求缺失、故事失败）时，系统地引导选定的代理和用户进行分析和规划。
 
-**Instructions:** Review each item with the user. Mark `[x]` for completed/confirmed, `[N/A]` if not applicable, or add notes for discussion points.
+**说明：** 与用户一起审阅每个项目。标记 `[x]` 表示已完成/已确认，`[N/A]` 表示不适用，或为讨论点添加备注。
 
-[[LLM: INITIALIZATION INSTRUCTIONS - CHANGE NAVIGATION
+[[LLM: 初始化说明 - 变更导航
 
-Changes during development are inevitable, but how we handle them determines project success or failure.
+开发过程中的变更是不可避免的，但我们如何处理它们决定了项目的成败。
 
-Before proceeding, understand:
+在继续之前，请理解：
 
-1. This checklist is for SIGNIFICANT changes that affect the project direction
+1.  此清单适用于影响项目方向的重大变更。
-2. Minor adjustments within a story don't require this process
+2.  故事内的微小调整不需要此流程。
-3. The goal is to minimize wasted work while adapting to new realities
+3.  目标是在适应新现实的同时，最大限度地减少工作浪费。
-4. User buy-in is critical - they must understand and approve changes
+4.  用户认同至关重要 - 他们必须理解并批准变更。
 
-Required context:
+所需背景：
 
-- The triggering story or issue
+-   触发问题的具体故事或问题。
-- Current project state (completed stories, current epic)
+-   当前项目状态（已完成的故事、当前史诗）。
-- Access to PRD, architecture, and other key documents
+-   访问PRD、架构和其他关键文档。
-- Understanding of remaining work planned
+-   了解剩余的计划工作。
 
-APPROACH:
+方法：
-This is an interactive process with the user. Work through each section together, discussing implications and options. The user makes final decisions, but provide expert guidance on technical feasibility and impact.
+这是一个与用户的互动过程。一起逐节审阅，讨论影响和选项。用户做最终决定，但您需要提供关于技术可行性和影响的专业指导。
 
-REMEMBER: Changes are opportunities to improve, not failures. Handle them professionally and constructively.]]
+切记：变更是改进的机会，而不是失败。请专业、建设性地处理它们。]]
 
 ---
 
-## 1. Understand the Trigger & Context
+## 1. 理解触发器和背景
 
-[[LLM: Start by fully understanding what went wrong and why. Don't jump to solutions yet. Ask probing questions:
+[[LLM: 首先要完全理解哪里出了问题以及原因。不要急于寻找解决方案。提出探究性问题：
 
-- What exactly happened that triggered this review?
+-   究竟发生了什么触发了这次审查？
-- Is this a one-time issue or symptomatic of a larger problem?
+-   这是一个一次性问题还是更大问题的症状？
-- Could this have been anticipated earlier?
+-   这能更早地预见到吗？
-- What assumptions were incorrect?
+-   哪些假设是错误的？
 
-Be specific and factual, not blame-oriented.]]
+要具体、实事求是，不要指责。]]
 
-- [ ] **Identify Triggering Story:** Clearly identify the story (or stories) that revealed the issue.
+- [ ] **识别触发故事：** 清楚地识别出揭示问题的故事。
-- [ ] **Define the Issue:** Articulate the core problem precisely.
+- [ ] **定义问题：** 精确地阐明核心问题。
-  - [ ] Is it a technical limitation/dead-end?
+    - [ ] 是技术限制/死胡同吗？
-  - [ ] Is it a newly discovered requirement?
+    - [ ] 是新发现的需求吗？
-  - [ ] Is it a fundamental misunderstanding of existing requirements?
+    - [ ] 是对现有需求的根本性误解吗？
-  - [ ] Is it a necessary pivot based on feedback or new information?
+    - [ ] 是基于反馈或新信息而必须的转向吗？
-  - [ ] Is it a failed/abandoned story needing a new approach?
+    - [ ] 是一个需要新方法的失败/废弃的故事吗？
-- [ ] **Assess Initial Impact:** Describe the immediate observed consequences (e.g., blocked progress, incorrect functionality, non-viable tech).
+- [ ] **评估初步影响：** 描述直接观察到的后果（例如，进度受阻、功能不正确、技术不可行）。
-- [ ] **Gather Evidence:** Note any specific logs, error messages, user feedback, or analysis that supports the issue definition.
+- [ ] **收集证据：** 记录支持问题定义的任何具体日志、错误消息、用户反馈或分析。
 
-## 2. Epic Impact Assessment
+## 2. 史诗影响评估
 
-[[LLM: Changes ripple through the project structure. Systematically evaluate:
+[[LLM: 变更会在整个项目结构中产生连锁反应。系统地评估：
 
-1. Can we salvage the current epic with modifications?
+1.  我们能通过修改来挽救当前的史诗吗？
-2. Do future epics still make sense given this change?
+2.  考虑到这个变更，未来的史诗还有意义吗？
-3. Are we creating or eliminating dependencies?
+3.  我们是在创造还是消除了依赖关系？
-4. Does the epic sequence need reordering?
+4.  史诗的顺序需要重新排列吗？
 
-Think about both immediate and downstream effects.]]
+考虑直接和下游的影响。]]
 
-- [ ] **Analyze Current Epic:**
+- [ ] **分析当前史诗：**
-  - [ ] Can the current epic containing the trigger story still be completed?
+    - [ ] 包含触发故事的当前史诗还能完成吗？
-  - [ ] Does the current epic need modification (story changes, additions, removals)?
+    - [ ] 当前史诗需要修改吗（故事变更、增加、删除）？
-  - [ ] Should the current epic be abandoned or fundamentally redefined?
+    - [ ] 当前史诗应该被放弃还是从根本上重新定义？
-- [ ] **Analyze Future Epics:**
+- [ ] **分析未来史诗：**
-  - [ ] Review all remaining planned epics.
+    - [ ] 审查所有剩余的计划史诗。
-  - [ ] Does the issue require changes to planned stories in future epics?
+    - [ ] 该问题是否需要更改未来史诗中的计划故事？
-  - [ ] Does the issue invalidate any future epics?
+    - [ ] 该问题是否使任何未来的史诗无效？
-  - [ ] Does the issue necessitate the creation of entirely new epics?
+    - [ ] 该问题是否需要创建全新的史诗？
-  - [ ] Should the order/priority of future epics be changed?
+    - [ ] 是否应该更改未来史诗的顺序/优先级？
-- [ ] **Summarize Epic Impact:** Briefly document the overall effect on the project's epic structure and flow.
+- [ ] **总结史诗影响：** 简要记录对项目史诗结构和流程的总体影响。
 
-## 3. Artifact Conflict & Impact Analysis
+## 3. 工件冲突与影响分析
 
-[[LLM: Documentation drives development in BMad. Check each artifact:
+[[LLM: 文档驱动着BMad的开发。检查每个工件：
 
-1. Does this change invalidate documented decisions?
+1.  这个变更是否使已记录的决策无效？
-2. Are architectural assumptions still valid?
+2.  架构假设是否仍然有效？
-3. Do user flows need rethinking?
+3.  用户流程是否需要重新思考？
-4. Are technical constraints different than documented?
+4.  技术约束是否与文档记录的不同？
 
-Be thorough - missed conflicts cause future problems.]]
+要彻底——遗漏的冲突会导致未来的问题。]]
 
-- [ ] **Review PRD:**
+- [ ] **审查PRD：**
-  - [ ] Does the issue conflict with the core goals or requirements stated in the PRD?
+    - [ ] 该问题是否与PRD中陈述的核心目标或要求冲突？
-  - [ ] Does the PRD need clarification or updates based on the new understanding?
+    - [ ] PRD是否需要根据新的理解进行澄清或更新？
-- [ ] **Review Architecture Document:**
+- [ ] **审查架构文档：**
-  - [ ] Does the issue conflict with the documented architecture (components, patterns, tech choices)?
+    - [ ] 该问题是否与文档化的架构（组件、模式、技术选择）冲突？
-  - [ ] Are specific components/diagrams/sections impacted?
+    - [ ] 是否影响了特定的组件/图表/部分？
-  - [ ] Does the technology list need updating?
+    - [ ] 技术清单是否需要更新？
-  - [ ] Do data models or schemas need revision?
+    - [ ] 数据模型或模式是否需要修订？
-  - [ ] Are external API integrations affected?
+    - [ ] 是否影响了外部API集成？
-- [ ] **Review Frontend Spec (if applicable):**
+- [ ] **审查前端规范（如果适用）：**
-  - [ ] Does the issue conflict with the FE architecture, component library choice, or UI/UX design?
+    - [ ] 该问题是否与前端架构、组件库选择或UI/UX设计冲突？
-  - [ ] Are specific FE components or user flows impacted?
+    - [ ] 是否影响了特定的前端组件或用户流程？
-- [ ] **Review Other Artifacts (if applicable):**
+- [ ] **审查其他工件（如果适用）：**
-  - [ ] Consider impact on deployment scripts, IaC, monitoring setup, etc.
+    - [ ] 考虑对部署脚本、IaC、监控设置等的影响。
-- [ ] **Summarize Artifact Impact:** List all artifacts requiring updates and the nature of the changes needed.
+- [ ] **总结工件影响：** 列出所有需要更新的工件以及所需的变更性质。
 
-## 4. Path Forward Evaluation
+## 4. 前进路径评估
 
-[[LLM: Present options clearly with pros/cons. For each path:
+[[LLM: 清晰地展示选项及其优缺点。对于每条路径：
 
-1. What's the effort required?
+1.  需要多少工作量？
-2. What work gets thrown away?
+2.  哪些工作会被丢弃？
-3. What risks are we taking?
+3.  我们承担了哪些风险？
-4. How does this affect timeline?
+4.  这对时间表有何影响？
-5. Is this sustainable long-term?
+5.  这在长期内是否可持续？
 
-Be honest about trade-offs. There's rarely a perfect solution.]]
+要诚实地对待权衡。很少有完美的解决方案。]]
 
-- [ ] **Option 1: Direct Adjustment / Integration:**
+- [ ] **选项1：直接调整/集成：**
-  - [ ] Can the issue be addressed by modifying/adding future stories within the existing plan?
+    - [ ] 能否通过在现有计划内修改/添加未来的故事来解决问题？
-  - [ ] Define the scope and nature of these adjustments.
+    - [ ] 定义这些调整的范围和性质。
-  - [ ] Assess feasibility, effort, and risks of this path.
+    - [ ] 评估此路径的可行性、工作量和风险。
-- [ ] **Option 2: Potential Rollback:**
+- [ ] **选项2：潜在回滚：**
-  - [ ] Would reverting completed stories significantly simplify addressing the issue?
+    - [ ] 恢复已完成的故事是否会显著简化问题处理？
-  - [ ] Identify specific stories/commits to consider for rollback.
+    - [ ] 确定要考虑回滚的具体故事/提交。
-  - [ ] Assess the effort required for rollback.
+    - [ ] 评估回滚所需的工作量。
-  - [ ] Assess the impact of rollback (lost work, data implications).
+    - [ ] 评估回滚的影响（丢失的工作、数据影响）。
-  - [ ] Compare the net benefit/cost vs. Direct Adjustment.
+    - [ ] 比较与直接调整的净收益/成本。
-- [ ] **Option 3: PRD MVP Review & Potential Re-scoping:**
+- [ ] **选项3：PRD MVP审查与潜在范围重定：**
-  - [ ] Is the original PRD MVP still achievable given the issue and constraints?
+    - [ ] 考虑到问题和约束，最初的PRD MVP是否仍可实现？
-  - [ ] Does the MVP scope need reduction (removing features/epics)?
+    - [ ] MVP范围是否需要缩减（移除功能/史诗）？
-  - [ ] Do the core MVP goals need modification?
+    - [ ] 核心MVP目标是否需要修改？
-  - [ ] Are alternative approaches needed to meet the original MVP intent?
+    - [ ] 是否需要替代方法来满足最初的MVP意图？
-  - [ ] **Extreme Case:** Does the issue necessitate a fundamental replan or potentially a new PRD V2 (to be handled by PM)?
+    - [ ] **极端情况：** 该问题是否需要根本性的重新规划或可能需要一个新的PRD V2（由PM处理）？
-- [ ] **Select Recommended Path:** Based on the evaluation, agree on the most viable path forward.
+- [ ] **选择推荐路径：** 基于评估，就最可行的前进路径达成一致。
 
-## 5. Sprint Change Proposal Components
+## 5. 冲刺变更提案组件
 
-[[LLM: The proposal must be actionable and clear. Ensure:
+[[LLM: 提案必须是可操作且清晰的。确保：
 
-1. The issue is explained in plain language
+1.  问题用通俗易懂的语言解释。
-2. Impacts are quantified where possible
+2.  影响在可能的情况下被量化。
-3. The recommended path has clear rationale
+3.  推荐的路径有明确的理由。
-4. Next steps are specific and assigned
+4.  下一步是具体且已分配的。
-5. Success criteria for the change are defined
+5.  定义了变更的成功标准。
 
-This proposal guides all subsequent work.]]
+该提案指导所有后续工作。]]
 
-(Ensure all agreed-upon points from previous sections are captured in the proposal)
+（确保所有先前章节中达成一致的要点都已在提案中体现）
 
-- [ ] **Identified Issue Summary:** Clear, concise problem statement.
+- [ ] **已识别问题摘要：** 清晰、简洁的问题陈述。
-- [ ] **Epic Impact Summary:** How epics are affected.
+- [ ] **史诗影响摘要：** 史诗受影响的方式。
-- [ ] **Artifact Adjustment Needs:** List of documents to change.
+- [ ] **工件调整需求：** 需要更改的文档列表。
-- [ ] **Recommended Path Forward:** Chosen solution with rationale.
+- [ ] **推荐的前进路径：** 选择的解决方案及理由。
-- [ ] **PRD MVP Impact:** Changes to scope/goals (if any).
+- [ ] **PRD MVP影响：** 范围/目标的变更（如有）。
-- [ ] **High-Level Action Plan:** Next steps for stories/updates.
+- [ ] **高层行动计划：** 故事/更新的下一步。
-- [ ] **Agent Handoff Plan:** Identify roles needed (PM, Arch, Design Arch, PO).
+- [ ] **代理交接计划：** 确定所需的角色（PM、架构师、设计架构师、PO）。
 
-## 6. Final Review & Handoff
+## 6. 最终审查与交接
 
-[[LLM: Changes require coordination. Before concluding:
+[[LLM: 变更需要协调。在结束之前：
 
-1. Is the user fully aligned with the plan?
+1.  用户是否完全同意该计划？
-2. Do all stakeholders understand the impacts?
+2.  所有利益相关者是否都理解其影响？
-3. Are handoffs to other agents clear?
+3.  向其他代理的交接是否清晰？
-4. Is there a rollback plan if the change fails?
+4.  如果变更失败，是否有回滚计划？
-5. How will we validate the change worked?
+5.  我们将如何验证变更是否成功？
 
-Get explicit approval - implicit agreement causes problems.
+获得明确的批准——默许的同意会导致问题。
 
-FINAL REPORT:
+最终报告：
-After completing the checklist, provide a concise summary:
+完成清单后，提供一份简明的摘要：
 
-- What changed and why
+-   什么变了，为什么变。
-- What we're doing about it
+-   我们对此采取什么措施。
-- Who needs to do what
+-   谁需要做什么。
-- When we'll know if it worked
+-   我们何时能知道它是否奏效。
 
-Keep it action-oriented and forward-looking.]]
+保持行动导向和前瞻性。]]
 
-- [ ] **Review Checklist:** Confirm all relevant items were discussed.
+- [ ] **审查清单：** 确认所有相关项目都已讨论。
-- [ ] **Review Sprint Change Proposal:** Ensure it accurately reflects the discussion and decisions.
+- [ ] **审查冲刺变更提案：** 确保其准确反映了讨论和决定。
-- [ ] **User Approval:** Obtain explicit user approval for the proposal.
+- [ ] **用户批准：** 获得用户对提案的明确批准。
-- [ ] **Confirm Next Steps:** Reiterate the handoff plan and the next actions to be taken by specific agents.
+- [ ] **确认下一步：** 重申交接计划和特定代理将要采取的下一步行动。
 
 ---

bmad-core/checklists/pm-checklist.md

@@ -1,372 +1,372 @@
-<!-- Powered by BMAD™ Core -->
+<!-- 由 BMAD™ Core 驱动 -->
 
-# Product Manager (PM) Requirements Checklist
+# 产品经理 (PM) 需求清单
 
-This checklist serves as a comprehensive framework to ensure the Product Requirements Document (PRD) and Epic definitions are complete, well-structured, and appropriately scoped for MVP development. The PM should systematically work through each item during the product definition process.
+本清单作为一个全面的框架，旨在确保产品需求文档 (PRD) 和史诗 (Epic) 定义是完整的、结构良好的，并且为 MVP 开发进行了适当的范围界定。产品经理应在产品定义过程中系统地审阅每个项目。
 
-[[LLM: INITIALIZATION INSTRUCTIONS - PM CHECKLIST
+[[LLM: 初始化说明 - PM 清单
 
-Before proceeding with this checklist, ensure you have access to:
+在开始使用此清单之前，请确保您能访问以下内容：
 
-1. prd.md - The Product Requirements Document (check docs/prd.md)
+1.  prd.md - 产品需求文档 (检查 docs/prd.md)
-2. Any user research, market analysis, or competitive analysis documents
+2.  任何用户研究、市场分析或竞争分析文档
-3. Business goals and strategy documents
+3.  业务目标和战略文档
-4. Any existing epic definitions or user stories
+4.  任何现有的史诗定义或用户故事
 
-IMPORTANT: If the PRD is missing, immediately ask the user for its location or content before proceeding.
+重要提示：如果 PRD 缺失，请在继续之前立即向用户询问其位置或内容。
 
-VALIDATION APPROACH:
+验证方法：
 
-1. User-Centric - Every requirement should tie back to user value
+1.  以用户为中心 - 每个需求都应回归到用户价值
-2. MVP Focus - Ensure scope is truly minimal while viable
+2.  聚焦 MVP - 确保范围在可行的同时真正最小化
-3. Clarity - Requirements should be unambiguous and testable
+3.  清晰性 - 需求应明确且可测试
-4. Completeness - All aspects of the product vision are covered
+4.  完整性 - 覆盖产品愿景的所有方面
-5. Feasibility - Requirements are technically achievable
+5.  可行性 - 需求在技术上是可实现的
 
-EXECUTION MODE:
+执行模式：
-Ask the user if they want to work through the checklist:
+询问用户是否希望通过以下方式审阅清单：
 
-- Section by section (interactive mode) - Review each section, present findings, get confirmation before proceeding
+- 逐节进行（互动模式） - 审阅每个部分，提出发现，在继续前获得确认
-- All at once (comprehensive mode) - Complete full analysis and present comprehensive report at end]]
+- 一次性完成（全面模式） - 完成全部分析并在最后提交综合报告]]
 
-## 1. PROBLEM DEFINITION & CONTEXT
+## 1. 问题定义与背景
 
-[[LLM: The foundation of any product is a clear problem statement. As you review this section:
+[[LLM: 任何产品的基石都是一个清晰的问题陈述。在审阅本节时：
 
-1. Verify the problem is real and worth solving
+1.  验证问题是真实且值得解决的
-2. Check that the target audience is specific, not "everyone"
+2.  检查目标受众是具体的，而不是“所有人”
-3. Ensure success metrics are measurable, not vague aspirations
+3.  确保成功指标是可衡量的，而不是模糊的愿望
-4. Look for evidence of user research, not just assumptions
+4.  寻找用户研究的证据，而不仅仅是假设
-5. Confirm the problem-solution fit is logical]]
+5.  确认问题-解决方案的匹配是合乎逻辑的]]
 
-### 1.1 Problem Statement
+### 1.1 问题陈述
 
-- [ ] Clear articulation of the problem being solved
+- [ ] 清晰阐述正在解决的问题
-- [ ] Identification of who experiences the problem
+- [ ] 确定谁遇到了这个问题
-- [ ] Explanation of why solving this problem matters
+- [ ] 解释为什么解决这个问题很重要
-- [ ] Quantification of problem impact (if possible)
+- [ ] 量化问题的影响（如果可能）
-- [ ] Differentiation from existing solutions
+- [ ] 与现有解决方案的差异化
 
-### 1.2 Business Goals & Success Metrics
+### 1.2 业务目标与成功指标
 
-- [ ] Specific, measurable business objectives defined
+- [ ] 定义了具体的、可衡量的业务目标
-- [ ] Clear success metrics and KPIs established
+- [ ] 建立了清晰的成功指标和 KPI
-- [ ] Metrics are tied to user and business value
+- [ ] 指标与用户和业务价值挂钩
-- [ ] Baseline measurements identified (if applicable)
+- [ ] 确定了基线测量（如果适用）
-- [ ] Timeframe for achieving goals specified
+- [ ] 指定了实现目标的时间框架
 
-### 1.3 User Research & Insights
+### 1.3 用户研究与洞察
 
-- [ ] Target user personas clearly defined
+- [ ] 清晰定义了目标用户画像
-- [ ] User needs and pain points documented
+- [ ] 记录了用户需求和痛点
-- [ ] User research findings summarized (if available)
+- [ ] 总结了用户研究发现（如果可用）
-- [ ] Competitive analysis included
+- [ ] 包括了竞争分析
-- [ ] Market context provided
+- [ ] 提供了市场背景
 
-## 2. MVP SCOPE DEFINITION
+## 2. MVP 范围定义
 
-[[LLM: MVP scope is critical - too much and you waste resources, too little and you can't validate. Check:
+[[LLM: MVP 范围至关重要——范围太大浪费资源，太小则无法验证。检查：
 
-1. Is this truly minimal? Challenge every feature
+1.  这真的是最小化的吗？挑战每一个功能
-2. Does each feature directly address the core problem?
+2.  每个功能是否都直接解决了核心问题？
-3. Are "nice-to-haves" clearly separated from "must-haves"?
+3.  “锦上添花”的功能是否与“必须拥有”的功能明确分开？
-4. Is the rationale for inclusion/exclusion documented?
+4.  包含/排除的理由是否已记录？
-5. Can you ship this in the target timeframe?]]
+5.  你能在目标时间框架内交付吗？]]
 
-### 2.1 Core Functionality
+### 2.1 核心功能
 
-- [ ] Essential features clearly distinguished from nice-to-haves
+- [ ] 基本功能与锦上添花的功能明确区分
-- [ ] Features directly address defined problem statement
+- [ ] 功能直接解决了定义的问题陈述
-- [ ] Each Epic ties back to specific user needs
+- [ ] 每个史诗都与特定的用户需求相关联
-- [ ] Features and Stories are described from user perspective
+- [ ] 从用户角度描述功能和故事
-- [ ] Minimum requirements for success defined
+- [ ] 定义了成功的最低要求
 
-### 2.2 Scope Boundaries
+### 2.2 范围边界
 
-- [ ] Clear articulation of what is OUT of scope
+- [ ] 清晰阐明什么不在范围之内
-- [ ] Future enhancements section included
+- [ ] 包括了未来的增强功能部分
-- [ ] Rationale for scope decisions documented
+- [ ] 记录了范围决策的理由
-- [ ] MVP minimizes functionality while maximizing learning
+- [ ] MVP 在最小化功能的同时最大化学习
-- [ ] Scope has been reviewed and refined multiple times
+- [ ] 范围已经过多次审查和完善
 
-### 2.3 MVP Validation Approach
+### 2.3 MVP 验证方法
 
-- [ ] Method for testing MVP success defined
+- [ ] 定义了测试 MVP 成功的方法
-- [ ] Initial user feedback mechanisms planned
+- [ ] 计划了初始用户反馈机制
-- [ ] Criteria for moving beyond MVP specified
+- [ ] 指定了超越 MVP 的标准
-- [ ] Learning goals for MVP articulated
+- [ ] 阐明了 MVP 的学习目标
-- [ ] Timeline expectations set
+- [ ] 设定了时间线预期
 
-## 3. USER EXPERIENCE REQUIREMENTS
+## 3. 用户体验需求
 
-[[LLM: UX requirements bridge user needs and technical implementation. Validate:
+[[LLM: 用户体验需求是连接用户需求和技术实现的桥梁。验证：
 
-1. User flows cover the primary use cases completely
+1.  用户流程完全覆盖了主要用例
-2. Edge cases are identified (even if deferred)
+2.  识别了边缘情况（即使已推迟）
-3. Accessibility isn't an afterthought
+3.  可访问性不是事后才考虑的
-4. Performance expectations are realistic
+4.  性能预期是现实的
-5. Error states and recovery are planned]]
+5.  计划了错误状态和恢复]]
 
-### 3.1 User Journeys & Flows
+### 3.1 用户旅程与流程
 
-- [ ] Primary user flows documented
+- [ ] 记录了主要用户流程
-- [ ] Entry and exit points for each flow identified
+- [ ] 确定了每个流程的入口和出口点
-- [ ] Decision points and branches mapped
+- [ ] 映射了决策点和分支
-- [ ] Critical path highlighted
+- [ ] 突出了关键路径
-- [ ] Edge cases considered
+- [ ] 考虑了边缘情况
 
-### 3.2 Usability Requirements
+### 3.2 可用性需求
 
-- [ ] Accessibility considerations documented
+- [ ] 记录了可访问性考虑因素
-- [ ] Platform/device compatibility specified
+- [ ] 指定了平台/设备兼容性
-- [ ] Performance expectations from user perspective defined
+- [ ] 定义了从用户角度出发的性能期望
-- [ ] Error handling and recovery approaches outlined
+- [ ] 概述了错误处理和恢复方法
-- [ ] User feedback mechanisms identified
+- [ ] 确定了用户反馈机制
 
-### 3.3 UI Requirements
+### 3.3 UI 需求
 
-- [ ] Information architecture outlined
+- [ ] 概述了信息架构
-- [ ] Critical UI components identified
+- [ ] 确定了关键 UI 组件
-- [ ] Visual design guidelines referenced (if applicable)
+- [ ] 引用了视觉设计指南（如果适用）
-- [ ] Content requirements specified
+- [ ] 指定了内容要求
-- [ ] High-level navigation structure defined
+- [ ] 定义了高层导航结构
 
-## 4. FUNCTIONAL REQUIREMENTS
+## 4. 功能性需求
 
-[[LLM: Functional requirements must be clear enough for implementation. Check:
+[[LLM: 功能性需求必须足够清晰以供实施。检查：
 
-1. Requirements focus on WHAT not HOW (no implementation details)
+1.  需求关注的是“什么”而不是“如何”（没有实现细节）
-2. Each requirement is testable (how would QA verify it?)
+2.  每个需求都是可测试的（QA 将如何验证它？）
-3. Dependencies are explicit (what needs to be built first?)
+3.  依赖关系是明确的（什么需要先构建？）
-4. Requirements use consistent terminology
+4.  需求使用一致的术语
-5. Complex features are broken into manageable pieces]]
+5.  复杂的功能被分解成可管理的部分]]
 
-### 4.1 Feature Completeness
+### 4.1 功能完整性
 
-- [ ] All required features for MVP documented
+- [ ] 记录了 MVP 所需的所有功能
-- [ ] Features have clear, user-focused descriptions
+- [ ] 功能有清晰的、以用户为中心的描述
-- [ ] Feature priority/criticality indicated
+- [ ] 指明了功能的优先级/重要性
-- [ ] Requirements are testable and verifiable
+- [ ] 需求是可测试和可验证的
-- [ ] Dependencies between features identified
+- [ ] 确定了功能之间的依赖关系
 
-### 4.2 Requirements Quality
+### 4.2 需求质量
 
-- [ ] Requirements are specific and unambiguous
+- [ ] 需求是具体且明确的
-- [ ] Requirements focus on WHAT not HOW
+- [ ] 需求关注“什么”而不是“如何”
-- [ ] Requirements use consistent terminology
+- [ ] 需求使用一致的术语
-- [ ] Complex requirements broken into simpler parts
+- [ ] 复杂的需求被分解成更简单的部分
-- [ ] Technical jargon minimized or explained
+- [ ] 技术术语被最小化或解释
 
-### 4.3 User Stories & Acceptance Criteria
+### 4.3 用户故事与验收标准
 
-- [ ] Stories follow consistent format
+- [ ] 故事遵循一致的格式
-- [ ] Acceptance criteria are testable
+- [ ] 验收标准是可测试的
-- [ ] Stories are sized appropriately (not too large)
+- [ ] 故事的大小适当（不要太大）
-- [ ] Stories are independent where possible
+- [ ] 故事在可能的情况下是独立的
-- [ ] Stories include necessary context
+- [ ] 故事包括必要的背景
-- [ ] Local testability requirements (e.g., via CLI) defined in ACs for relevant backend/data stories
+- [ ] 在相关后端/数据故事的验收标准中定义了本地可测试性要求（例如，通过 CLI）
 
-## 5. NON-FUNCTIONAL REQUIREMENTS
+## 5. 非功能性需求
 
-### 5.1 Performance Requirements
+### 5.1 性能需求
 
-- [ ] Response time expectations defined
+- [ ] 定义了响应时间期望
-- [ ] Throughput/capacity requirements specified
+- [ ] 指定了吞吐量/容量要求
-- [ ] Scalability needs documented
+- [ ] 记录了可扩展性需求
-- [ ] Resource utilization constraints identified
+- [ ] 确定了资源利用率约束
-- [ ] Load handling expectations set
+- [ ] 设定了负载处理期望
 
-### 5.2 Security & Compliance
+### 5.2 安全与合规
 
-- [ ] Data protection requirements specified
+- [ ] 指定了数据保护要求
-- [ ] Authentication/authorization needs defined
+- [ ] 定义了认证/授权需求
-- [ ] Compliance requirements documented
+- [ ] 记录了合规性要求
-- [ ] Security testing requirements outlined
+- [ ] 概述了安全测试要求
-- [ ] Privacy considerations addressed
+- [ ] 解决了隐私考虑因素
 
-### 5.3 Reliability & Resilience
+### 5.3 可靠性与弹性
 
-- [ ] Availability requirements defined
+- [ ] 定义了可用性要求
-- [ ] Backup and recovery needs documented
+- [ ] 记录了备份和恢复需求
-- [ ] Fault tolerance expectations set
+- [ ] 设定了容错期望
-- [ ] Error handling requirements specified
+- [ ] 指定了错误处理要求
-- [ ] Maintenance and support considerations included
+- [ ] 包括了维护和支持考虑因素
 
-### 5.4 Technical Constraints
+### 5.4 技术约束
 
-- [ ] Platform/technology constraints documented
+- [ ] 记录了平台/技术约束
-- [ ] Integration requirements outlined
+- [ ] 概述了集成要求
-- [ ] Third-party service dependencies identified
+- [ ] 确定了第三方服务依赖关系
-- [ ] Infrastructure requirements specified
+- [ ] 指定了基础设施要求
-- [ ] Development environment needs identified
+- [ ] 确定了开发环境需求
 
-## 6. EPIC & STORY STRUCTURE
+## 6. 史诗与故事结构
 
-### 6.1 Epic Definition
+### 6.1 史诗定义
 
-- [ ] Epics represent cohesive units of functionality
+- [ ] 史诗代表了功能内聚的单元
-- [ ] Epics focus on user/business value delivery
+- [ ] 史诗专注于用户/业务价值的交付
-- [ ] Epic goals clearly articulated
+- [ ] 清晰阐述了史诗的目标
-- [ ] Epics are sized appropriately for incremental delivery
+- [ ] 史诗的大小适合增量交付
-- [ ] Epic sequence and dependencies identified
+- [ ] 确定了史诗的顺序和依赖关系
 
-### 6.2 Story Breakdown
+### 6.2 故事分解
 
-- [ ] Stories are broken down to appropriate size
+- [ ] 故事被分解到适当的大小
-- [ ] Stories have clear, independent value
+- [ ] 故事具有清晰、独立的价值
-- [ ] Stories include appropriate acceptance criteria
+- [ ] 故事包括适当的验收标准
-- [ ] Story dependencies and sequence documented
+- [ ] 记录了故事的依赖关系和顺序
-- [ ] Stories aligned with epic goals
+- [ ] 故事与史诗目标保持一致
 
-### 6.3 First Epic Completeness
+### 6.3 第一个史诗的完整性
 
-- [ ] First epic includes all necessary setup steps
+- [ ] 第一个史诗包括所有必要的设置步骤
-- [ ] Project scaffolding and initialization addressed
+- [ ] 解决了项目脚手架和初始化问题
-- [ ] Core infrastructure setup included
+- [ ] 包括了核心基础设施设置
-- [ ] Development environment setup addressed
+- [ ] 解决了开发环境设置问题
-- [ ] Local testability established early
+- [ ] 尽早建立了本地可测试性
 
-## 7. TECHNICAL GUIDANCE
+## 7. 技术指导
 
-### 7.1 Architecture Guidance
+### 7.1 架构指导
 
-- [ ] Initial architecture direction provided
+- [ ] 提供了初步的架构方向
-- [ ] Technical constraints clearly communicated
+- [ ] 清晰传达了技术约束
-- [ ] Integration points identified
+- [ ] 确定了集成点
-- [ ] Performance considerations highlighted
+- [ ] 强调了性能考虑因素
-- [ ] Security requirements articulated
+- [ ] 阐明了安全要求
-- [ ] Known areas of high complexity or technical risk flagged for architectural deep-dive
+- [ ] 标记了已知的高度复杂或技术风险领域以进行架构深度探讨
 
-### 7.2 Technical Decision Framework
+### 7.2 技术决策框架
 
-- [ ] Decision criteria for technical choices provided
+- [ ] 提供了技术选择的决策标准
-- [ ] Trade-offs articulated for key decisions
+- [ ] 阐明了关键决策的权衡
-- [ ] Rationale for selecting primary approach over considered alternatives documented (for key design/feature choices)
+- [ ] 记录了选择主要方法而非考虑的备选方案的理由（针对关键设计/功能选择）
-- [ ] Non-negotiable technical requirements highlighted
+- [ ] 强调了不可协商的技术要求
-- [ ] Areas requiring technical investigation identified
+- [ ] 确定了需要技术调查的领域
-- [ ] Guidance on technical debt approach provided
+- [ ] 提供了关于技术债务方法的指导
 
-### 7.3 Implementation Considerations
+### 7.3 实施考虑
 
-- [ ] Development approach guidance provided
+- [ ] 提供了开发方法指导
-- [ ] Testing requirements articulated
+- [ ] 阐明了测试要求
-- [ ] Deployment expectations set
+- [ ] 设定了部署期望
-- [ ] Monitoring needs identified
+- [ ] 确定了监控需求
-- [ ] Documentation requirements specified
+- [ ] 指定了文档要求
 
-## 8. CROSS-FUNCTIONAL REQUIREMENTS
+## 8. 跨功能需求
 
-### 8.1 Data Requirements
+### 8.1 数据需求
 
-- [ ] Data entities and relationships identified
+- [ ] 确定了数据实体和关系
-- [ ] Data storage requirements specified
+- [ ] 指定了数据存储要求
-- [ ] Data quality requirements defined
+- [ ] 定义了数据质量要求
-- [ ] Data retention policies identified
+- [ ] 确定了数据保留策略
-- [ ] Data migration needs addressed (if applicable)
+- [ ] 解决了数据迁移需求（如果适用）
-- [ ] Schema changes planned iteratively, tied to stories requiring them
+- [ ] 计划了迭代式的模式变更，并与需要它们的故事相关联
 
-### 8.2 Integration Requirements
+### 8.2 集成需求
 
-- [ ] External system integrations identified
+- [ ] 确定了外部系统集成
-- [ ] API requirements documented
+- [ ] 记录了 API 要求
-- [ ] Authentication for integrations specified
+- [ ] 指定了集成的认证
-- [ ] Data exchange formats defined
+- [ ] 定义了数据交换格式
-- [ ] Integration testing requirements outlined
+- [ ] 概述了集成测试要求
 
-### 8.3 Operational Requirements
+### 8.3 运营需求
 
-- [ ] Deployment frequency expectations set
+- [ ] 设定了部署频率期望
-- [ ] Environment requirements defined
+- [ ] 定义了环境要求
-- [ ] Monitoring and alerting needs identified
+- [ ] 确定了监控和警报需求
-- [ ] Support requirements documented
+- [ ] 记录了支持要求
-- [ ] Performance monitoring approach specified
+- [ ] 指定了性能监控方法
 
-## 9. CLARITY & COMMUNICATION
+## 9. 清晰性与沟通
 
-### 9.1 Documentation Quality
+### 9.1 文档质量
 
-- [ ] Documents use clear, consistent language
+- [ ] 文档使用清晰、一致的语言
-- [ ] Documents are well-structured and organized
+- [ ] 文档结构良好、组织有序
-- [ ] Technical terms are defined where necessary
+- [ ] 在必要时定义了技术术语
-- [ ] Diagrams/visuals included where helpful
+- [ ] 在有帮助的地方包含了图表/视觉效果
-- [ ] Documentation is versioned appropriately
+- [ ] 文档已适当地版本化
 
-### 9.2 Stakeholder Alignment
+### 9.2 利益相关者对齐
 
-- [ ] Key stakeholders identified
+- [ ] 确定了关键利益相关者
-- [ ] Stakeholder input incorporated
+- [ ] 采纳了利益相关者的意见
-- [ ] Potential areas of disagreement addressed
+- [ ] 解决了潜在的分歧领域
-- [ ] Communication plan for updates established
+- [ ] 建立了更新的沟通计划
-- [ ] Approval process defined
+- [ ] 定义了审批流程
 
-## PRD & EPIC VALIDATION SUMMARY
+## PRD 与史诗验证摘要
 
-[[LLM: FINAL PM CHECKLIST REPORT GENERATION
+[[LLM: 最终 PM 清单报告生成
 
-Create a comprehensive validation report that includes:
+创建一个全面的验证报告，其中包括：
 
-1. Executive Summary
+1.  执行摘要
-   - Overall PRD completeness (percentage)
+    -   整体 PRD 完整度（百分比）
-   - MVP scope appropriateness (Too Large/Just Right/Too Small)
+    -   MVP 范围的适当性（过大/正好/过小）
-   - Readiness for architecture phase (Ready/Nearly Ready/Not Ready)
+    -   架构阶段的准备情况（准备就绪/接近就绪/未准备好）
-   - Most critical gaps or concerns
+    -   最关键的差距或担忧
 
-2. Category Analysis Table
+2.  类别分析表
-   Fill in the actual table with:
+    用以下内容填写实际表格：
-   - Status: PASS (90%+ complete), PARTIAL (60-89%), FAIL (<60%)
+    -   状态：通过 (90%+ 完成), 部分 (60-89%), 失败 (<60%)
-   - Critical Issues: Specific problems that block progress
+    -   关键问题：阻碍进展的具体问题
 
-3. Top Issues by Priority
+3.  按优先级排列的主要问题
-   - BLOCKERS: Must fix before architect can proceed
+    -   阻塞性问题：在架构师可以继续之前必须修复
-   - HIGH: Should fix for quality
+    -   高优先级：为保证质量应修复
-   - MEDIUM: Would improve clarity
+    -   中优先级：将提高清晰度
-   - LOW: Nice to have
+    -   低优先级：锦上添花
 
-4. MVP Scope Assessment
+4.  MVP 范围评估
-   - Features that might be cut for true MVP
+    -   为实现真正的 MVP 可能需要削减的功能
-   - Missing features that are essential
+    -   必不可少的缺失功能
-   - Complexity concerns
+    -   复杂性担忧
-   - Timeline realism
+    -   时间线的现实性
 
-5. Technical Readiness
+5.  技术准备情况
-   - Clarity of technical constraints
+    -   技术约束的清晰度
-   - Identified technical risks
+    -   已识别的技术风险
-   - Areas needing architect investigation
+    -   需要架构师调查的领域
 
-6. Recommendations
+6.  建议
-   - Specific actions to address each blocker
+    -   解决每个阻塞性问题的具体行动
-   - Suggested improvements
+    -   建议的改进
-   - Next steps
+    -   下一步
 
-After presenting the report, ask if the user wants:
+在提交报告后，询问用户是否需要：
 
-- Detailed analysis of any failed sections
+-   任何失败部分的详细分析
-- Suggestions for improving specific areas
+-   关于改进特定领域的建议
-- Help with refining MVP scope]]
+-   帮助完善 MVP 范围]]
 
-### Category Statuses
+### 类别状态
 
-| Category                         | Status | Critical Issues |
+| 类别 | 状态 | 关键问题 |
-| -------------------------------- | ------ | --------------- |
+| --- | --- | --- |
-| 1. Problem Definition & Context  | _TBD_  |                 |
+| 1. 问题定义与背景 | _待定_ | |
-| 2. MVP Scope Definition          | _TBD_  |                 |
+| 2. MVP 范围定义 | _待定_ | |
-| 3. User Experience Requirements  | _TBD_  |                 |
+| 3. 用户体验需求 | _待定_ | |
-| 4. Functional Requirements       | _TBD_  |                 |
+| 4. 功能性需求 | _待定_ | |
-| 5. Non-Functional Requirements   | _TBD_  |                 |
+| 5. 非功能性需求 | _待定_ | |
-| 6. Epic & Story Structure        | _TBD_  |                 |
+| 6. 史诗与故事结构 | _待定_ | |
-| 7. Technical Guidance            | _TBD_  |                 |
+| 7. 技术指导 | _待定_ | |
-| 8. Cross-Functional Requirements | _TBD_  |                 |
+| 8. 跨功能需求 | _待定_ | |
-| 9. Clarity & Communication       | _TBD_  |                 |
+| 9. 清晰性与沟通 | _待定_ | |
 
-### Critical Deficiencies
+### 关键缺陷
 
-(To be populated during validation)
+（在验证过程中填写）
 
-### Recommendations
+### 建议
 
-(To be populated during validation)
+（在验证过程中填写）
 
-### Final Decision
+### 最终决定
 
-- **READY FOR ARCHITECT**: The PRD and epics are comprehensive, properly structured, and ready for architectural design.
+- **准备好进行架构设计**：PRD 和史诗是全面的、结构合理的，并已准备好进行架构设计。
-- **NEEDS REFINEMENT**: The requirements documentation requires additional work to address the identified deficiencies.
+- **需要完善**：需求文档需要额外的工作来解决已识别的缺陷。

bmad-core/checklists/po-master-checklist.md

@@ -1,434 +1,434 @@
-<!-- Powered by BMAD™ Core -->
+<!-- 由 BMAD™ Core 驱动 -->
 
-# Product Owner (PO) Master Validation Checklist
+# 产品负责人 (PO) 主验证清单
 
-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.
+本清单为产品负责人在开发执行前验证项目计划提供了一个全面的框架。它会根据项目类型（绿地 vs 棕地）智能调整，并在适用时包含 UI/UX 考量。
 
-[[LLM: INITIALIZATION INSTRUCTIONS - PO MASTER CHECKLIST
+[[LLM: 初始化说明 - PO 主清单
 
-PROJECT TYPE DETECTION:
+项目类型检测：
-First, determine the project type by checking:
+首先，通过检查以下内容确定项目类型：
 
-1. Is this a GREENFIELD project (new from scratch)?
+1.  这是一个绿地项目（从零开始的新项目）吗？
-   - Look for: New project initialization, no existing codebase references
+    -   寻找：新项目初始化，没有现有代码库引用
-   - Check for: prd.md, architecture.md, new project setup stories
+    -   检查：prd.md, architecture.md, 新项目设置故事
 
-2. Is this a BROWNFIELD project (enhancing existing system)?
+2.  这是一个棕地项目（增强现有系统）吗？
-   - Look for: References to existing codebase, enhancement/modification language
+    -   寻找：对现有代码库的引用，增强/修改的语言
-   - Check for: brownfield-prd.md, brownfield-architecture.md, existing system analysis
+    -   检查：brownfield-prd.md, brownfield-architecture.md, 现有系统分析
 
-3. Does the project include UI/UX components?
+3.  项目是否包含 UI/UX 组件？
-   - Check for: frontend-architecture.md, UI/UX specifications, design files
+    -   检查：frontend-architecture.md, UI/UX 规范, 设计文件
-   - 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
+-   prd.md - 产品需求文档
-- architecture.md - The system architecture
+-   architecture.md - 系统架构
-- frontend-architecture.md - If UI/UX is involved
+-   frontend-architecture.md - 如果涉及 UI/UX
-- All epic and story definitions
+-   所有史诗和故事定义
 
-For BROWNFIELD projects:
+对于棕地项目：
 
-- brownfield-prd.md - The brownfield enhancement requirements
+-   brownfield-prd.md - 棕地增强需求
-- brownfield-architecture.md - The enhancement architecture
+-   brownfield-architecture.md - 增强架构
-- Existing project codebase access (CRITICAL - cannot proceed without this)
+-   现有项目代码库访问权限（关键 - 没有这个无法继续）
-- Current deployment configuration and infrastructure details
+-   当前部署配置和基础设施详情
-- Database schemas, API documentation, monitoring setup
+-   数据库模式，API 文档，监控设置
 
-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
+-   对于仅后端的项目，跳过标有 [[仅UI/UX]] 的部分
-- Note all skipped sections in your final report
+-   在最终报告中注明所有跳过的部分
 
-VALIDATION APPROACH:
+验证方法：
 
-1. Deep Analysis - Thoroughly analyze each item against documentation
+1.  深入分析 - 对照文档彻底分析每个项目
-2. Evidence-Based - Cite specific sections or code when validating
+2.  基于证据 - 验证时引用具体章节或代码
-3. Critical Thinking - Question assumptions and identify gaps
+3.  批判性思维 - 质疑假设并发现差距
-4. Risk Assessment - Consider what could go wrong with each decision
+4.  风险评估 - 考虑每个决策可能出错的地方
 
-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
+## 1. 项目设置与初始化
 
-[[LLM: Project setup is the foundation. For greenfield, ensure clean start. For brownfield, ensure safe integration with existing system. Verify setup matches project type.]]
+[[LLM: 项目设置是基础。对于绿地项目，确保干净的开始。对于棕地项目，确保与现有系统安全集成。验证设置与项目类型匹配。]]
 
-### 1.1 Project Scaffolding [[GREENFIELD ONLY]]
+### 1.1 项目脚手架 [[仅绿地]]
 
-- [ ] Epic 1 includes explicit steps for project creation/initialization
+- [ ] 史诗1包含项目创建/初始化的明确步骤
-- [ ] 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
+- [ ] 包含初始 README 或文档设置
-- [ ] Repository setup and initial commit processes are defined
+- [ ] 定义了存储库设置和初始提交过程
 
-### 1.2 Existing System Integration [[BROWNFIELD ONLY]]
+### 1.2 现有系统集成 [[仅棕地]]
 
-- [ ] 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
+### 1.3 开发环境
 
-- [ ] 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
+### 1.4 核心依赖
 
-- [ ] 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
+## 2. 基础设施与部署
 
-[[LLM: Infrastructure must exist before use. For brownfield, must integrate with existing infrastructure without breaking it.]]
+[[LLM: 基础设施必须在使用前存在。对于棕地项目，必须与现有基础设施集成而不能破坏它。]]
 
-### 2.1 Database & Data Store Setup
+### 2.1 数据库与数据存储设置
 
-- [ ] 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
+### 2.2 API 与服务配置
 
-- [ ] API frameworks are set up before implementing endpoints
+- [ ] 在实现端点之前设置 API 框架
-- [ ] 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
+- [ ] [[仅棕地]] 保持了与现有系统的 API 兼容性
-- [ ] [[BROWNFIELD ONLY]] Integration with existing authentication preserved
+- [ ] [[仅棕地]] 保留了与现有身份验证的集成
 
-### 2.3 Deployment Pipeline
+### 2.3 部署流水线
 
-- [ ] CI/CD pipeline is established before deployment actions
+- [ ] 在部署操作之前建立 CI/CD 流水线
-- [ ] Infrastructure as Code (IaC) is set up before use
+- [ ] 在使用之前设置基础设施即代码 (IaC)
-- [ ] 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
+### 2.4 测试基础设施
 
-- [ ] 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
+## 3. 外部依赖与集成
 
-[[LLM: External dependencies often block progress. For brownfield, ensure new dependencies don't conflict with existing ones.]]
+[[LLM: 外部依赖常常阻碍进度。对于棕地项目，确保新依赖不与现有依赖冲突。]]
 
-### 3.1 Third-Party Services
+### 3.1 第三方服务
 
-- [ ] Account creation steps are identified for required services
+- [ ] 确定了所需服务的帐户创建步骤
-- [ ] API key acquisition processes are defined
+- [ ] 定义了 API 密钥获取流程
-- [ ] 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
+### 3.2 外部 API
 
-- [ ] Integration points with external APIs are clearly identified
+- [ ] 明确标识了与外部 API 的集成点
-- [ ] Authentication with external services is properly sequenced
+- [ ] 正确排序了与外部服务的身份验证
-- [ ] API limits or constraints are acknowledged
+- [ ] 确认了 API 限制或约束
-- [ ] Backup strategies for API failures are considered
+- [ ] 考虑了 API 故障的备份策略
-- [ ] [[BROWNFIELD ONLY]] Existing API dependencies maintained
+- [ ] [[仅棕地]] 维护了现有的 API 依赖
 
-### 3.3 Infrastructure Services
+### 3.3 基础设施服务
 
-- [ ] Cloud resource provisioning is properly sequenced
+- [ ] 正确排序了云资源配置
-- [ ] DNS or domain registration needs are identified
+- [ ] 确定了 DNS 或域名注册需求
-- [ ] Email or messaging service setup is included if needed
+- [ ] 如果需要，包含电子邮件或消息服务设置
-- [ ] CDN or static asset hosting setup precedes their use
+- [ ] 在使用之前设置 CDN 或静态资产托管
-- [ ] [[BROWNFIELD ONLY]] Existing infrastructure services preserved
+- [ ] [[仅棕地]] 保留了现有的基础设施服务
 
-## 4. UI/UX CONSIDERATIONS [[UI/UX ONLY]]
+## 4. UI/UX 考量 [[仅UI/UX]]
 
-[[LLM: Only evaluate this section if the project includes user interface components. Skip entirely for backend-only projects.]]
+[[LLM: 仅当项目包含用户界面组件时才评估此部分。对于仅后端的项目，完全跳过。]]
 
-### 4.1 Design System Setup
+### 4.1 设计系统设置
 
-- [ ] UI framework and libraries are selected and installed early
+- [ ] 尽早选择并安装了 UI 框架和库
-- [ ] Design system or component library is established
+- [ ] 建立了设计系统或组件库
-- [ ] Styling approach (CSS modules, styled-components, etc.) is defined
+- [ ] 定义了样式方法（CSS 模块、styled-components 等）
-- [ ] Responsive design strategy is established
+- [ ] 建立了响应式设计策略
-- [ ] Accessibility requirements are defined upfront
+- [ ] 预先定义了可访问性要求
 
-### 4.2 Frontend Infrastructure
+### 4.2 前端基础设施
 
-- [ ] 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
+- [ ] [[仅棕地]] 保持了与现有系统的 UI 一致性
 
-### 4.3 User Experience Flow
+### 4.3 用户体验流程
 
-- [ ] 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
+## 5. 用户/代理责任
 
-[[LLM: Clear ownership prevents confusion. Ensure tasks are assigned appropriately based on what only humans can do.]]
+[[LLM: 清晰的所有权可以防止混淆。确保根据只有人类能做的事情适当地分配任务。]]
 
-### 5.1 User Actions
+### 5.1 用户操作
 
-- [ ] 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
+### 5.2 开发代理操作
 
-- [ ] 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
+## 6. 功能排序与依赖关系
 
-[[LLM: Dependencies create the critical path. For brownfield, ensure new features don't break existing ones.]]
+[[LLM: 依赖关系创建了关键路径。对于棕地项目，确保新功能不会破坏现有功能。]]
 
-### 6.1 Functional Dependencies
+### 6.1 功能依赖
 
-- [ ] 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
+### 6.2 技术依赖
 
-- [ ] 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
+- [ ] 在客户端使用 API 端点之前定义它们
-- [ ] [[BROWNFIELD ONLY]] Integration points tested at each step
+- [ ] [[仅棕地]] 在每个步骤都测试了集成点
 
-### 6.3 Cross-Epic Dependencies
+### 6.3 跨史诗依赖
 
-- [ ] 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]]
+## 7. 风险管理 [[仅棕地]]
 
-[[LLM: This section is CRITICAL for brownfield projects. Think pessimistically about what could break.]]
+[[LLM: 此部分对于棕地项目至关重要。悲观地思考可能出问题的地方。]]
 
-### 7.1 Breaking Change Risks
+### 7.1 重大变更风险
 
-- [ ] Risk of breaking existing functionality assessed
+- [ ] 评估了破坏现有功能的风险
-- [ ] Database migration risks identified and mitigated
+- [ ] 识别并缓解了数据库迁移风险
-- [ ] API breaking change risks evaluated
+- [ ] 评估了 API 重大变更风险
-- [ ] Performance degradation risks identified
+- [ ] 识别了性能下降风险
-- [ ] Security vulnerability risks evaluated
+- [ ] 评估了安全漏洞风险
 
-### 7.2 Rollback Strategy
+### 7.2 回滚策略
 
-- [ ] 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
+### 7.3 用户影响缓解
 
-- [ ] 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
+## 8. MVP 范围对齐
 
-[[LLM: MVP means MINIMUM viable product. For brownfield, ensure enhancements are truly necessary.]]
+[[LLM: MVP 意味着最小可行产品。对于棕地项目，确保增强功能是真正必要的。]]
 
-### 8.1 Core Goals Alignment
+### 8.1 核心目标对齐
 
-- [ ] All core goals from PRD are addressed
+- [ ] 解决了 PRD 中的所有核心目标
-- [ ] Features directly support MVP goals
+- [ ] 功能直接支持 MVP 目标
-- [ ] No extraneous features beyond MVP scope
+- [ ] 没有超出 MVP 范围的无关功能
-- [ ] Critical features prioritized appropriately
+- [ ] 适当地优先考虑了关键功能
-- [ ] [[BROWNFIELD ONLY]] Enhancement complexity justified
+- [ ] [[仅棕地]] 证明了增强的复杂性是合理的
 
-### 8.2 User Journey Completeness
+### 8.2 用户旅程完整性
 
-- [ ] All critical user journeys fully implemented
+- [ ] 完全实现了所有关键用户旅程
-- [ ] Edge cases and error scenarios addressed
+- [ ] 解决了边缘情况和错误场景
-- [ ] User experience considerations included
+- [ ] 包括了用户体验考量
-- [ ] [[UI/UX ONLY]] Accessibility requirements incorporated
+- [ ] [[仅UI/UX]] 纳入了可访问性要求
-- [ ] [[BROWNFIELD ONLY]] Existing workflows preserved or improved
+- [ ] [[仅棕地]] 保留或改进了现有工作流
 
-### 8.3 Technical Requirements
+### 8.3 技术要求
 
-- [ ] All technical constraints from PRD addressed
+- [ ] 解决了 PRD 中的所有技术约束
-- [ ] Non-functional requirements incorporated
+- [ ] 纳入了非功能性需求
-- [ ] Architecture decisions align with constraints
+- [ ] 架构决策与约束保持一致
-- [ ] Performance considerations addressed
+- [ ] 解决了性能考量
-- [ ] [[BROWNFIELD ONLY]] Compatibility requirements met
+- [ ] [[仅棕地]] 满足了兼容性要求
 
-## 9. DOCUMENTATION & HANDOFF
+## 9. 文档与交接
 
-[[LLM: Good documentation enables smooth development. For brownfield, documentation of integration points is critical.]]
+[[LLM: 好的文档可以实现顺利的开发。对于棕地项目，集成点的文档至关重要。]]
 
-### 9.1 Developer Documentation
+### 9.1 开发人员文档
 
-- [ ] API documentation created alongside implementation
+- [ ] 在实现的同时创建 API 文档
-- [ ] Setup instructions are comprehensive
+- [ ] 设置说明全面
-- [ ] Architecture decisions documented
+- [ ] 记录了架构决策
-- [ ] Patterns and conventions documented
+- [ ] 记录了模式和约定
-- [ ] [[BROWNFIELD ONLY]] Integration points documented in detail
+- [ ] [[仅棕地]] 详细记录了集成点
 
-### 9.2 User Documentation
+### 9.2 用户文档
 
-- [ ] 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
+### 9.3 知识转移
 
-- [ ] [[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
+## 10. MVP 后考量
 
-[[LLM: Planning for success prevents technical debt. For brownfield, ensure enhancements don't limit future growth.]]
+[[LLM: 为成功做规划可以防止技术债务。对于棕地项目，确保增强功能不会限制未来的增长。]]
 
-### 10.1 Future Enhancements
+### 10.1 未来增强
 
-- [ ] Clear separation between MVP and future features
+- [ ] 明确区分 MVP 和未来功能
-- [ ] Architecture supports planned enhancements
+- [ ] 架构支持计划的增强功能
-- [ ] Technical debt considerations documented
+- [ ] 记录了技术债务考量
-- [ ] Extensibility points identified
+- [ ] 确定了可扩展性点
-- [ ] [[BROWNFIELD ONLY]] Integration patterns reusable
+- [ ] [[仅棕地]] 集成模式可重用
 
-### 10.2 Monitoring & Feedback
+### 10.2 监控与反馈
 
-- [ ] 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
+[[LLM: 最终 PO 验证报告生成
 
-Generate a comprehensive validation report that adapts to project type:
+生成一份适应项目类型的全面验证报告：
 
-1. Executive Summary
+1.  执行摘要
-   - Project type: [Greenfield/Brownfield] with [UI/No UI]
+    -   项目类型：[绿地/棕地] 与 [有UI/无UI]
-   - Overall readiness (percentage)
+    -   总体准备情况（百分比）
-   - Go/No-Go recommendation
+    -   执行/不执行建议
-   - Critical blocking issues count
+    -   关键阻塞问题数量
-   - Sections skipped due to project type
+    -   因项目类型而跳过的部分
 
-2. Project-Specific Analysis
+2.  项目特定分析
 
-   FOR GREENFIELD:
+    对于绿地项目：
-   - Setup completeness
+    -   设置完整性
-   - Dependency sequencing
+    -   依赖排序
-   - MVP scope appropriateness
+    -   MVP 范围的适当性
-   - Development timeline feasibility
+    -   开发时间线的可行性
 
-   FOR BROWNFIELD:
+    对于棕地项目：
-   - Integration risk level (High/Medium/Low)
+    -   集成风险级别（高/中/低）
-   - Existing system impact assessment
+    -   现有系统影响评估
-   - Rollback readiness
+    -   回滚准备情况
-   - User disruption potential
+    -   用户中断的可能性
 
-3. Risk Assessment
+3.  风险评估
-   - Top 5 risks by severity
+    -   按严重性排名的前 5 大风险
-   - Mitigation recommendations
+    -   缓解建议
-   - Timeline impact of addressing issues
+    -   解决问题对时间线的影响
-   - [BROWNFIELD] Specific integration risks
+    -   [棕地] 具体集成风险
 
-4. MVP Completeness
+4.  MVP 完整性
-   - Core features coverage
+    -   核心功能覆盖范围
-   - Missing essential functionality
+    -   缺少的基本功能
-   - Scope creep identified
+    -   识别出的范围蔓延
-   - True MVP vs over-engineering
+    -   真正的 MVP vs 过度设计
 
-5. Implementation Readiness
+5.  实施准备情况
-   - Developer clarity score (1-10)
+    -   开发人员清晰度得分 (1-10)
-   - Ambiguous requirements count
+    -   模糊需求数量
-   - Missing technical details
+    -   缺少的技术细节
-   - [BROWNFIELD] Integration point clarity
+    -   [棕地] 集成点清晰度
 
-6. Recommendations
+6.  建议
-   - Must-fix before development
+    -   开发前必须修复
-   - Should-fix for quality
+    -   为保证质量应修复
-   - Consider for improvement
+    -   考虑改进
-   - Post-MVP deferrals
+    -   MVP 后推迟
 
-7. [BROWNFIELD ONLY] Integration Confidence
+7.  [仅棕地] 集成信心
-   - 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_  |                 |
+| 1. 项目设置与初始化 | _待定_ | |
-| 2. Infrastructure & Deployment          | _TBD_  |                 |
+| 2. 基础设施与部署 | _待定_ | |
-| 3. External Dependencies & Integrations | _TBD_  |                 |
+| 3. 外部依赖与集成 | _待定_ | |
-| 4. UI/UX Considerations                 | _TBD_  |                 |
+| 4. UI/UX 考量 | _待定_ | |
-| 5. User/Agent Responsibility            | _TBD_  |                 |
+| 5. 用户/代理责任 | _待定_ | |
-| 6. Feature Sequencing & Dependencies    | _TBD_  |                 |
+| 6. 功能排序与依赖关系 | _待定_ | |
-| 7. Risk Management (Brownfield)         | _TBD_  |                 |
+| 7. 风险管理 (棕地) | _待定_ | |
-| 8. MVP Scope Alignment                  | _TBD_  |                 |
+| 8. MVP 范围对齐 | _待定_ | |
-| 9. Documentation & Handoff              | _TBD_  |                 |
+| 9. 文档与交接 | _待定_ | |
-| 10. Post-MVP Considerations             | _TBD_  |                 |
+| 10. MVP 后考量 | _待定_ | |
 
-### 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.
+- **已拒绝**：该计划需要重大修订以解决关键缺陷。

bmad-core/checklists/story-dod-checklist.md

@@ -1,96 +1,96 @@
-<!-- Powered by BMAD™ Core -->
+<!-- 由 BMAD™ Core 驱动 -->
 
-# Story Definition of Done (DoD) Checklist
+# 故事完成定义 (DoD) 清单
 
-## Instructions for Developer Agent
+## 开发代理说明
 
-Before marking a story as 'Review', please go through each item in this checklist. Report the status of each item (e.g., [x] Done, [ ] Not Done, [N/A] Not Applicable) and provide brief comments if necessary.
+在将故事标记为“待审查”之前，请仔细检查此清单中的每个项目。报告每个项目的状态（例如，[x] 完成，[ ] 未完成，[N/A] 不适用），并在必要时提供简要评论。
 
-[[LLM: INITIALIZATION INSTRUCTIONS - STORY DOD VALIDATION
+[[LLM: 初始化说明 - 故事 DoD 验证
 
-This checklist is for DEVELOPER AGENTS to self-validate their work before marking a story complete.
+此清单供开发代理在标记故事完成前自行验证其工作。
 
-IMPORTANT: This is a self-assessment. Be honest about what's actually done vs what should be done. It's better to identify issues now than have them found in review.
+重要提示：这是一项自我评估。请诚实地说明实际完成的内容与应完成的内容。现在发现问题比在审查中被发现要好。
 
-EXECUTION APPROACH:
+执行方法：
 
-1. Go through each section systematically
+1.  系统地检查每个部分
-2. Mark items as [x] Done, [ ] Not Done, or [N/A] Not Applicable
+2.  将项目标记为 [x] 完成, [ ] 未完成, 或 [N/A] 不适用
-3. Add brief comments explaining any [ ] or [N/A] items
+3.  为任何 [ ] 或 [N/A] 项目添加简要评论以作解释
-4. Be specific about what was actually implemented
+4.  具体说明实际实施了什么
-5. Flag any concerns or technical debt created
+5.  标记任何疑虑或产生的技术债务
 
-The goal is quality delivery, not just checking boxes.]]
+目标是高质量交付，而不仅仅是勾选复选框。]]
 
-## Checklist Items
+## 清单项目
 
-1. **Requirements Met:**
+1.  **需求满足：**
 
-   [[LLM: Be specific - list each requirement and whether it's complete]]
+    [[LLM: 请具体说明——列出每个需求及其是否完成]]
-   - [ ] All functional requirements specified in the story are implemented.
+    - [ ] 故事中指定的所有功能性需求均已实现。
-   - [ ] All acceptance criteria defined in the story are met.
+    - [ ] 故事中定义的所有验收标准均已满足。
 
-2. **Coding Standards & Project Structure:**
+2.  **编码标准与项目结构：**
 
-   [[LLM: Code quality matters for maintainability. Check each item carefully]]
+    [[LLM: 代码质量对可维护性至关重要。请仔细检查每个项目]]
-   - [ ] All new/modified code strictly adheres to `Operational Guidelines`.
+    - [ ] 所有新增/修改的代码严格遵守`操作指南`。
-   - [ ] All new/modified code aligns with `Project Structure` (file locations, naming, etc.).
+    - [ ] 所有新增/修改的代码与`项目结构`（文件位置、命名等）保持一致。
-   - [ ] Adherence to `Tech Stack` for technologies/versions used (if story introduces or modifies tech usage).
+    - [ ] 遵守`技术栈`中规定的技术/版本（如果故事引入或修改了技术使用）。
-   - [ ] Adherence to `Api Reference` and `Data Models` (if story involves API or data model changes).
+    - [ ] 遵守`API参考`和`数据模型`（如果故事涉及API或数据模型更改）。
-   - [ ] Basic security best practices (e.g., input validation, proper error handling, no hardcoded secrets) applied for new/modified code.
+    - [ ] 对新增/修改的代码应用了基本的安全最佳实践（例如，输入验证、正确的错误处理、无硬编码机密）。
-   - [ ] No new linter errors or warnings introduced.
+    - [ ] 没有引入新的 linter 错误或警告。
-   - [ ] Code is well-commented where necessary (clarifying complex logic, not obvious statements).
+    - [ ] 在必要处对代码进行了充分注释（澄清复杂逻辑，而非显而易见的语句）。
 
-3. **Testing:**
+3.  **测试：**
 
-   [[LLM: Testing proves your code works. Be honest about test coverage]]
+    [[LLM: 测试证明您的代码有效。请诚实地说明测试覆盖率]]
-   - [ ] All required unit tests as per the story and `Operational Guidelines` Testing Strategy are implemented.
+    - [ ] 根据故事和`操作指南`测试策略要求的所有单元测试均已实现。
-   - [ ] All required integration tests (if applicable) as per the story and `Operational Guidelines` Testing Strategy are implemented.
+    - [ ] 根据故事和`操作指南`测试策略要求的所有集成测试（如果适用）均已实现。
-   - [ ] All tests (unit, integration, E2E if applicable) pass successfully.
+    - [ ] 所有测试（单元、集成、端到端，如果适用）均成功通过。
-   - [ ] Test coverage meets project standards (if defined).
+    - [ ] 测试覆盖率符合项目标准（如果已定义）。
 
-4. **Functionality & Verification:**
+4.  **功能与验证：**
 
-   [[LLM: Did you actually run and test your code? Be specific about what you tested]]
+    [[LLM: 您是否实际运行并测试了您的代码？请具体说明您测试了什么]]
-   - [ ] Functionality has been manually verified by the developer (e.g., running the app locally, checking UI, testing API endpoints).
+    - [ ] 功能已由开发人员手动验证（例如，在本地运行应用程序、检查UI、测试API端点）。
-   - [ ] Edge cases and potential error conditions considered and handled gracefully.
+    - [ ] 已考虑并妥善处理了边缘情况和潜在的错误条件。
 
-5. **Story Administration:**
+5.  **故事管理：**
 
-   [[LLM: Documentation helps the next developer. What should they know?]]
+    [[LLM: 文档可以帮助下一个开发人员。他们需要知道什么？]]
-   - [ ] All tasks within the story file are marked as complete.
+    - [ ] 故事文件中的所有任务均已标记为完成。
-   - [ ] Any clarifications or decisions made during development are documented in the story file or linked appropriately.
+    - [ ] 开发过程中做出的任何澄清或决定都已记录在故事文件中或已适当链接。
-   - [ ] The story wrap up section has been completed with notes of changes or information relevant to the next story or overall project, the agent model that was primarily used during development, and the changelog of any changes is properly updated.
+    - [ ] 故事总结部分已完成，其中包含与下一个故事或整个项目相关的变更或信息说明、开发期间主要使用的代理模型，以及任何变更的更新日志均已正确更新。
 
-6. **Dependencies, Build & Configuration:**
+6.  **依赖、构建与配置：**
 
-   [[LLM: Build issues block everyone. Ensure everything compiles and runs cleanly]]
+    [[LLM: 构建问题会阻碍所有人。请确保所有内容都能干净地编译和运行]]
-   - [ ] Project builds successfully without errors.
+    - [ ] 项目成功构建，无错误。
-   - [ ] Project linting passes
+    - [ ] 项目 linting 通过。
-   - [ ] Any new dependencies added were either pre-approved in the story requirements OR explicitly approved by the user during development (approval documented in story file).
+    - [ ] 新增的任何依赖项要么在故事需求中预先批准，要么在开发过程中由用户明确批准（批准情况记录在故事文件中）。
-   - [ ] If new dependencies were added, they are recorded in the appropriate project files (e.g., `package.json`, `requirements.txt`) with justification.
+    - [ ] 如果添加了新依赖项，它们会连同理由一起记录在适当的项目文件中（例如，`package.json`、`requirements.txt`）。
-   - [ ] No known security vulnerabilities introduced by newly added and approved dependencies.
+    - [ ] 新增并批准的依赖项未引入已知的安全漏洞。
-   - [ ] If new environment variables or configurations were introduced by the story, they are documented and handled securely.
+    - [ ] 如果故事引入了新的环境变量或配置，它们已被记录并得到安全处理。
 
-7. **Documentation (If Applicable):**
+7.  **文档（如果适用）：**
 
-   [[LLM: Good documentation prevents future confusion. What needs explaining?]]
+    [[LLM: 好的文档可以避免未来的困惑。什么需要解释？]]
-   - [ ] Relevant inline code documentation (e.g., JSDoc, TSDoc, Python docstrings) for new public APIs or complex logic is complete.
+    - [ ] 新的公共API或复杂逻辑的相关内联代码文档（例如，JSDoc、TSDoc、Python docstrings）已完成。
-   - [ ] User-facing documentation updated, if changes impact users.
+    - [ ] 如果变动影响用户，面向用户的文档已更新。
-   - [ ] Technical documentation (e.g., READMEs, system diagrams) updated if significant architectural changes were made.
+    - [ ] 如果进行了重大的架构变更，技术文档（例如，README、系统图）已更新。
 
-## Final Confirmation
+## 最终确认
 
-[[LLM: FINAL DOD SUMMARY
+[[LLM: 最终 DoD 摘要
 
-After completing the checklist:
+完成清单后：
 
-1. Summarize what was accomplished in this story
+1.  总结此故事中完成的工作
-2. List any items marked as [ ] Not Done with explanations
+2.  列出任何标记为 [ ] 未完成的项目并附上解释
-3. Identify any technical debt or follow-up work needed
+3.  确定任何技术债务或需要跟进的工作
-4. Note any challenges or learnings for future stories
+4.  记录未来故事的任何挑战或经验教训
-5. Confirm whether the story is truly ready for review
+5.  确认故事是否真正准备好进行审查
 
-Be honest - it's better to flag issues now than have them discovered later.]]
+请务必诚实——现在标记问题比以后被发现要好。]]
 
-- [ ] I, the Developer Agent, confirm that all applicable items above have been addressed.
+- [ ] 我，作为开发代理，确认以上所有适用项目均已处理。

bmad-core/checklists/story-draft-checklist.md

@@ -1,155 +1,155 @@
-<!-- Powered by BMAD™ Core -->
+<!-- 由 BMAD™ Core 驱动 -->
 
-# Story Draft Checklist
+# 故事草稿清单
 
-The Scrum Master should use this checklist to validate that each story contains sufficient context for a developer agent to implement it successfully, while assuming the dev agent has reasonable capabilities to figure things out.
+Scrum Master 应使用此清单来验证每个故事是否包含足够的上下文，以便开发代理成功实施，同时假设开发代理具有合理的能力来解决问题。
 
-[[LLM: INITIALIZATION INSTRUCTIONS - STORY DRAFT VALIDATION
+[[LLM: 初始化说明 - 故事草稿验证
 
-Before proceeding with this checklist, ensure you have access to:
+在开始使用此清单之前，请确保您能访问以下内容：
 
-1. The story document being validated (usually in docs/stories/ or provided directly)
+1.  正在验证的故事文档（通常在 docs/stories/ 中或直接提供）
-2. The parent epic context
+2.  父级史诗的上下文
-3. Any referenced architecture or design documents
+3.  任何引用的架构或设计文档
-4. Previous related stories if this builds on prior work
+4.  如果此工作建立在先前工作的基础上，则需提供以前的相关故事
 
-IMPORTANT: This checklist validates individual stories BEFORE implementation begins.
+重要提示：此清单在实施开始前验证单个故事。
 
-VALIDATION PRINCIPLES:
+验证原则：
 
-1. Clarity - A developer should understand WHAT to build
+1.  清晰性 - 开发人员应了解要构建什么
-2. Context - WHY this is being built and how it fits
+2.  上下文 - 为什么要构建它以及它如何融入整体
-3. Guidance - Key technical decisions and patterns to follow
+3.  指导 - 要遵循的关键技术决策和模式
-4. Testability - How to verify the implementation works
+4.  可测试性 - 如何验证实施是否有效
-5. Self-Contained - Most info needed is in the story itself
+5.  自包含性 - 所需的大部分信息都在故事本身中
 
-REMEMBER: We assume competent developer agents who can:
+请记住：我们假设有能力的开发代理可以：
 
-- Research documentation and codebases
+-   研究文档和代码库
-- Make reasonable technical decisions
+-   做出合理的技术决策
-- Follow established patterns
+-   遵循既定模式
-- Ask for clarification when truly stuck
+-   在真正遇到困难时请求澄清
 
-We're checking for SUFFICIENT guidance, not exhaustive detail.]]
+我们正在检查的是足够的指导，而不是详尽的细节。]]
 
-## 1. GOAL & CONTEXT CLARITY
+## 1. 目标与上下文清晰度
 
-[[LLM: Without clear goals, developers build the wrong thing. Verify:
+[[LLM: 没有明确的目标，开发人员会构建错误的东西。验证：
 
-1. The story states WHAT functionality to implement
+1.  故事说明了要实施什么功能
-2. The business value or user benefit is clear
+2.  业务价值或用户利益是明确的
-3. How this fits into the larger epic/product is explained
+3.  解释了这如何融入更大的史诗/产品
-4. Dependencies are explicit ("requires Story X to be complete")
+4.  依赖关系是明确的（“需要故事 X 完成”）
-5. Success looks like something specific, not vague]]
+5.  成功看起来是具体的，而不是模糊的]]
 
-- [ ] Story goal/purpose is clearly stated
+- [ ] 故事目标/目的陈述清晰
-- [ ] Relationship to epic goals is evident
+- [ ] 与史诗目标的关系显而易见
-- [ ] How the story fits into overall system flow is explained
+- [ ] 解释了故事如何融入整个系统流程
-- [ ] Dependencies on previous stories are identified (if applicable)
+- [ ] 确定了对先前故事的依赖关系（如果适用）
-- [ ] Business context and value are clear
+- [ ] 业务背景和价值清晰
 
-## 2. TECHNICAL IMPLEMENTATION GUIDANCE
+## 2. 技术实施指导
 
-[[LLM: Developers need enough technical context to start coding. Check:
+[[LLM: 开发人员需要足够的技术背景才能开始编码。检查：
 
-1. Key files/components to create or modify are mentioned
+1.  提到了要创建或修改的关键文件/组件
-2. Technology choices are specified where non-obvious
+2.  在不明显的地方指定了技术选择
-3. Integration points with existing code are identified
+3.  确定了与现有代码的集成点
-4. Data models or API contracts are defined or referenced
+4.  定义或引用了数据模型或 API 合约
-5. Non-standard patterns or exceptions are called out
+5.  指出了非标准模式或例外情况
 
-Note: We don't need every file listed - just the important ones.]]
+注意：我们不需要列出每个文件 - 只需要重要的文件。]]
 
-- [ ] Key files to create/modify are identified (not necessarily exhaustive)
+- [ ] 确定了要创建/修改的关键文件（不一定详尽无遗）
-- [ ] Technologies specifically needed for this story are mentioned
+- [ ] 提到了此故事特别需要的技术
-- [ ] Critical APIs or interfaces are sufficiently described
+- [ ] 充分描述了关键的 API 或接口
-- [ ] Necessary data models or structures are referenced
+- [ ] 引用了必要的数据模型或结构
-- [ ] Required environment variables are listed (if applicable)
+- [ ] 列出了所需的环境变量（如果适用）
-- [ ] Any exceptions to standard coding patterns are noted
+- [ ] 注意到了标准编码模式的任何例外情况
 
-## 3. REFERENCE EFFECTIVENESS
+## 3. 参考有效性
 
-[[LLM: References should help, not create a treasure hunt. Ensure:
+[[LLM: 参考应该有帮助，而不是制造寻宝游戏。确保：
 
-1. References point to specific sections, not whole documents
+1.  参考指向特定部分，而不是整个文档
-2. The relevance of each reference is explained
+2.  解释了每个参考的相关性
-3. Critical information is summarized in the story
+3.  故事中总结了关键信息
-4. References are accessible (not broken links)
+4.  参考是可访问的（不是损坏的链接）
-5. Previous story context is summarized if needed]]
+5.  如果需要，总结了先前故事的上下文]]
 
-- [ ] References to external documents point to specific relevant sections
+- [ ] 对外部文档的引用指向特定的相关部分
-- [ ] Critical information from previous stories is summarized (not just referenced)
+- [ ] 总结了先前故事中的关键信息（而不仅仅是引用）
-- [ ] Context is provided for why references are relevant
+- [ ] 提供了为什么参考相关的上下文
-- [ ] References use consistent format (e.g., `docs/filename.md#section`)
+- [ ] 参考使用一致的格式（例如，`docs/filename.md#section`）
 
-## 4. SELF-CONTAINMENT ASSESSMENT
+## 4. 自包含性评估
 
-[[LLM: Stories should be mostly self-contained to avoid context switching. Verify:
+[[LLM: 故事应尽可能自包含，以避免上下文切换。验证：
 
-1. Core requirements are in the story, not just in references
+1.  核心需求在故事中，而不仅仅是在参考中
-2. Domain terms are explained or obvious from context
+2.  领域术语已解释或从上下文中显而易见
-3. Assumptions are stated explicitly
+3.  明确陈述了假设
-4. Edge cases are mentioned (even if deferred)
+4.  提到了边缘情况（即使已推迟）
-5. The story could be understood without reading 10 other documents]]
+5.  无需阅读 10 个其他文档即可理解该故事]]
 
-- [ ] Core information needed is included (not overly reliant on external docs)
+- [ ] 包含了所需的核心信息（不过度依赖外部文档）
-- [ ] Implicit assumptions are made explicit
+- [ ] 明确了隐含的假设
-- [ ] Domain-specific terms or concepts are explained
+- [ ] 解释了特定领域的术语或概念
-- [ ] Edge cases or error scenarios are addressed
+- [ ] 解决了边缘情况或错误场景
 
-## 5. TESTING GUIDANCE
+## 5. 测试指导
 
-[[LLM: Testing ensures the implementation actually works. Check:
+[[LLM: 测试确保实施真正有效。检查：
 
-1. Test approach is specified (unit, integration, e2e)
+1.  指定了测试方法（单元、集成、端到端）
-2. Key test scenarios are listed
+2.  列出了关键测试场景
-3. Success criteria are measurable
+3.  成功标准是可衡量的
-4. Special test considerations are noted
+4.  注意到了特殊的测试注意事项
-5. Acceptance criteria in the story are testable]]
+5.  故事中的验收标准是可测试的]]
 
-- [ ] Required testing approach is outlined
+- [ ] 概述了所需的测试方法
-- [ ] Key test scenarios are identified
+- [ ] 确定了关键测试场景
-- [ ] Success criteria are defined
+- [ ] 定义了成功标准
-- [ ] Special testing considerations are noted (if applicable)
+- [ ] 注意到了特殊的测试注意事项（如果适用）
 
-## VALIDATION RESULT
+## 验证结果
 
-[[LLM: FINAL STORY VALIDATION REPORT
+[[LLM: 最终故事验证报告
 
-Generate a concise validation report:
+生成一份简洁的验证报告：
 
-1. Quick Summary
+1.  快速摘要
-   - Story readiness: READY / NEEDS REVISION / BLOCKED
+    -   故事准备情况：准备就绪 / 需要修订 / 受阻
-   - Clarity score (1-10)
+    -   清晰度得分 (1-10)
-   - Major gaps identified
+    -   识别出的主要差距
 
-2. Fill in the validation table with:
+2.  填写验证表：
-   - PASS: Requirements clearly met
+    -   通过：需求明确满足
-   - PARTIAL: Some gaps but workable
+    -   部分：有些差距但可行
-   - FAIL: Critical information missing
+    -   失败：缺少关键信息
 
-3. Specific Issues (if any)
+3.  具体问题（如有）
-   - List concrete problems to fix
+    -   列出要修复的具体问题
-   - Suggest specific improvements
+    -   提出具体的改进建议
-   - Identify any blocking dependencies
+    -   确定任何阻塞性依赖关系
 
-4. Developer Perspective
+4.  开发人员视角
-   - Could YOU implement this story as written?
+    -   您能按书面形式实施这个故事吗？
-   - What questions would you have?
+    -   您会有什么问题？
-   - What might cause delays or rework?
+    -   什么可能导致延误或返工？
 
-Be pragmatic - perfect documentation doesn't exist, but it must be enough to provide the extreme context a dev agent needs to get the work down and not create a mess.]]
+要务实——完美的文档不存在，但必须足以提供开发代理完成工作所需的极端上下文，并且不会造成混乱。]]
 
-| Category                             | Status | Issues |
+| 类别 | 状态 | 问题 |
-| ------------------------------------ | ------ | ------ |
+| --- | --- | --- |
-| 1. Goal & Context Clarity            | _TBD_  |        |
+| 1. 目标与上下文清晰度 | _待定_ | |
-| 2. Technical Implementation Guidance | _TBD_  |        |
+| 2. 技术实施指导 | _待定_ | |
-| 3. Reference Effectiveness           | _TBD_  |        |
+| 3. 参考有效性 | _待定_ | |
-| 4. Self-Containment Assessment       | _TBD_  |        |
+| 4. 自包含性评估 | _待定_ | |
-| 5. Testing Guidance                  | _TBD_  |        |
+| 5. 测试指导 | _待定_ | |
 
-**Final Assessment:**
+**最终评估：**
 
-- READY: The story provides sufficient context for implementation
+-   **准备就绪**：故事为实施提供了足够的上下文
-- NEEDS REVISION: The story requires updates (see issues)
+-   **需要修订**：故事需要更新（见问题）
-- BLOCKED: External information required (specify what information)
+-   **受阻**：需要外部信息（指明需要什么信息）

bmad-core/data/brainstorming-techniques.md

@@ -1,38 +1,38 @@
-<!-- Powered by BMAD™ Core -->
+<!-- 由 BMAD™ Core 驱动 -->
 
-# Brainstorming Techniques Data
+# 头脑风暴技术数据
 
-## Creative Expansion
+## 创意扩展
 
-1. **What If Scenarios**: Ask one provocative question, get their response, then ask another
+1.  **“如果…”场景**：提出一个挑衅性问题，获取他们的回应，然后再问另一个。
-2. **Analogical Thinking**: Give one example analogy, ask them to find 2-3 more
+2.  **类比思维**：给出一个类比示例，让他们再找出2-3个。
-3. **Reversal/Inversion**: Pose the reverse question, let them work through it
+3.  **逆向/反转**：提出反向问题，让他们思考。
-4. **First Principles Thinking**: Ask "What are the fundamentals?" and guide them to break it down
+4.  **第一性原理思维**：问“基本原理是什么？”，并引导他们进行分解。
 
-## Structured Frameworks
+## 结构化框架
 
-5. **SCAMPER Method**: Go through one letter at a time, wait for their ideas before moving to next
+5.  **SCAMPER方法**：一次处理一个字母，等待他们的想法，然后再进行下一个。
-6. **Six Thinking Hats**: Present one hat, ask for their thoughts, then move to next hat
+6.  **六顶思考帽**：呈现一顶帽子，征求他们的想法，然后换下一顶帽子。
-7. **Mind Mapping**: Start with central concept, ask them to suggest branches
+7.  **思维导图**：从中心概念开始，让他们建议分支。
 
-## Collaborative Techniques
+## 协作技巧
 
-8. **"Yes, And..." Building**: They give idea, you "yes and" it, they "yes and" back - alternate
+8.  **“是的，而且…”构建**：他们提出想法，你用“是的，而且…”来补充，他们再用“是的，而且…”回应——交替进行。
-9. **Brainwriting/Round Robin**: They suggest idea, you build on it, ask them to build on yours
+9.  **脑力写作/循环**：他们提出想法，你在此基础上构建，再让他们在你的基础上构建。
-10. **Random Stimulation**: Give one random prompt/word, ask them to make connections
+10. **随机刺激**：给出一个随机的提示/词语，让他们建立联系。
 
-## Deep Exploration
+## 深度探索
 
-11. **Five Whys**: Ask "why" and wait for their answer before asking next "why"
+11. **五个为什么**：问“为什么”，等待他们的回答，然后再问下一个“为什么”。
-12. **Morphological Analysis**: Ask them to list parameters first, then explore combinations together
+12. **形态分析**：先让他们列出参数，然后一起探索组合。
-13. **Provocation Technique (PO)**: Give one provocative statement, ask them to extract useful ideas
+13. **挑衅技术 (PO)**：给出一个挑衅性的陈述，让他们从中提取有用的想法。
 
-## Advanced Techniques
+## 高级技巧
 
-14. **Forced Relationships**: Connect two unrelated concepts and ask them to find the bridge
+14. **强制关联**：连接两个不相关的概念，让他们找到桥梁。
-15. **Assumption Reversal**: Challenge their core assumptions and ask them to build from there
+15. **假设逆转**：挑战他们的核心假设，让他们从那里开始构建。
-16. **Role Playing**: Ask them to brainstorm from different stakeholder perspectives
+16. **角色扮演**：让他们从不同利益相关者的角度进行头脑风暴。
-17. **Time Shifting**: "How would you solve this in 1995? 2030?"
+17. **时间转移**：“在1995年你会如何解决这个问题？2030年呢？”
-18. **Resource Constraints**: "What if you had only $10 and 1 hour?"
+18. **资源限制**：“如果你只有10美元和1小时怎么办？”
-19. **Metaphor Mapping**: Use extended metaphors to explore solutions
+19. **隐喻映射**：使用扩展的隐喻来探索解决方案。
-20. **Question Storming**: Generate questions instead of answers first
+20. **问题风暴**：首先生成问题而不是答案。

bmad-core/data/elicitation-methods.md

@@ -1,156 +1,157 @@
-<!-- Powered by BMAD™ Core -->
+<!-- 由 BMAD™ Core 驱动 -->
 
-# Elicitation Methods Data
+# 启发式方法数据
 
-## Core Reflective Methods
+## 核心反思方法
 
-**Expand or Contract for Audience**
+**为受众扩展或收缩**
 
-- Ask whether to 'expand' (add detail, elaborate) or 'contract' (simplify, clarify)
+-   询问是“扩展”（添加细节、阐述）还是“收缩”（简化、澄清）
-- Identify specific target audience if relevant
+-   如果相关，确定具体的目标受众
-- Tailor content complexity and depth accordingly
+-   相应地调整内容的复杂性和深度
 
-**Explain Reasoning (CoT Step-by-Step)**
+**解释推理（CoT分步进行）**
 
-- Walk through the step-by-step thinking process
+-   逐步展示思维过程
-- Reveal underlying assumptions and decision points
+-   揭示潜在的假设和决策点
-- Show how conclusions were reached from current role's perspective
+-   从当前角色的角度展示结论是如何得出的
 
-**Critique and Refine**
+**批判与完善**
 
-- Review output for flaws, inconsistencies, or improvement areas
+-   审查输出中的缺陷、不一致或改进领域
-- Identify specific weaknesses from role's expertise
+-   从角色的专业知识角度找出具体弱点
-- Suggest refined version reflecting domain knowledge
+-   建议反映领域知识的完善版本
 
-## Structural Analysis Methods
+## 结构分析方法
 
-**Analyze Logical Flow and Dependencies**
+**分析逻辑流程和依赖关系**
 
-- Examine content structure for logical progression
+-   检查内容结构的逻辑进展
-- Check internal consistency and coherence
+-   检查内部一致性和连贯性
-- Identify and validate dependencies between elements
+-   识别并验证元素之间的依赖关系
-- Confirm effective ordering and sequencing
+-   确认有效的排序和顺序
 
-**Assess Alignment with Overall Goals**
+**评估与总体目标的对齐情况**
 
-- Evaluate content contribution to stated objectives
+-   评估内容对既定目标的贡献
-- Identify any misalignments or gaps
+-   识别任何不一致或差距
-- Interpret alignment from specific role's perspective
+-   从特定角色的角度解释对齐情况
-- Suggest adjustments to better serve goals
+-   建议调整以更好地服务于目标
 
-## Risk and Challenge Methods
+## 风险与挑战方法
 
-**Identify Potential Risks and Unforeseen Issues**
+**识别潜在风险和未预见的问题**
 
-- Brainstorm potential risks from role's expertise
+-   从角色的专业知识角度头脑风暴潜在风险
-- Identify overlooked edge cases or scenarios
+-   识别被忽视的边缘案例或场景
-- Anticipate unintended consequences
+-   预测意想不到的后果
-- Highlight implementation challenges
+-   突出实施挑战
 
-**Challenge from Critical Perspective**
+**从批判性角度提出挑战**
 
-- Adopt critical stance on current content
+-   对当前内容采取批判性立场
-- Play devil's advocate from specified viewpoint
+-   从指定角度扮演“魔鬼代言人”
-- Argue against proposal highlighting weaknesses
+-   反驳提案，突出弱点
-- Apply YAGNI principles when appropriate (scope trimming)
+-   在适当时应用YAGNI原则（削减范围）
 
-## Creative Exploration Methods
+## 创意探索方法
 
-**Tree of Thoughts Deep Dive**
+**思维树深度探索**
 
-- Break problem into discrete "thoughts" or intermediate steps
+-   将问题分解为离散的“思想”或中间步骤
-- Explore multiple reasoning paths simultaneously
+-   同时探索多种推理路径
-- Use self-evaluation to classify each path as "sure", "likely", or "impossible"
+-   使用自我评估将每条路径分类为“确定”、“可能”或“不可能”
-- Apply search algorithms (BFS/DFS) to find optimal solution paths
+-   应用搜索算法（BFS/DFS）寻找最优解决方案路径
 
-**Hindsight is 20/20: The 'If Only...' Reflection**
+**事后诸葛亮：“如果当初…”反思**
 
-- Imagine retrospective scenario based on current content
+-   根据当前内容想象一个回顾性场景
-- Identify the one "if only we had known/done X..." insight
+-   找出那个“如果我们当初知道/做了X就好了…”的洞见
-- Describe imagined consequences humorously or dramatically
+-   幽默或戏剧性地描述想象中的后果
-- Extract actionable learnings for current context
+-   为当前情境提取可操作的学习经验
 
-## Multi-Persona Collaboration Methods
+## 多角色协作方法
 
-**Agile Team Perspective Shift**
+**敏捷团队视角转换**
 
-- Rotate through different Scrum team member viewpoints
+-   在不同的Scrum团队成员视角之间轮换
-- Product Owner: Focus on user value and business impact
+-   产品负责人：关注用户价值和业务影响
-- Scrum Master: Examine process flow and team dynamics
+-   Scrum Master：检查流程和团队动态
-- Developer: Assess technical implementation and complexity
+-   开发人员：评估技术实施和复杂性
-- QA: Identify testing scenarios and quality concerns
+-   QA：识别测试场景和质量问题
 
-**Stakeholder Round Table**
+**利益相关者圆桌会议**
 
-- Convene virtual meeting with multiple personas
+-   召集多个角色的虚拟会议
-- Each persona contributes unique perspective on content
+-   每个角色对内容贡献独特的视角
-- Identify conflicts and synergies between viewpoints
+-   识别不同观点之间的冲突和协同作用
-- Synthesize insights into actionable recommendations
+-   将洞见综合为可操作的建议
 
-**Meta-Prompting Analysis**
+**元提示分析**
 
-- Step back to analyze the structure and logic of current approach
+-   退后一步分析当前方法的结构和逻辑
-- Question the format and methodology being used
+-   质疑正在使用的格式和方法论
-- Suggest alternative frameworks or mental models
+-   建议替代框架或心智模型
-- Optimize the elicitation process itself
+-
+-   优化启发过程本身
 
-## Advanced 2025 Techniques
+## 2025年高级技术
 
-**Self-Consistency Validation**
+**自我一致性验证**
 
-- Generate multiple reasoning paths for same problem
+-   为同一问题生成多个推理路径
-- Compare consistency across different approaches
+-   比较不同方法之间的一致性
-- Identify most reliable and robust solution
+-   确定最可靠和稳健的解决方案
-- Highlight areas where approaches diverge and why
+-   突出不同方法产生分歧的领域及其原因
 
-**ReWOO (Reasoning Without Observation)**
+**ReWOO（无观察推理）**
 
-- Separate parametric reasoning from tool-based actions
+-   将参数化推理与基于工具的行动分开
-- Create reasoning plan without external dependencies
+-   在没有外部依赖的情况下创建推理计划
-- Identify what can be solved through pure reasoning
+-   确定可以通过纯粹推理解决的问题
-- Optimize for efficiency and reduced token usage
+-   优化效率并减少令牌使用
 
-**Persona-Pattern Hybrid**
+**角色-模式混合**
 
-- Combine specific role expertise with elicitation pattern
+-   将特定角色的专业知识与启发模式相结合
-- Architect + Risk Analysis: Deep technical risk assessment
+-   架构师 + 风险分析：深入的技术风险评估
-- UX Expert + User Journey: End-to-end experience critique
+-   UX专家 + 用户旅程：端到端的体验批判
-- PM + Stakeholder Analysis: Multi-perspective impact review
+-   PM + 利益相关者分析：多角度影响审查
 
-**Emergent Collaboration Discovery**
+**涌现式协作发现**
 
-- Allow multiple perspectives to naturally emerge
+-   让多种视角自然涌现
-- Identify unexpected insights from persona interactions
+-   从角色互动中识别意想不到的洞见
-- Explore novel combinations of viewpoints
+-   探索新颖的观点组合
-- Capture serendipitous discoveries from multi-agent thinking
+-   捕捉多代理思维中的意外发现
 
-## Game-Based Elicitation Methods
+## 基于游戏的启发方法
 
-**Red Team vs Blue Team**
+**红队 vs 蓝队**
 
-- Red Team: Attack the proposal, find vulnerabilities
+-   红队：攻击提案，发现漏洞
-- Blue Team: Defend and strengthen the approach
+-   蓝队：捍卫并加强方法
-- Competitive analysis reveals blind spots
+-   竞争性分析揭示盲点
-- Results in more robust, battle-tested solutions
+-   产生更稳健、经过实战检验的解决方案
 
-**Innovation Tournament**
+**创新锦标赛**
 
-- Pit multiple alternative approaches against each other
+-   让多种替代方法相互竞争
-- Score each approach across different criteria
+-   根据不同标准对每种方法进行评分
-- Crowd-source evaluation from different personas
+-   从不同角色中众包评估
-- Identify winning combination of features
+-   确定获胜的功能组合
 
-**Escape Room Challenge**
+**密室逃脱挑战**
 
-- Present content as constraints to work within
+-   将内容作为工作限制呈现
-- Find creative solutions within tight limitations
+-   在严格的限制下寻找创造性解决方案
-- Identify minimum viable approach
+--   确定最小可行方法
-- Discover innovative workarounds and optimizations
+-   发现创新的变通方法和优化
 
-## Process Control
+## 流程控制
 
-**Proceed / No Further Actions**
+**继续/无进一步操作**
 
-- Acknowledge choice to finalize current work
+-   确认完成当前工作的选择
-- Accept output as-is or move to next step
+-   按原样接受输出或进入下一步
-- Prepare to continue without additional elicitation
+-   准备在没有额外启发的情况下继续

bmad-core/data/technical-preferences.md

@@ -1,5 +1,5 @@
-<!-- Powered by BMAD™ Core -->
+<!-- 由 BMAD™ Core 驱动 -->
 
-# User-Defined Preferred Patterns and Preferences
+# 用户定义的首选模式和偏好
 
-None Listed
+未列出

bmad-core/data/test-levels-framework.md

@@ -1,147 +1,147 @@
-<!-- Powered by BMAD™ Core -->
+<!-- 由 BMAD™ Core 驱动 -->
 
-# Test Levels Framework
+# 测试级别框架
 
-Comprehensive guide for determining appropriate test levels (unit, integration, E2E) for different scenarios.
+用于确定不同场景下适当测试级别（单元、集成、端到端）的综合指南。
 
-## Test Level Decision Matrix
+## 测试级别决策矩阵
 
-### Unit Tests
+### 单元测试
 
-**When to use:**
+**何时使用：**
 
-- Testing pure functions and business logic
+-   测试纯函数和业务逻辑
-- Algorithm correctness
+-   算法正确性
-- Input validation and data transformation
+-   输入验证和数据转换
-- Error handling in isolated components
+-   隔离组件中的错误处理
-- Complex calculations or state machines
+-   复杂计算或状态机
 
-**Characteristics:**
+**特点：**
 
-- Fast execution (immediate feedback)
+-   执行速度快（即时反馈）
-- No external dependencies (DB, API, file system)
+-   无外部依赖（数据库、API、文件系统）
-- Highly maintainable and stable
+-   高度可维护和稳定
-- Easy to debug failures
+-   易于调试失败
 
-**Example scenarios:**
+**示例场景：**
 
 ```yaml
 unit_test:
   component: 'PriceCalculator'
-  scenario: 'Calculate discount with multiple rules'
+  scenario: '使用多条规则计算折扣'
-  justification: 'Complex business logic with multiple branches'
+  justification: '具有多个分支的复杂业务逻辑'
-  mock_requirements: 'None - pure function'
+  mock_requirements: '无 - 纯函数'
 ```
 
-### Integration Tests
+### 集成测试
 
-**When to use:**
+**何时使用：**
 
-- Component interaction verification
+-   组件交互验证
-- Database operations and transactions
+-   数据库操作和事务
-- API endpoint contracts
+-   API 端点合约
-- Service-to-service communication
+-   服务间通信
-- Middleware and interceptor behavior
+-   中间件和拦截器行为
 
-**Characteristics:**
+**特点：**
 
-- Moderate execution time
+-   执行时间适中
-- Tests component boundaries
+-   测试组件边界
-- May use test databases or containers
+-   可能使用测试数据库或容器
-- Validates system integration points
+-   验证系统集成点
 
-**Example scenarios:**
+**示例场景：**
 
 ```yaml
 integration_test:
   components: ['UserService', 'AuthRepository']
-  scenario: 'Create user with role assignment'
+  scenario: '创建具有角色分配的用户'
-  justification: 'Critical data flow between service and persistence'
+  justification: '服务与持久化之间的关键数据流'
-  test_environment: 'In-memory database'
+  test_environment: '内存数据库'
 ```
 
-### End-to-End Tests
+### 端到端测试
 
-**When to use:**
+**何时使用：**
 
-- Critical user journeys
+-   关键用户旅程
-- Cross-system workflows
+-   跨系统工作流
-- Visual regression testing
+-   可视化回归测试
-- Compliance and regulatory requirements
+-   合规性和法规要求
-- Final validation before release
+-   发布前最终验证
 
-**Characteristics:**
+**特点：**
 
-- Slower execution
+-   执行速度较慢
-- Tests complete workflows
+-   测试完整工作流
-- Requires full environment setup
+-   需要完整的环境设置
-- Most realistic but most brittle
+-   最真实但最脆弱
 
-**Example scenarios:**
+**示例场景：**
 
 ```yaml
 e2e_test:
-  journey: 'Complete checkout process'
+  journey: '完成结账流程'
-  scenario: 'User purchases with saved payment method'
+  scenario: '用户使用已保存的支付方式购买'
-  justification: 'Revenue-critical path requiring full validation'
+  justification: '需要全面验证的收入关键路径'
-  environment: 'Staging with test payment gateway'
+  environment: '带有测试支付网关的预发环境'
 ```
 
-## Test Level Selection Rules
+## 测试级别选择规则
 
-### Favor Unit Tests When:
+### 何时倾向于单元测试：
 
-- Logic can be isolated
+-   逻辑可以被隔离
-- No side effects involved
+-   不涉及副作用
-- Fast feedback needed
+-   需要快速反馈
-- High cyclomatic complexity
+-   圈复杂度高
 
-### Favor Integration Tests When:
+### 何时倾向于集成测试：
 
-- Testing persistence layer
+-   测试持久层
-- Validating service contracts
+-   验证服务合约
-- Testing middleware/interceptors
+-   测试中间件/拦截器
-- Component boundaries critical
+-   组件边界至关重要
 
-### Favor E2E Tests When:
+### 何时倾向于端到端测试：
 
-- User-facing critical paths
+-   面向用户的关键路径
-- Multi-system interactions
+-   多系统交互
-- Regulatory compliance scenarios
+-   法规遵从性场景
-- Visual regression important
+-   可视化回归很重要
 
-## Anti-patterns to Avoid
+## 要避免的反模式
 
-- E2E testing for business logic validation
+-   使用端到端测试进行业务逻辑验证
-- Unit testing framework behavior
+-   单元测试框架行为
-- Integration testing third-party libraries
+-   集成测试第三方库
-- Duplicate coverage across levels
+-   跨级别的重复覆盖
 
-## Duplicate Coverage Guard
+## 重复覆盖防护
 
-**Before adding any test, check:**
+**在添加任何测试之前，请检查：**
 
-1. Is this already tested at a lower level?
+1.  这是否已经在较低级别进行了测试？
-2. Can a unit test cover this instead of integration?
+2.  单元测试能否代替集成测试覆盖此项？
-3. Can an integration test cover this instead of E2E?
+3.  集成测试能否代替端到端测试覆盖此项？
 
-**Coverage overlap is only acceptable when:**
+**仅在以下情况下，覆盖范围重叠是可接受的：**
 
-- Testing different aspects (unit: logic, integration: interaction, e2e: user experience)
+-   测试不同方面（单元：逻辑，集成：交互，端到端：用户体验）
-- Critical paths requiring defense in depth
+-   需要深度防御的关键路径
-- Regression prevention for previously broken functionality
+-   防止先前已损坏功能的回归
 
-## Test Naming Conventions
+## 测试命名约定
 
-- Unit: `test_{component}_{scenario}`
+-   单元：`test_{component}_{scenario}`
-- Integration: `test_{flow}_{interaction}`
+-   集成：`test_{flow}_{interaction}`
-- E2E: `test_{journey}_{outcome}`
+-   端到端：`test_{journey}_{outcome}`
 
-## Test ID Format
+## 测试ID格式
 
 `{EPIC}.{STORY}-{LEVEL}-{SEQ}`
 
-Examples:
+**示例：**
 
 -   `1.3-UNIT-001`
 -   `1.3-INT-002`

bmad-core/data/test-priorities-matrix.md

@@ -1,174 +1,174 @@
-<!-- Powered by BMAD™ Core -->
+<!-- 由 BMAD™ Core 驱动 -->
 
-# Test Priorities Matrix
+# 测试优先级矩阵
 
-Guide for prioritizing test scenarios based on risk, criticality, and business impact.
+根据风险、重要性和业务影响来确定测试场景优先级的指南。
 
-## Priority Levels
+## 优先级
 
-### P0 - Critical (Must Test)
+### P0 - 关键（必须测试）
 
-**Criteria:**
+**标准：**
 
-- Revenue-impacting functionality
+-   影响收入的功能
-- Security-critical paths
+-   安全关键路径
-- Data integrity operations
+-   数据完整性操作
-- Regulatory compliance requirements
+-   法规遵从性要求
-- Previously broken functionality (regression prevention)
+-   先前损坏的功能（回归预防）
 
-**Examples:**
+**示例：**
 
-- Payment processing
+-   支付处理
-- Authentication/authorization
+-   认证/授权
-- User data creation/deletion
+-   用户数据创建/删除
-- Financial calculations
+-   财务计算
-- GDPR/privacy compliance
+-   GDPR/隐私合规
 
-**Testing Requirements:**
+**测试要求：**
 
-- Comprehensive coverage at all levels
+-   各级别的全面覆盖
-- Both happy and unhappy paths
+-   正常路径和异常路径
-- Edge cases and error scenarios
+-   边缘情况和错误场景
-- Performance under load
+-   负载下的性能
 
-### P1 - High (Should Test)
+### P1 - 高（应该测试）
 
-**Criteria:**
+**标准：**
 
-- Core user journeys
+-   核心用户旅程
-- Frequently used features
+-   常用功能
-- Features with complex logic
+-   逻辑复杂的功能
-- Integration points between systems
+-   系统之间的集成点
-- Features affecting user experience
+-   影响用户体验的功能
 
-**Examples:**
+**示例：**
 
-- User registration flow
+-   用户注册流程
-- Search functionality
+-   搜索功能
-- Data import/export
+-   数据导入/导出
-- Notification systems
+-   通知系统
-- Dashboard displays
+-   仪表板显示
 
-**Testing Requirements:**
+**测试要求：**
 
-- Primary happy paths required
+-   需要主要的正常路径
-- Key error scenarios
+-   关键错误场景
-- Critical edge cases
+-   关键边缘情况
-- Basic performance validation
+-   基本性能验证
 
-### P2 - Medium (Nice to Test)
+### P2 - 中（最好测试）
 
-**Criteria:**
+**标准：**
 
-- Secondary features
+-   次要功能
-- Admin functionality
+-   管理功能
-- Reporting features
+-   报告功能
-- Configuration options
+-   配置选项
-- UI polish and aesthetics
+-   UI润色和美学
 
-**Examples:**
+**示例：**
 
-- Admin settings panels
+-   管理设置面板
-- Report generation
+-   报告生成
-- Theme customization
+-   主题定制
-- Help documentation
+-   帮助文档
-- Analytics tracking
+-   分析跟踪
 
-**Testing Requirements:**
+**测试要求：**
 
-- Happy path coverage
+-   正常路径覆盖
-- Basic error handling
+-   基本错误处理
-- Can defer edge cases
+-   可以推迟边缘情况
 
-### P3 - Low (Test if Time Permits)
+### P3 - 低（时间允许则测试）
 
-**Criteria:**
+**标准：**
 
-- Rarely used features
+-   很少使用的功能
-- Nice-to-have functionality
+-   锦上添花的功能
-- Cosmetic issues
+-   外观问题
-- Non-critical optimizations
+-   非关键优化
 
-**Examples:**
+**示例：**
 
-- Advanced preferences
+-   高级首选项
-- Legacy feature support
+-   旧功能支持
-- Experimental features
+-   实验性功能
-- Debug utilities
+-   调试工具
 
-**Testing Requirements:**
+**测试要求：**
 
-- Smoke tests only
+-   仅冒烟测试
-- Can rely on manual testing
+-   可以依赖手动测试
-- Document known limitations
+-   记录已知限制
 
-## Risk-Based Priority Adjustments
+## 基于风险的优先级调整
 
-### Increase Priority When:
+### 何时提高优先级：
 
-- High user impact (affects >50% of users)
+-   高用户影响（影响>50%的用户）
-- High financial impact (>$10K potential loss)
+-   高财务影响（>1万美元的潜在损失）
-- Security vulnerability potential
+-   潜在的安全漏洞
-- Compliance/legal requirements
+-   合规/法律要求
-- Customer-reported issues
+-   客户报告的问题
-- Complex implementation (>500 LOC)
+-   复杂实现（>500行代码）
-- Multiple system dependencies
+-   多个系统依赖
 
-### Decrease Priority When:
+### 何时降低优先级：
 
-- Feature flag protected
+-   受功能标志保护
-- Gradual rollout planned
+-   计划逐步推出
-- Strong monitoring in place
+-   有强大的监控
-- Easy rollback capability
+-   易于回滚
-- Low usage metrics
+-   低使用率指标
-- Simple implementation
+-   简单实现
-- Well-isolated component
+-   良好隔离的组件
 
-## Test Coverage by Priority
+## 按优先级划分的测试覆盖率
 
-| Priority | Unit Coverage | Integration Coverage | E2E Coverage       |
+| 优先级 | 单元覆盖率 | 集成覆盖率 | 端到端覆盖率 |
-| -------- | ------------- | -------------------- | ------------------ |
+| --- | --- | --- | --- |
-| P0       | >90%          | >80%                 | All critical paths |
+| P0 | >90% | >80% | 所有关键路径 |
-| P1       | >80%          | >60%                 | Main happy paths   |
+| P1 | >80% | >60% | 主要正常路径 |
-| P2       | >60%          | >40%                 | Smoke tests        |
+| P2 | >60% | >40% | 冒烟测试 |
-| P3       | Best effort   | Best effort          | Manual only        |
+| P3 | 尽力而为 | 尽力而为 | 仅手动 |
 
-## Priority Assignment Rules
+## 优先级分配规则
 
-1. **Start with business impact** - What happens if this fails?
+1.  **从业务影响开始** - 如果失败会怎样？
-2. **Consider probability** - How likely is failure?
+2.  **考虑概率** - 失败的可能性有多大？
-3. **Factor in detectability** - Would we know if it failed?
+3.  **考虑可检测性** - 如果失败了我们能知道吗？
-4. **Account for recoverability** - Can we fix it quickly?
+4.  **考虑可恢复性** - 我们能快速修复吗？
 
-## Priority Decision Tree
+## 优先级决策树
 
 ```
-Is it revenue-critical?
+是否对收入至关重要？
-├─ YES → P0
+├─ 是 → P0
-└─ NO → Does it affect core user journey?
+└─ 否 → 是否影响核心用户旅程？
-    ├─ YES → Is it high-risk?
+    ├─ 是 → 风险高吗？
-    │   ├─ YES → P0
+    │   ├─ 是 → P0
-    │   └─ NO → P1
+    │   └─ 否 → P1
-    └─ NO → Is it frequently used?
+    └─ 否 → 是否经常使用？
-        ├─ YES → P1
+        ├─ 是 → P1
-        └─ NO → Is it customer-facing?
+        └─ 否 → 是否面向客户？
-            ├─ YES → P2
+            ├─ 是 → P2
-            └─ NO → P3
+            └─ 否 → P3
 ```
 
-## Test Execution Order
+## 测试执行顺序
 
-1. Execute P0 tests first (fail fast on critical issues)
+1.  首先执行P0测试（在关键问题上快速失败）
-2. Execute P1 tests second (core functionality)
+2.  其次执行P1测试（核心功能）
-3. Execute P2 tests if time permits
+3.  如果时间允许，执行P2测试
-4. P3 tests only in full regression cycles
+4.  仅在完整回归周期中执行P3测试
 
-## Continuous Adjustment
+## 持续调整
 
-Review and adjust priorities based on:
+根据以下情况审查和调整优先级：
 
-- Production incident patterns
+-   生产事故模式
-- User feedback and complaints
+-   用户反馈和投诉
-- Usage analytics
+-   使用情况分析
-- Test failure history
+-   测试失败历史
-- Business priority changes
+-   业务优先级变更

bmad-core/tasks/advanced-elicitation.md

@@ -1,119 +1,119 @@
-<!-- Powered by BMAD™ Core -->
+<!-- 由 BMAD™ Core 驱动 -->
 
-# Advanced Elicitation Task
+# 高级启发任务
 
-## Purpose
+## 目的
 
-- Provide optional reflective and brainstorming actions to enhance content quality
+-   提供可选的反思和头脑风暴行动，以提高内容质量
-- Enable deeper exploration of ideas through structured elicitation techniques
+-   通过结构化的启发技术，实现对思想的更深层次探索
-- Support iterative refinement through multiple analytical perspectives
+-   通过多种分析视角支持迭代式完善
-- Usable during template-driven document creation or any chat conversation
+-   可在模板驱动的文档创建或任何聊天对话中使用
 
-## Usage Scenarios
+## 使用场景
 
-### Scenario 1: Template Document Creation
+### 场景1：模板文档创建
 
-After outputting a section during document creation:
+在文档创建过程中输出一个部分后：
 
-1. **Section Review**: Ask user to review the drafted section
+1.  **部分审查**：要求用户审查草拟的部分
-2. **Offer Elicitation**: Present 9 carefully selected elicitation methods
+2.  **提供启发选项**：呈现9种精心挑选的启发方法
-3. **Simple Selection**: User types a number (0-8) to engage method, or 9 to proceed
+3.  **简单选择**：用户输入数字（0-8）以使用该方法，或输入9继续
-4. **Execute & Loop**: Apply selected method, then re-offer choices until user proceeds
+4.  **执行并循环**：应用所选方法，然后重新提供选项，直到用户继续
 
-### Scenario 2: General Chat Elicitation
+### 场景2：通用聊天启发
 
-User can request advanced elicitation on any agent output:
+用户可以对任何代理输出请求高级启发：
 
-- User says "do advanced elicitation" or similar
+-   用户说“进行高级启发”或类似的话
-- Agent selects 9 relevant methods for the context
+-   代理根据上下文选择9种相关方法
-- Same simple 0-9 selection process
+-   同样简单的0-9选择过程
 
-## Task Instructions
+## 任务说明
 
-### 1. Intelligent Method Selection
+### 1. 智能方法选择
 
-**Context Analysis**: Before presenting options, analyze:
+**上下文分析**：在呈现选项之前，分析：
 
-- **Content Type**: Technical specs, user stories, architecture, requirements, etc.
+-   **内容类型**：技术规范、用户故事、架构、需求等。
-- **Complexity Level**: Simple, moderate, or complex content
+-   **复杂程度**：简单、中等或复杂的内容
-- **Stakeholder Needs**: Who will use this information
+-   **利益相关者需求**：谁将使用此信息
-- **Risk Level**: High-impact decisions vs routine items
+-   **风险级别**：高影响决策与常规项目
-- **Creative Potential**: Opportunities for innovation or alternatives
+-   **创新潜力**：创新或替代方案的机会
 
-**Method Selection Strategy**:
+**方法选择策略**：
 
-1. **Always Include Core Methods** (choose 3-4):
+1.  **始终包含核心方法**（选择3-4种）：
-   - Expand or Contract for Audience
+    -   为受众扩展或收缩
-   - Critique and Refine
+    -   批判与完善
-   - Identify Potential Risks
+    -   识别潜在风险
-   - Assess Alignment with Goals
+    -   评估与目标的对齐情况
 
-2. **Context-Specific Methods** (choose 4-5):
+2.  **特定上下文方法**（选择4-5种）：
-   - **Technical Content**: Tree of Thoughts, ReWOO, Meta-Prompting
+    -   **技术内容**：思维树、ReWOO、元提示
-   - **User-Facing Content**: Agile Team Perspective, Stakeholder Roundtable
+    -   **面向用户的内容**：敏捷团队视角、利益相关者圆桌会议
-   - **Creative Content**: Innovation Tournament, Escape Room Challenge
+    -   **创意内容**：创新锦标赛、密室逃脱挑战
-   - **Strategic Content**: Red Team vs Blue Team, Hindsight Reflection
+    -   **战略内容**：红队vs蓝队、事后反思
 
-3. **Always Include**: "Proceed / No Further Actions" as option 9
+3.  **始终包含**：“继续/无进一步操作”作为选项9
 
-### 2. Section Context and Review
+### 2. 部分上下文和审查
 
-When invoked after outputting a section:
+在输出一个部分后调用时：
 
-1. **Provide Context Summary**: Give a brief 1-2 sentence summary of what the user should look for in the section just presented
+1.  **提供上下文摘要**：用1-2句话简要总结用户在刚呈现的部分中应注意什么
 
-2. **Explain Visual Elements**: If the section contains diagrams, explain them briefly before offering elicitation options
+2.  **解释视觉元素**：如果部分包含图表，在提供启发选项前简要解释它们
 
-3. **Clarify Scope Options**: If the section contains multiple distinct items, inform the user they can apply elicitation actions to:
+3.  **澄清范围选项**：如果部分包含多个不同项目，告知用户他们可以将启发行动应用于：
-   - The entire section as a whole
+    -   整个部分
-   - Individual items within the section (specify which item when selecting an action)
+    -   部分内的单个项目（选择行动时指明哪个项目）
 
-### 3. Present Elicitation Options
+### 3. 呈现启发选项
 
-**Review Request Process:**
+**审查请求流程：**
 
-- Ask the user to review the drafted section
+-   要求用户审查草拟的部分
-- In the SAME message, inform them they can suggest direct changes OR select an elicitation method
+-   在同一条消息中，告知他们可以直接提出修改建议或选择一种启发方法
-- Present 9 intelligently selected methods (0-8) plus "Proceed" (9)
+-   呈现9种智能选择的方法（0-8）加上“继续”（9）
-- Keep descriptions short - just the method name
+-   描述要简短——只写方法名称
-- Await simple numeric selection
+-   等待简单的数字选择
 
-**Action List Presentation Format:**
+**行动列表呈现格式：**
 
 ```text
-**Advanced Elicitation Options**
+**高级启发选项**
-Choose a number (0-8) or 9 to proceed:
+选择一个数字（0-8）或9以继续：
 
-0. [Method Name]
+0. [方法名称]
-1. [Method Name]
+1. [方法名称]
-2. [Method Name]
+2. [方法名称]
-3. [Method Name]
+3. [方法名称]
-4. [Method Name]
+4. [方法名称]
-5. [Method Name]
+5. [方法名称]
-6. [Method Name]
+6. [方法名称]
-7. [Method Name]
+7. [方法名称]
-8. [Method Name]
+8. [方法名称]
-9. Proceed / No Further Actions
+9. 继续/无进一步操作
 ```
 
-**Response Handling:**
+**响应处理：**
 
-- **Numbers 0-8**: Execute the selected method, then re-offer the choice
+-   **数字0-8**：执行所选方法，然后重新提供选项
-- **Number 9**: Proceed to next section or continue conversation
+-   **数字9**：进入下一部分或继续对话
-- **Direct Feedback**: Apply user's suggested changes and continue
+-   **直接反馈**：应用用户建议的更改并继续
 
-### 4. Method Execution Framework
+### 4. 方法执行框架
 
-**Execution Process:**
+**执行过程：**
 
-1. **Retrieve Method**: Access the specific elicitation method from the elicitation-methods data file
+1.  **检索方法**：从启发方法数据文件中访问特定的启发方法
-2. **Apply Context**: Execute the method from your current role's perspective
+2.  **应用上下文**：从您当前角色的角度执行该方法
-3. **Provide Results**: Deliver insights, critiques, or alternatives relevant to the content
+3.  **提供结果**：提供与内容相关的见解、批判或替代方案
-4. **Re-offer Choice**: Present the same 9 options again until user selects 9 or gives direct feedback
+4.  **重新提供选项**：再次呈现相同的9个选项，直到用户选择9或给出直接反馈
 
-**Execution Guidelines:**
+**执行指南：**
 
-- **Be Concise**: Focus on actionable insights, not lengthy explanations
+-   **简明扼要**：专注于可操作的见解，而非冗长的解释
-- **Stay Relevant**: Tie all elicitation back to the specific content being analyzed
+-   **保持相关性**：将所有启发都与正在分析的具体内容联系起来
-- **Identify Personas**: For multi-persona methods, clearly identify which viewpoint is speaking
+-   **识别角色**：对于多角色方法，清楚地识别是哪个视角在发言
-- **Maintain Flow**: Keep the process moving efficiently
+-   **保持流程**：高效地推进过程

bmad-core/tasks/apply-qa-fixes.md

@@ -1,150 +1,150 @@
-<!-- Powered by BMAD™ Core -->
+<!-- 由 BMAD™ Core 驱动 -->
 
-# apply-qa-fixes
+# 应用QA修复
 
-Implement fixes based on QA results (gate and assessments) for a specific story. This task is for the Dev agent to systematically consume QA outputs and apply code/test changes while only updating allowed sections in the story file.
+根据特定故事的QA结果（门禁和评估）实施修复。此任务供开发代理系统地使用QA输出并应用代码/测试更改，同时仅更新故事文件中允许的部分。
 
-## Purpose
+## 目的
 
-- Read QA outputs for a story (gate YAML + assessment markdowns)
+-   读取故事的QA输出（门禁YAML + 评估markdown）
-- Create a prioritized, deterministic fix plan
+-   创建优先的、确定性的修复计划
-- Apply code and test changes to close gaps and address issues
+-   应用代码和测试更改以弥补差距和解决问题
-- Update only the allowed story sections for the Dev agent
+-   仅更新开发代理允许的故事部分
 
-## Inputs
+## 输入
 
 ```yaml
 required:
-  - story_id: '{epic}.{story}' # e.g., "2.2"
+  - story_id: '{epic}.{story}' # 例如, "2.2"
-  - qa_root: from `bmad-core/core-config.yaml` key `qa.qaLocation` (e.g., `docs/project/qa`)
+  - qa_root: 来自 `bmad-core/core-config.yaml` 键 `qa.qaLocation` (例如, `docs/project/qa`)
-  - story_root: from `bmad-core/core-config.yaml` key `devStoryLocation` (e.g., `docs/project/stories`)
+  - story_root: 来自 `bmad-core/core-config.yaml` 键 `devStoryLocation` (例如, `docs/project/stories`)
 
 optional:
-  - story_title: '{title}' # derive from story H1 if missing
+  - story_title: '{title}' # 如果缺少，则从故事的H1派生
-  - story_slug: '{slug}' # derive from title (lowercase, hyphenated) if missing
+  - story_slug: '{slug}' # 如果缺少，则从标题派生 (小写，连字符连接)
 ```
 
-## QA Sources to Read
+## 要读取的QA源
 
-- Gate (YAML): `{qa_root}/gates/{epic}.{story}-*.yml`
+-   门禁 (YAML): `{qa_root}/gates/{epic}.{story}-*.yml`
-  - If multiple, use the most recent by modified time
+    -   如果有多个，则使用修改时间最新的一个
-- Assessments (Markdown):
+-   评估 (Markdown):
-  - Test Design: `{qa_root}/assessments/{epic}.{story}-test-design-*.md`
+    -   测试设计: `{qa_root}/assessments/{epic}.{story}-test-design-*.md`
-  - Traceability: `{qa_root}/assessments/{epic}.{story}-trace-*.md`
+    -   可追溯性: `{qa_root}/assessments/{epic}.{story}-trace-*.md`
-  - Risk Profile: `{qa_root}/assessments/{epic}.{story}-risk-*.md`
+    -   风险概况: `{qa_root}/assessments/{epic}.{story}-risk-*.md`
-  - NFR Assessment: `{qa_root}/assessments/{epic}.{story}-nfr-*.md`
+    -   非功能性需求评估: `{qa_root}/assessments/{epic}.{story}-nfr-*.md`
 
-## Prerequisites
+## 先决条件
 
-- Repository builds and tests run locally (Deno 2)
+-   仓库在本地构建和测试运行 (Deno 2)
-- Lint and test commands available:
+-   可用的Lint和测试命令:
     -   `deno lint`
     -   `deno test -A`
 
-## Process (Do not skip steps)
+## 流程 (不要跳过步骤)
 
-### 0) Load Core Config & Locate Story
+### 0) 加载核心配置并定位故事
 
-- Read `bmad-core/core-config.yaml` and resolve `qa_root` and `story_root`
+-   读取 `bmad-core/core-config.yaml` 并解析 `qa_root` 和 `story_root`
-- Locate story file in `{story_root}/{epic}.{story}.*.md`
+-   在 `{story_root}/{epic}.{story}.*.md` 中定位故事文件
-  - HALT if missing and ask for correct story id/path
+    -   如果缺少，则停止并要求正确的故事ID/路径
 
-### 1) Collect QA Findings
+### 1) 收集QA发现
 
-- Parse the latest gate YAML:
+-   解析最新的门禁YAML:
     -   `gate` (PASS|CONCERNS|FAIL|WAIVED)
-  - `top_issues[]` with `id`, `severity`, `finding`, `suggested_action`
+    -   `top_issues[]` 包含 `id`, `severity`, `finding`, `suggested_action`
-  - `nfr_validation.*.status` and notes
+    -   `nfr_validation.*.status` 和注释
-  - `trace` coverage summary/gaps
+    -   `trace` 覆盖范围摘要/差距
     -   `test_design.coverage_gaps[]`
-  - `risk_summary.recommendations.must_fix[]` (if present)
+    -   `risk_summary.recommendations.must_fix[]` (如果存在)
-- Read any present assessment markdowns and extract explicit gaps/recommendations
+-   读取任何存在的评估markdown并提取明确的差距/建议
 
-### 2) Build Deterministic Fix Plan (Priority Order)
+### 2) 构建确定性修复计划 (按优先级顺序)
 
-Apply in order, highest priority first:
+按顺序应用，优先级最高的优先：
 
-1. High severity items in `top_issues` (security/perf/reliability/maintainability)
+1.  `top_issues` 中的高严重性项目 (安全/性能/可靠性/可维护性)
-2. NFR statuses: all FAIL must be fixed → then CONCERNS
+2.  NFR状态：所有FAIL必须修复 → 然后是CONCERNS
-3. Test Design `coverage_gaps` (prioritize P0 scenarios if specified)
+3.  测试设计 `coverage_gaps` (如果指定，则优先处理P0场景)
-4. Trace uncovered requirements (AC-level)
+4.  Trace未覆盖的需求 (AC级别)
-5. Risk `must_fix` recommendations
+5.  风险 `must_fix` 建议
-6. Medium severity issues, then low
+6.  中等严重性问题，然后是低严重性问题
 
-Guidance:
+指导：
 
-- Prefer tests closing coverage gaps before/with code changes
+-   在代码更改之前/同时，优先选择弥补覆盖差距的测试
-- Keep changes minimal and targeted; follow project architecture and TS/Deno rules
+-   保持更改最小化和有针对性；遵循项目架构和TS/Deno规则
 
-### 3) Apply Changes
+### 3) 应用更改
 
-- Implement code fixes per plan
+-   根据计划实施代码修复
-- Add missing tests to close coverage gaps (unit first; integration where required by AC)
+-   添加缺失的测试以弥补覆盖差距 (单元测试优先；根据AC要求进行集成测试)
-- Keep imports centralized via `deps.ts` (see `docs/project/typescript-rules.md`)
+-   通过 `deps.ts` 保持导入集中化 (参见 `docs/project/typescript-rules.md`)
-- Follow DI boundaries in `src/core/di.ts` and existing patterns
+-   遵循 `src/core/di.ts` 中的DI边界和现有模式
 
-### 4) Validate
+### 4) 验证
 
-- Run `deno lint` and fix issues
+-   运行 `deno lint` 并修复问题
-- Run `deno test -A` until all tests pass
+-   运行 `deno test -A` 直到所有测试通过
-- Iterate until clean
+-   迭代直到干净
 
-### 5) Update Story (Allowed Sections ONLY)
+### 5) 更新故事 (仅限允许的部分)
 
-CRITICAL: Dev agent is ONLY authorized to update these sections of the story file. Do not modify any other sections (e.g., QA Results, Story, Acceptance Criteria, Dev Notes, Testing):
+关键：开发代理仅被授权更新故事文件的这些部分。不要修改任何其他部分 (例如, QA结果, 故事, 验收标准, 开发说明, 测试):
 
-- Tasks / Subtasks Checkboxes (mark any fix subtask you added as done)
+-   任务/子任务复选框 (将您添加的任何修复子任务标记为完成)
-- Dev Agent Record →
+-   开发代理记录 →
-  - Agent Model Used (if changed)
+    -   使用的代理模型 (如果更改)
-  - Debug Log References (commands/results, e.g., lint/tests)
+    -   调试日志参考 (命令/结果, 例如, lint/tests)
-  - Completion Notes List (what changed, why, how)
+    -   完成说明列表 (更改了什么, 为什么, 如何)
-  - File List (all added/modified/deleted files)
+    -   文件列表 (所有添加/修改/删除的文件)
-- Change Log (new dated entry describing applied fixes)
+-   更改日志 (描述应用的修复的新的带日期的条目)
-- Status (see Rule below)
+-   状态 (见下文规则)
 
-Status Rule:
+状态规则：
 
-- If gate was PASS and all identified gaps are closed → set `Status: Ready for Done`
+-   如果门禁为PASS且所有已识别的差距都已弥补 → 设置 `Status: Ready for Done`
-- Otherwise → set `Status: Ready for Review` and notify QA to re-run the review
+-   否则 → 设置 `Status: Ready for Review` 并通知QA重新运行审查
 
-### 6) Do NOT Edit Gate Files
+### 6) 不要编辑门禁文件
 
-- Dev does not modify gate YAML. If fixes address issues, request QA to re-run `review-story` to update the gate
+-   开发人员不修改门禁YAML。如果修复解决了问题，请请求QA重新运行 `review-story` 以更新门禁
 
-## Blocking Conditions
+## 阻塞条件
 
-- Missing `bmad-core/core-config.yaml`
+-   缺少 `bmad-core/core-config.yaml`
-- Story file not found for `story_id`
+-   找不到 `story_id` 的故事文件
-- No QA artifacts found (neither gate nor assessments)
+-   未找到QA工件 (门禁和评估都没有)
-  - HALT and request QA to generate at least a gate file (or proceed only with clear developer-provided fix list)
+    -   停止并请求QA生成至少一个门禁文件 (或仅在有明确的开发人员提供的修复列表的情况下继续)
 
-## Completion Checklist
+## 完成清单
 
-- deno lint: 0 problems
+-   deno lint: 0个问题
-- deno test -A: all tests pass
+-   deno test -A: 所有测试通过
-- All high severity `top_issues` addressed
+-   所有高严重性的 `top_issues` 已解决
-- NFR FAIL → resolved; CONCERNS minimized or documented
+-   NFR FAIL → 已解决; CONCERNS 已最小化或记录
-- Coverage gaps closed or explicitly documented with rationale
+-   覆盖差距已弥补或用理由明确记录
-- Story updated (allowed sections only) including File List and Change Log
+-   故事已更新 (仅限允许的部分)，包括文件列表和更改日志
-- Status set according to Status Rule
+-   状态已根据状态规则设置
 
-## Example: Story 2.2
+## 示例：故事2.2
 
-Given gate `docs/project/qa/gates/2.2-*.yml` shows
+给定门禁 `docs/project/qa/gates/2.2-*.yml` 显示
 
-- `coverage_gaps`: Back action behavior untested (AC2)
+-   `coverage_gaps`: 未测试返回操作行为 (AC2)
-- `coverage_gaps`: Centralized dependencies enforcement untested (AC4)
+-   `coverage_gaps`: 未测试集中化依赖项强制执行 (AC4)
 
-Fix plan:
+修复计划：
 
-- Add a test ensuring the Toolkit Menu "Back" action returns to Main Menu
+-   添加一个测试，确保工具包菜单的“返回”操作返回到主菜单
-- Add a static test verifying imports for service/view go through `deps.ts`
+-   添加一个静态测试，验证服务/视图的导入通过 `deps.ts`
-- Re-run lint/tests and update Dev Agent Record + File List accordingly
+-   重新运行lint/tests并相应地更新开发代理记录 + 文件列表
 
-## Key Principles
+## 关键原则
 
-- Deterministic, risk-first prioritization
+-   确定性的、风险优先的优先级排序
-- Minimal, maintainable changes
+-   最小的、可维护的更改
-- Tests validate behavior and close gaps
+-   测试验证行为并弥补差距
-- Strict adherence to allowed story update areas
+-   严格遵守允许的故事更新区域
-- Gate ownership remains with QA; Dev signals readiness via Status
+-   门禁所有权仍归QA所有；开发通过状态信号表示准备就绪

bmad-core/tasks/brownfield-create-epic.md

@@ -1,162 +1,162 @@
-<!-- Powered by BMAD™ Core -->
+<!-- 由 BMAD™ Core 驱动 -->
 
-# Create Brownfield Epic Task
+# 创建棕地史诗任务
 
-## Purpose
+## 目的
 
-Create a single epic for smaller brownfield enhancements that don't require the full PRD and Architecture documentation process. This task is for isolated features or modifications that can be completed within a focused scope.
+为不需要完整PRD和架构文档流程的较小规模棕地增强项目创建一个独立的史诗。此任务适用于可以在一个专注范围内完成的孤立功能或修改。
 
-## When to Use This Task
+## 何时使用此任务
 
-**Use this task when:**
+**在以下情况下使用此任务：**
 
-- The enhancement can be completed in 1-3 stories
+-   增强功能可以在1-3个故事内完成
-- No significant architectural changes are required
+-   不需要重大的架构变更
-- The enhancement follows existing project patterns
+-   增强功能遵循现有的项目模式
-- Integration complexity is minimal
+-   集成复杂度最低
-- Risk to existing system is low
+-   对现有系统的风险较低
 
-**Use the full brownfield PRD/Architecture process when:**
+**在以下情况下使用完整的棕地PRD/架构流程：**
 
-- The enhancement requires multiple coordinated stories
+-   增强功能需要多个协调的故事
-- Architectural planning is needed
+-   需要进行架构规划
-- Significant integration work is required
+-   需要大量的集成工作
-- Risk assessment and mitigation planning is necessary
+-   需要进行风险评估和缓解规划
 
-## Instructions
+## 说明
 
-### 1. Project Analysis (Required)
+### 1. 项目分析（必需）
 
-Before creating the epic, gather essential information about the existing project:
+在创建史诗之前，收集有关现有项目的重要信息：
 
-**Existing Project Context:**
+**现有项目背景：**
 
-- [ ] Project purpose and current functionality understood
+- [ ] 理解项目目的和当前功能
-- [ ] Existing technology stack identified
+- [ ] 确定现有技术栈
-- [ ] Current architecture patterns noted
+- [ ] 注意到当前的架构模式
-- [ ] Integration points with existing system identified
+- [ ] 确定与现有系统的集成点
 
-**Enhancement Scope:**
+**增强范围：**
 
-- [ ] Enhancement clearly defined and scoped
+- [ ] 明确定义和界定增强范围
-- [ ] Impact on existing functionality assessed
+- [ ] 评估对现有功能的影响
-- [ ] Required integration points identified
+- [ ] 确定所需的集成点
-- [ ] Success criteria established
+- [ ] 建立成功标准
 
-### 2. Epic Creation
+### 2. 史诗创建
 
-Create a focused epic following this structure:
+按照此结构创建一个专注的史诗：
 
-#### Epic Title
+#### 史诗标题
 
-{{Enhancement Name}} - Brownfield Enhancement
+{{增强功能名称}} - 棕地增强
 
-#### Epic Goal
+#### 史诗目标
 
-{{1-2 sentences describing what the epic will accomplish and why it adds value}}
+{{1-2句话描述该史诗将完成什么以及为什么它能增加价值}}
 
-#### Epic Description
+#### 史诗描述
 
-**Existing System Context:**
+**现有系统背景：**
 
-- Current relevant functionality: {{brief description}}
+-   当前相关功能：{{简要描述}}
-- Technology stack: {{relevant existing technologies}}
+-   技术栈：{{相关的现有技术}}
-- Integration points: {{where new work connects to existing system}}
+-   集成点：{{新工作与现有系统连接的地方}}
 
-**Enhancement Details:**
+**增强详情：**
 
-- What's being added/changed: {{clear description}}
+-   正在添加/更改的内容：{{清晰的描述}}
-- How it integrates: {{integration approach}}
+-   如何集成：{{集成方法}}
-- Success criteria: {{measurable outcomes}}
+-   成功标准：{{可衡量的结果}}
 
-#### Stories
+#### 故事
 
-List 1-3 focused stories that complete the epic:
+列出1-3个完成该史诗的专注故事：
 
-1. **Story 1:** {{Story title and brief description}}
+1.  **故事1：** {{故事标题和简要描述}}
-2. **Story 2:** {{Story title and brief description}}
+2.  **故事2：** {{故事标题和简要描述}}
-3. **Story 3:** {{Story title and brief description}}
+3.  **故事3：** {{故事标题和简要描述}}
 
-#### Compatibility Requirements
+#### 兼容性要求
 
-- [ ] Existing APIs remain unchanged
+- [ ] 现有API保持不变
-- [ ] Database schema changes are backward compatible
+- [ ] 数据库模式变更是向后兼容的
-- [ ] UI changes follow existing patterns
+- [ ] UI变更遵循现有模式
-- [ ] Performance impact is minimal
+- [ ] 性能影响最小
 
-#### Risk Mitigation
+#### 风险缓解
 
-- **Primary Risk:** {{main risk to existing system}}
+-   **主要风险：** {{对现有系统的主要风险}}
-- **Mitigation:** {{how risk will be addressed}}
+-   **缓解措施：** {{将如何解决风险}}
-- **Rollback Plan:** {{how to undo changes if needed}}
+-   **回滚计划：** {{如果需要，如何撤销更改}}
 
-#### Definition of Done
+#### 完成的定义
 
-- [ ] All stories completed with acceptance criteria met
+- [ ] 所有故事均已完成，并满足验收标准
-- [ ] Existing functionality verified through testing
+- [ ] 通过测试验证了现有功能
-- [ ] Integration points working correctly
+- [ ] 集成点工作正常
-- [ ] Documentation updated appropriately
+- [ ] 适当更新了文档
-- [ ] No regression in existing features
+- [ ] 现有功能无回归
 
-### 3. Validation Checklist
+### 3. 验证清单
 
-Before finalizing the epic, ensure:
+在最终确定史诗之前，请确保：
 
-**Scope Validation:**
+**范围验证：**
 
-- [ ] Epic can be completed in 1-3 stories maximum
+- [ ] 史诗最多可在1-3个故事内完成
-- [ ] No architectural documentation is required
+- [ ] 不需要架构文档
-- [ ] Enhancement follows existing patterns
+- [ ] 增强功能遵循现有模式
-- [ ] Integration complexity is manageable
+- [ ] 集成复杂度可管理
 
-**Risk Assessment:**
+**风险评估：**
 
-- [ ] Risk to existing system is low
+- [ ] 对现有系统的风险较低
-- [ ] Rollback plan is feasible
+- [ ] 回滚计划是可行的
-- [ ] Testing approach covers existing functionality
+- [ ] 测试方法覆盖了现有功能
-- [ ] Team has sufficient knowledge of integration points
+- [ ] 团队对集成点有足够的了解
 
-**Completeness Check:**
+**完整性检查：**
 
-- [ ] Epic goal is clear and achievable
+- [ ] 史诗目标清晰且可实现
-- [ ] Stories are properly scoped
+- [ ] 故事范围界定得当
-- [ ] Success criteria are measurable
+- [ ] 成功标准是可衡量的
-- [ ] Dependencies are identified
+- [ ] 确定了依赖关系
 
-### 4. Handoff to Story Manager
+### 4. 交接给故事管理员
 
-Once the epic is validated, provide this handoff to the Story Manager:
+一旦史诗经过验证，将此交接提供给故事管理员：
 
 ---
 
-**Story Manager Handoff:**
+**故事管理员交接：**
 
-"Please develop detailed user stories for this brownfield epic. Key considerations:
+“请为此棕地史诗制定详细的用户故事。关键考虑因素：
 
-- This is an enhancement to an existing system running {{technology stack}}
+-   这是对运行{{technology stack}}的现有系统的增强
-- Integration points: {{list key integration points}}
+-   集成点：{{列出关键集成点}}
-- Existing patterns to follow: {{relevant existing patterns}}
+-   要遵循的现有模式：{{相关的现有模式}}
-- Critical compatibility requirements: {{key requirements}}
+-   关键兼容性要求：{{关键要求}}
-- Each story must include verification that existing functionality remains intact
+-   每个故事都必须包括对现有功能保持不变的验证
 
-The epic should maintain system integrity while delivering {{epic goal}}."
+该史诗应在交付{{epic goal}}的同时保持系统完整性。”
 
 ---
 
-## Success Criteria
+## 成功标准
 
-The epic creation is successful when:
+当满足以下条件时，史诗创建成功：
 
-1. Enhancement scope is clearly defined and appropriately sized
+1.  增强范围定义清晰且大小适当
-2. Integration approach respects existing system architecture
+2.  集成方法尊重现有系统架构
-3. Risk to existing functionality is minimized
+3.  对现有功能的风险最小化
-4. Stories are logically sequenced for safe implementation
+4.  故事按逻辑顺序排列以确保安全实施
-5. Compatibility requirements are clearly specified
+5.  明确规定了兼容性要求
-6. Rollback plan is feasible and documented
+6.  回滚计划可行且已记录
 
-## Important Notes
+## 重要说明
 
-- This task is specifically for SMALL brownfield enhancements
+-   此任务专门用于小规模的棕地增强
-- If the scope grows beyond 3 stories, consider the full brownfield PRD process
+-   如果范围超出3个故事，请考虑完整的棕地PRD流程
-- Always prioritize existing system integrity over new functionality
+-   始终将现有系统的完整性置于新功能之上
-- When in doubt about scope or complexity, escalate to full brownfield planning
+-   当对范围或复杂性有疑问时，升级到完整的棕地规划流程

bmad-core/tasks/brownfield-create-story.md

@@ -1,149 +1,155 @@
-<!-- Powered by BMAD™ Core -->
+<!-- 由 BMAD™ Core 驱动 -->
 
-# Create Brownfield Story Task
+# 创建棕地故事任务
 
-## Purpose
+## 目的
 
-Create a single user story for very small brownfield enhancements that can be completed in one focused development session. This task is for minimal additions or bug fixes that require existing system integration awareness.
+为非常小的棕地增强创建一个单一的用户故事，这些增强可以在一次专注的开发会话中完成。此任务适用于需要了解现有系统集成的最小添加或错误修复。
 
-## When to Use This Task
+## 何时使用此任务
 
-**Use this task when:**
+**在以下情况下使用此任务：**
 
-- The enhancement can be completed in a single story
+-   增强功能可以在一个故事中完成
-- No new architecture or significant design is required
+-   不需要新的架构或重要的设计
-- The change follows existing patterns exactly
+-   更改完全遵循现有模式
-- Integration is straightforward with minimal risk
+-   集成直接且风险最小
-- Change is isolated with clear boundaries
+-   更改是孤立的，边界清晰
 
-**Use brownfield-create-epic when:**
+**在以下情况下使用 brownfield-create-epic：**
 
-- The enhancement requires 2-3 coordinated stories
+-   增强功能需要2-3个协调的故事
-- Some design work is needed
+-   需要一些设计工作
-- Multiple integration points are involved
+-   涉及多个集成点
 
-**Use the full brownfield PRD/Architecture process when:**
+**在以下情况下使用完整的棕地PRD/架构流程：**
 
-- The enhancement requires multiple coordinated stories
+-   增强功能需要多个协调的故事
-- Architectural planning is needed
+-   需要进行架构规划
-- Significant integration work is required
+-   需要大量的集成工作
 
-## Instructions
+## 说明
 
-### 1. Quick Project Assessment
+### 1. 快速项目评估
 
-Gather minimal but essential context about the existing project:
+收集关于现有项目的最少但必要的信息：
 
-**Current System Context:**
+**当前系统背景：**
 
-- [ ] Relevant existing functionality identified
+- [ ] 确定了相关的现有功能
-- [ ] Technology stack for this area noted
+- [ ] 注意到该领域的技术栈
-- [ ] Integration point(s) clearly understood
+- [ ] 清楚地理解了集成点
-- [ ] Existing patterns for similar work identified
+- [ ] 确定了类似工作的现有模式
 
-**Change Scope:**
+**变更范围：**
 
-- [ ] Specific change clearly defined
+- [ ] 明确定义了具体变更
-- [ ] Impact boundaries identified
+- [ ] 确定了影响边界
-- [ ] Success criteria established
+- [ ] 建立了成功标准
 
-### 2. Story Creation
+### 2. 故事创建
 
-Create a single focused story following this structure:
+按照此结构创建一个专注的单一故事：
 
-#### Story Title
+#### 故事标题
 
-{{Specific Enhancement}} - Brownfield Addition
+{{具体增强}} - 棕地添加
 
-#### User Story
+#### 用户故事
 
-As a {{user type}},
+作为一个{{用户类型}}，
-I want {{specific action/capability}},
+我想要{{具体行动/能力}}，
-So that {{clear benefit/value}}.
+以便于{{明确的益处/价值}}。
 
-#### Story Context
+#### 故事背景
 
-**Existing System Integration:**
+**现有系统集成：**
 
-- Integrates with: {{existing component/system}}
+-   集成于：{{现有组件/系统}}
-- Technology: {{relevant tech stack}}
+-   技术：{{相关技术栈}}
-- Follows pattern: {{existing pattern to follow}}
+-   遵循模式：{{要遵循的现有模式}}
-- Touch points: {{specific integration points}}
+-   接触点：{{具体的集成点}}
 
-#### Acceptance Criteria
+#### 验收标准
 
-**Functional Requirements:**
+**功能性需求：**
 
-1. {{Primary functional requirement}}
+1.  {{主要功能性需求}}
-2. {{Secondary functional requirement (if any)}}
+2.  {{次要功能性需求（如有）}}
-3. {{Integration requirement}}
+3.  {{集成需求}}
 
-**Integration Requirements:** 4. Existing {{relevant functionality}} continues to work unchanged 5. New functionality follows existing {{pattern}} pattern 6. Integration with {{system/component}} maintains current behavior
+**集成需求：**
+4. 现有{{相关功能}}继续保持不变
+5. 新功能遵循现有{{模式}}模式
+6. 与{{系统/组件}}的集成保持当前行为
 
-**Quality Requirements:** 7. Change is covered by appropriate tests 8. Documentation is updated if needed 9. No regression in existing functionality verified
+**质量需求：**
+7. 更改由适当的测试覆盖
+8. 如果需要，更新文档
+9. 验证现有功能无回归
 
-#### Technical Notes
+#### 技术说明
 
-- **Integration Approach:** {{how it connects to existing system}}
+-   **集成方法：** {{它如何连接到现有系统}}
-- **Existing Pattern Reference:** {{link or description of pattern to follow}}
+-   **现有模式参考：** {{要遵循的模式的链接或描述}}
-- **Key Constraints:** {{any important limitations or requirements}}
+-   **关键约束：** {{任何重要的限制或要求}}
 
-#### Definition of Done
+#### 完成的定义
 
-- [ ] Functional requirements met
+- [ ] 满足功能性需求
-- [ ] Integration requirements verified
+- [ ] 验证了集成需求
-- [ ] Existing functionality regression tested
+- [ ] 对现有功能进行了回归测试
-- [ ] Code follows existing patterns and standards
+- [ ] 代码遵循现有模式和标准
-- [ ] Tests pass (existing and new)
+- [ ] 测试通过（现有和新的）
-- [ ] Documentation updated if applicable
+- [ ] 如果适用，更新了文档
 
-### 3. Risk and Compatibility Check
+### 3. 风险和兼容性检查
 
-**Minimal Risk Assessment:**
+**最小风险评估：**
 
-- **Primary Risk:** {{main risk to existing system}}
+-   **主要风险：** {{对现有系统的主要风险}}
-- **Mitigation:** {{simple mitigation approach}}
+-   **缓解措施：** {{简单的缓解方法}}
-- **Rollback:** {{how to undo if needed}}
+-   **回滚：** {{如果需要，如何撤销}}
 
-**Compatibility Verification:**
+**兼容性验证：**
 
-- [ ] No breaking changes to existing APIs
+- [ ] 对现有API无重大变更
-- [ ] Database changes (if any) are additive only
+- [ ] 数据库变更（如有）仅为增量式
-- [ ] UI changes follow existing design patterns
+- [ ] UI变更遵循现有设计模式
-- [ ] Performance impact is negligible
+- [ ] 性能影响可忽略不计
 
-### 4. Validation Checklist
+### 4. 验证清单
 
-Before finalizing the story, confirm:
+在最终确定故事之前，请确认：
 
-**Scope Validation:**
+**范围验证：**
 
-- [ ] Story can be completed in one development session
+- [ ] 故事可以在一次开发会话中完成
-- [ ] Integration approach is straightforward
+- [ ] 集成方法直接
-- [ ] Follows existing patterns exactly
+- [ ] 完全遵循现有模式
-- [ ] No design or architecture work required
+- [ ] 不需要设计或架构工作
 
-**Clarity Check:**
+**清晰度检查：**
 
-- [ ] Story requirements are unambiguous
+- [ ] 故事需求明确
-- [ ] Integration points are clearly specified
+- [ ] 集成点明确指定
-- [ ] Success criteria are testable
+- [ ] 成功标准可测试
-- [ ] Rollback approach is simple
+- [ ] 回滚方法简单
 
-## Success Criteria
+## 成功标准
 
-The story creation is successful when:
+当满足以下条件时，故事创建成功：
 
-1. Enhancement is clearly defined and appropriately scoped for single session
+1.  增强功能定义清晰，范围适合单次会话
-2. Integration approach is straightforward and low-risk
+2.  集成方法直接且风险低
-3. Existing system patterns are identified and will be followed
+3.  确定并将遵循现有系统模式
-4. Rollback plan is simple and feasible
+4.  回滚计划简单可行
-5. Acceptance criteria include existing functionality verification
+5.  验收标准包括对现有功能的验证
 
-## Important Notes
+## 重要说明
 
-- This task is for VERY SMALL brownfield changes only
+-   此任务仅适用于非常小的棕地变更
-- If complexity grows during analysis, escalate to brownfield-create-epic
+-   如果分析过程中复杂性增加，请升级到 brownfield-create-epic
-- Always prioritize existing system integrity
+-   始终将现有系统的完整性置于首位
-- When in doubt about integration complexity, use brownfield-create-epic instead
+-   当对集成复杂性有疑问时，请改用 brownfield-create-epic
-- Stories should take no more than 4 hours of focused development work
+-   故事的专注开发工作时间不应超过4小时

bmad-core/tasks/correct-course.md

@@ -1,72 +1,72 @@
-<!-- Powered by BMAD™ Core -->
+<!-- 由 BMAD™ Core 驱动 -->
 
-# Correct Course Task
+# 纠正航向任务
 
-## Purpose
+## 目的
 
-- Guide a structured response to a change trigger using the `{root}/checklists/change-checklist`.
+-   使用 `{root}/checklists/change-checklist` 指导对变更触发器的结构化响应。
-- Analyze the impacts of the change on epics, project artifacts, and the MVP, guided by the checklist's structure.
+-   在清单结构的指导下，分析变更对史诗、项目工件和MVP的影响。
-- Explore potential solutions (e.g., adjust scope, rollback elements, re-scope features) as prompted by the checklist.
+-   按照清单的提示，探索潜在的解决方案（例如，调整范围、回滚元素、重新界定功能范围）。
-- Draft specific, actionable proposed updates to any affected project artifacts (e.g., epics, user stories, PRD sections, architecture document sections) based on the analysis.
+-   根据分析，为任何受影响的项目工件（例如，史诗、用户故事、PRD部分、架构文档部分）起草具体的、可操作的拟议更新。
-- Produce a consolidated "Sprint Change Proposal" document that contains the impact analysis and the clearly drafted proposed edits for user review and approval.
+-   生成一份整合的“冲刺变更提案”文档，其中包含影响分析和清晰起草的拟议编辑，供用户审查和批准。
-- Ensure a clear handoff path if the nature of the changes necessitates fundamental replanning by other core agents (like PM or Architect).
+-   如果变更的性质需要其他核心代理（如PM或架构师）进行根本性的重新规划，确保有清晰的交接路径。
 
-## Instructions
+## 说明
 
-### 1. Initial Setup & Mode Selection
+### 1. 初始设置和模式选择
 
-- **Acknowledge Task & Inputs:**
+-   **确认任务和输入：**
-  - Confirm with the user that the "Correct Course Task" (Change Navigation & Integration) is being initiated.
+    -   向用户确认正在启动“纠正航向任务”（变更导航与集成）。
-  - Verify the change trigger and ensure you have the user's initial explanation of the issue and its perceived impact.
+    -   验证变更触发器，并确保您已获得用户对问题及其感知影响的初步解释。
-  - Confirm access to all relevant project artifacts (e.g., PRD, Epics/Stories, Architecture Documents, UI/UX Specifications) and, critically, the `{root}/checklists/change-checklist`.
+    -   确认可以访问所有相关的项目工件（例如，PRD、史诗/故事、架构文档、UI/UX规范），以及至关重要的`{root}/checklists/change-checklist`。
-- **Establish Interaction Mode:**
+-   **建立交互模式：**
-  - Ask the user their preferred interaction mode for this task:
+    -   询问用户他们对此任务的首选交互模式：
-    - **"Incrementally (Default & Recommended):** Shall we work through the change-checklist section by section, discussing findings and collaboratively drafting proposed changes for each relevant part before moving to the next? This allows for detailed, step-by-step refinement."
+        -   **“增量模式（默认和推荐）：** 我们是否应逐节审阅变更清单，讨论发现并协作起草每个相关部分的拟议变更，然后再进行下一部分？这允许进行详细的、逐步的完善。”
-    - **"YOLO Mode (Batch Processing):** Or, would you prefer I conduct a more batched analysis based on the checklist and then present a consolidated set of findings and proposed changes for a broader review? This can be quicker for initial assessment but might require more extensive review of the combined proposals."
+        -   **“YOLO模式（批量处理）：** 或者，您是否希望我根据清单进行更批量的分析，然后提交一份整合的发现和拟议变更集，以进行更广泛的审查？这对于初步评估可能更快，但可能需要对合并的提案进行更广泛的审查。”
-  - Once the user chooses, confirm the selected mode and then inform the user: "We will now use the change-checklist to analyze the change and draft proposed updates. I will guide you through the checklist items based on our chosen interaction mode."
+    -   一旦用户选择，确认所选模式，然后通知用户：“我们现在将使用变更清单来分析变更并起草拟议的更新。我将根据我们选择的交互模式引导您完成清单项目。”
 
-### 2. Execute Checklist Analysis (Iteratively or Batched, per Interaction Mode)
+### 2. 执行清单分析（根据交互模式，迭代或批量进行）
 
-- Systematically work through Sections 1-4 of the change-checklist (typically covering Change Context, Epic/Story Impact Analysis, Artifact Conflict Resolution, and Path Evaluation/Recommendation).
+-   系统地完成变更清单的第1-4节（通常涵盖变更背景、史诗/故事影响分析、工件冲突解决和路径评估/建议）。
-- For each checklist item or logical group of items (depending on interaction mode):
+-   对于每个清单项目或逻辑项目组（取决于交互模式）：
-  - Present the relevant prompt(s) or considerations from the checklist to the user.
+    -   向用户呈现清单中的相关提示或考虑因素。
-  - Request necessary information and actively analyze the relevant project artifacts (PRD, epics, architecture documents, story history, etc.) to assess the impact.
+    -   请求必要的信息，并积极分析相关的项目工件（PRD、史诗、架构文档、故事历史等）以评估影响。
-  - Discuss your findings for each item with the user.
+    -   与用户讨论您对每个项目的发现。
-  - Record the status of each checklist item (e.g., `[x] Addressed`, `[N/A]`, `[!] Further Action Needed`) and any pertinent notes or decisions.
+    -   记录每个清单项目的状态（例如，`[x] 已处理`，`[N/A]`，`[!] 需要进一步行动`）以及任何相关的说明或决定。
-  - Collaboratively agree on the "Recommended Path Forward" as prompted by Section 4 of the checklist.
+    -   按照清单第4节的提示，协作商定“推荐的前进路径”。
 
-### 3. Draft Proposed Changes (Iteratively or Batched)
+### 3. 起草拟议的变更（迭代或批量）
 
-- Based on the completed checklist analysis (Sections 1-4) and the agreed "Recommended Path Forward" (excluding scenarios requiring fundamental replans that would necessitate immediate handoff to PM/Architect):
+-   基于完成的清单分析（第1-4节）和商定的“推荐的前进路径”（不包括需要立即交接给PM/架构师进行根本性重新规划的场景）：
-  - Identify the specific project artifacts that require updates (e.g., specific epics, user stories, PRD sections, architecture document components, diagrams).
+    -   确定需要更新的具体项目工件（例如，特定的史诗、用户故事、PRD部分、架构文档组件、图表）。
-  - **Draft the proposed changes directly and explicitly for each identified artifact.** Examples include:
+    -   **为每个已识别的工件直接且明确地起草拟议的变更。** 示例包括：
-    - Revising user story text, acceptance criteria, or priority.
+        -   修改用户故事文本、验收标准或优先级。
-    - Adding, removing, reordering, or splitting user stories within epics.
+        -   在史诗中添加、删除、重新排序或拆分用户故事。
-    - Proposing modified architecture diagram snippets (e.g., providing an updated Mermaid diagram block or a clear textual description of the change to an existing diagram).
+        -   提出修改后的架构图片段（例如，提供更新的Mermaid图块或对现有图表的清晰文字描述）。
-    - Updating technology lists, configuration details, or specific sections within the PRD or architecture documents.
+        -   更新技术列表、配置细节或PRD或架构文档中的特定部分。
-    - Drafting new, small supporting artifacts if necessary (e.g., a brief addendum for a specific decision).
+        -   如果需要，起草新的、小的支持性工件（例如，针对特定决策的简要附录）。
-  - If in "Incremental Mode," discuss and refine these proposed edits for each artifact or small group of related artifacts with the user as they are drafted.
+    -   如果在“增量模式”下，在起草每个工件或相关工件小组的拟议编辑时，与用户讨论和完善它们。
-  - If in "YOLO Mode," compile all drafted edits for presentation in the next step.
+    -   如果在“YOLO模式”下，编译所有起草的编辑，以便在下一步中呈现。
 
-### 4. Generate "Sprint Change Proposal" with Edits
+### 4. 生成包含编辑的“冲刺变更提案”
 
-- Synthesize the complete change-checklist analysis (covering findings from Sections 1-4) and all the agreed-upon proposed edits (from Instruction 3) into a single document titled "Sprint Change Proposal." This proposal should align with the structure suggested by Section 5 of the change-checklist.
+-   将完整的变更清单分析（涵盖第1-4节的发现）和所有商定的拟议编辑（来自说明3）综合成一份名为“冲刺变更提案”的单一文档。此提案应与变更清单第5节建议的结构保持一致。
-- The proposal must clearly present:
+-   提案必须清晰地呈现：
-  - **Analysis Summary:** A concise overview of the original issue, its analyzed impact (on epics, artifacts, MVP scope), and the rationale for the chosen path forward.
+    -   **分析摘要：** 对原始问题、其分析的影响（对史诗、工件、MVP范围）以及所选前进路径的理由的简明概述。
-  - **Specific Proposed Edits:** For each affected artifact, clearly show or describe the exact changes (e.g., "Change Story X.Y from: [old text] To: [new text]", "Add new Acceptance Criterion to Story A.B: [new AC]", "Update Section 3.2 of Architecture Document as follows: [new/modified text or diagram description]").
+    -   **具体的拟议编辑：** 对于每个受影响的工件，清晰地显示或描述确切的变更（例如，“将故事X.Y从：[旧文本] 更改为：[新文本]”，“向故事A.B添加新的验收标准：[新AC]”，“按如下方式更新架构文档的第3.2节：[新的/修改的文本或图表描述]”）。
-- Present the complete draft of the "Sprint Change Proposal" to the user for final review and feedback. Incorporate any final adjustments requested by the user.
+-   将“冲刺变更提案”的完整草稿呈现给用户进行最终审查和反馈。采纳用户要求的任何最终调整。
 
-### 5. Finalize & Determine Next Steps
+### 5. 最终确定并确定下一步
 
-- Obtain explicit user approval for the "Sprint Change Proposal," including all the specific edits documented within it.
+-   获得用户对“冲刺变更提案”的明确批准，包括其中记录的所有具体编辑。
-- Provide the finalized "Sprint Change Proposal" document to the user.
+-   向用户提供最终确定的“冲刺变更提案”文档。
-- **Based on the nature of the approved changes:**
+-   **根据批准的变更的性质：**
-  - **If the approved edits sufficiently address the change and can be implemented directly or organized by a PO/SM:** State that the "Correct Course Task" is complete regarding analysis and change proposal, and the user can now proceed with implementing or logging these changes (e.g., updating actual project documents, backlog items). Suggest handoff to a PO/SM agent for backlog organization if appropriate.
+    -   **如果批准的编辑足以解决变更，并且可以直接实施或由PO/SM组织：** 说明“纠正航向任务”在分析和变更提案方面已完成，用户现在可以继续实施或记录这些变更（例如，更新实际的项目文档、待办事项）。如果合适，建议交接给PO/SM代理进行待办事项组织。
-  - **If the analysis and proposed path (as per checklist Section 4 and potentially Section 6) indicate that the change requires a more fundamental replan (e.g., significant scope change, major architectural rework):** Clearly state this conclusion. Advise the user that the next step involves engaging the primary PM or Architect agents, using the "Sprint Change Proposal" as critical input and context for that deeper replanning effort.
+    -   **如果分析和拟议路径（根据清单第4节和可能第6节）表明变更需要更根本的重新规划（例如，重大的范围变更、主要的架构重做）：** 清晰地陈述此结论。建议用户下一步是让主要的PM或架构师代理参与进来，使用“冲刺变更提案”作为该更深层次重新规划工作的关键输入和背景。
 
-## Output Deliverables
+## 输出交付物
 
-- **Primary:** A "Sprint Change Proposal" document (in markdown format). This document will contain:
+-   **主要：** 一份“冲刺变更提案”文档（markdown格式）。该文档将包含：
-  - A summary of the change-checklist analysis (issue, impact, rationale for the chosen path).
+    -   变更清单分析的摘要（问题、影响、所选路径的理由）。
-  - Specific, clearly drafted proposed edits for all affected project artifacts.
+    -   为所有受影响的项目工件起草的具体的、清晰的拟议编辑。
-- **Implicit:** An annotated change-checklist (or the record of its completion) reflecting the discussions, findings, and decisions made during the process.
+-   **隐含：** 一份带注释的变更清单（或其完成记录），反映了在此过程中进行的讨论、发现和决定。

bmad-core/tasks/create-deep-research-prompt.md

@@ -1,280 +1,280 @@
-<!-- Powered by BMAD™ Core -->
+<!-- 由 BMAD™ Core 驱动 -->
 
-# Create Deep Research Prompt Task
+# 创建深度研究提示任务
 
-This task helps create comprehensive research prompts for various types of deep analysis. It can process inputs from brainstorming sessions, project briefs, market research, or specific research questions to generate targeted prompts for deeper investigation.
+此任务有助于为各种类型的深度分析创建全面的研究提示。它可以处理来自头脑风暴会议、项目简报、市场研究或特定研究问题的输入，以生成用于更深入调查的目标提示。
 
-## Purpose
+## 目的
 
-Generate well-structured research prompts that:
+生成结构良好的研究提示，以便：
 
-- Define clear research objectives and scope
+-   定义明确的研究目标和范围
-- Specify appropriate research methodologies
+-   指定适当的研究方法
-- Outline expected deliverables and formats
+-   概述预期的可交付成果和格式
-- Guide systematic investigation of complex topics
+-   指导对复杂主题的系统性调查
-- Ensure actionable insights are captured
+-   确保捕获可操作的见解
 
-## Research Type Selection
+## 研究类型选择
 
-CRITICAL: First, help the user select the most appropriate research focus based on their needs and any input documents they've provided.
+关键：首先，根据用户的需求和他们提供的任何输入文件，帮助用户选择最合适的研究重点。
 
-### 1. Research Focus Options
+### 1. 研究重点选项
 
-Present these numbered options to the user:
+向用户呈现这些编号的选项：
 
-1. **Product Validation Research**
+1.  **产品验证研究**
-   - Validate product hypotheses and market fit
+    -   验证产品假设和市场契合度
-   - Test assumptions about user needs and solutions
+    -   测试关于用户需求和解决方案的假设
-   - Assess technical and business feasibility
+    -   评估技术和业务可行性
-   - Identify risks and mitigation strategies
+    -   识别风险和缓解策略
 
-2. **Market Opportunity Research**
+2.  **市场机会研究**
-   - Analyze market size and growth potential
+    -   分析市场规模和增长潜力
-   - Identify market segments and dynamics
+    -   识别市场细分和动态
-   - Assess market entry strategies
+    -   评估市场进入策略
-   - Evaluate timing and market readiness
+    -   评估时机和市场准备情况
 
-3. **User & Customer Research**
+3.  **用户与客户研究**
-   - Deep dive into user personas and behaviors
+    -   深入研究用户画像和行为
-   - Understand jobs-to-be-done and pain points
+    -   理解待办任务和痛点
-   - Map customer journeys and touchpoints
+    -   绘制客户旅程和接触点
-   - Analyze willingness to pay and value perception
+    -   分析支付意愿和价值感知
 
-4. **Competitive Intelligence Research**
+4.  **竞争情报研究**
-   - Detailed competitor analysis and positioning
+    -   详细的竞争对手分析和定位
-   - Feature and capability comparisons
+    -   功能和能力比较
-   - Business model and strategy analysis
+    -   商业模式和战略分析
-   - Identify competitive advantages and gaps
+    -   识别竞争优势和差距
 
-5. **Technology & Innovation Research**
+5.  **技术与创新研究**
-   - Assess technology trends and possibilities
+    -   评估技术趋势和可能性
-   - Evaluate technical approaches and architectures
+    -   评估技术方法和架构
-   - Identify emerging technologies and disruptions
+    -   识别新兴技术和颠覆性技术
-   - Analyze build vs. buy vs. partner options
+    -   分析自建、购买与合作的选项
 
-6. **Industry & Ecosystem Research**
+6.  **行业与生态系统研究**
-   - Map industry value chains and dynamics
+    -   绘制行业价值链和动态
-   - Identify key players and relationships
+    -   识别关键参与者和关系
-   - Analyze regulatory and compliance factors
+    -   分析法规和合规因素
-   - Understand partnership opportunities
+    -   理解合作机会
 
-7. **Strategic Options Research**
+7.  **战略选项研究**
-   - Evaluate different strategic directions
+    -   评估不同的战略方向
-   - Assess business model alternatives
+    -   评估商业模式替代方案
-   - Analyze go-to-market strategies
+    -   分析市场进入策略
-   - Consider expansion and scaling paths
+    -   考虑扩张和扩展路径
 
-8. **Risk & Feasibility Research**
+8.  **风险与可行性研究**
-   - Identify and assess various risk factors
+    -   识别和评估各种风险因素
-   - Evaluate implementation challenges
+    -   评估实施挑战
-   - Analyze resource requirements
+    -   分析资源需求
-   - Consider regulatory and legal implications
+    -   考虑法规和法律影响
 
-9. **Custom Research Focus**
+9.  **自定义研究重点**
-   - User-defined research objectives
+    -   用户定义的研究目标
-   - Specialized domain investigation
+    -   专业领域调查
-   - Cross-functional research needs
+    -   跨职能研究需求
 
-### 2. Input Processing
+### 2. 输入处理
 
-**If Project Brief provided:**
+**如果提供了项目简报：**
 
-- Extract key product concepts and goals
+-   提取关键产品概念和目标
-- Identify target users and use cases
+-   识别目标用户和用例
-- Note technical constraints and preferences
+-   注意技术约束和偏好
-- Highlight uncertainties and assumptions
+-   突出不确定性和假设
 
-**If Brainstorming Results provided:**
+**如果提供了头脑风暴结果：**
 
-- Synthesize main ideas and themes
+-   综合主要思想和主题
-- Identify areas needing validation
+-   识别需要验证的领域
-- Extract hypotheses to test
+-   提取要测试的假设
-- Note creative directions to explore
+-   注意要探索的创意方向
 
-**If Market Research provided:**
+**如果提供了市场研究：**
 
-- Build on identified opportunities
+-   在已识别的机会上进行构建
-- Deepen specific market insights
+-   深化特定的市场见解
-- Validate initial findings
+-   验证初步发现
-- Explore adjacent possibilities
+-   探索相邻的可能性
 
-**If Starting Fresh:**
+**如果从头开始：**
 
-- Gather essential context through questions
+-   通过问题收集基本背景
-- Define the problem space
+-   定义问题空间
-- Clarify research objectives
+-   澄清研究目标
-- Establish success criteria
+-   建立成功标准
 
-## Process
+## 流程
 
-### 3. Research Prompt Structure
+### 3. 研究提示结构
 
-CRITICAL: collaboratively develop a comprehensive research prompt with these components.
+关键：与用户协作制定一个包含这些组成部分的全面研究提示。
 
-#### A. Research Objectives
+#### A. 研究目标
 
-CRITICAL: collaborate with the user to articulate clear, specific objectives for the research.
+关键：与用户协作，阐明清晰、具体的研究目标。
 
-- Primary research goal and purpose
+-   主要研究目标和目的
-- Key decisions the research will inform
+-   研究将为哪些关键决策提供信息
-- Success criteria for the research
+-   研究的成功标准
-- Constraints and boundaries
+-   约束和边界
 
-#### B. Research Questions
+#### B. 研究问题
 
-CRITICAL: collaborate with the user to develop specific, actionable research questions organized by theme.
+关键：与用户协作，按主题组织制定具体的、可操作的研究问题。
 
-**Core Questions:**
+**核心问题：**
 
-- Central questions that must be answered
+-   必须回答的核心问题
-- Priority ranking of questions
+-   问题的优先级排序
-- Dependencies between questions
+-   问题之间的依赖关系
 
-**Supporting Questions:**
+**支持性问题：**
 
-- Additional context-building questions
+-   额外的背景构建问题
-- Nice-to-have insights
+-   可有可无的见解
-- Future-looking considerations
+-   面向未来的考虑
 
-#### C. Research Methodology
+#### C. 研究方法
 
-**Data Collection Methods:**
+**数据收集方法：**
 
-- Secondary research sources
+-   二手研究来源
-- Primary research approaches (if applicable)
+-   一手研究方法（如果适用）
-- Data quality requirements
+-   数据质量要求
-- Source credibility criteria
+-   来源可信度标准
 
-**Analysis Frameworks:**
+**分析框架：**
 
-- Specific frameworks to apply
+-   要应用的具体框架
-- Comparison criteria
+-   比较标准
-- Evaluation methodologies
+-   评估方法
-- Synthesis approaches
+-   综合方法
 
-#### D. Output Requirements
+#### D. 输出要求
 
-**Format Specifications:**
+**格式规范：**
 
-- Executive summary requirements
+-   执行摘要要求
-- Detailed findings structure
+-   详细发现的结构
-- Visual/tabular presentations
+-   视觉/表格演示
-- Supporting documentation
+-   支持文档
 
-**Key Deliverables:**
+**关键可交付成果：**
 
-- Must-have sections and insights
+-   必须有的部分和见解
-- Decision-support elements
+-   决策支持元素
-- Action-oriented recommendations
+-   面向行动的建议
-- Risk and uncertainty documentation
+--   风险和不确定性文档
 
-### 4. Prompt Generation
+### 4. 提示生成
 
-**Research Prompt Template:**
+**研究提示模板：**
 
 ```markdown
-## Research Objective
+## 研究目标
 
-[Clear statement of what this research aims to achieve]
+[清晰陈述本研究旨在实现的目标]
 
-## Background Context
+## 背景情况
 
-[Relevant information from project brief, brainstorming, or other inputs]
+[来自项目简报、头脑风暴或其他输入的相关信息]
 
-## Research Questions
+## 研究问题
 
-### Primary Questions (Must Answer)
+### 主要问题（必须回答）
 
-1. [Specific, actionable question]
+1. [具体的、可操作的问题]
-2. [Specific, actionable question]
+2. [具体的、可操作的问题]
    ...
 
-### Secondary Questions (Nice to Have)
+### 次要问题（最好有）
 
-1. [Supporting question]
+1. [支持性问题]
-2. [Supporting question]
+2. [支持性问题]
    ...
 
-## Research Methodology
+## 研究方法
 
-### Information Sources
+### 信息来源
 
-- [Specific source types and priorities]
+- [具体来源类型和优先级]
 
-### Analysis Frameworks
+### 分析框架
 
-- [Specific frameworks to apply]
+- [要应用的具体框架]
 
-### Data Requirements
+### 数据要求
 
-- [Quality, recency, credibility needs]
+- [质量、时效性、可信度需求]
 
-## Expected Deliverables
+## 预期可交付成果
 
-### Executive Summary
+### 执行摘要
 
-- Key findings and insights
+- 关键发现和见解
-- Critical implications
+- 关键影响
-- Recommended actions
+- 建议的行动
 
-### Detailed Analysis
+### 详细分析
 
-[Specific sections needed based on research type]
+[根据研究类型需要的具体部分]
 
-### Supporting Materials
+### 支持材料
 
-- Data tables
+- 数据表
-- Comparison matrices
+- 比较矩阵
-- Source documentation
+- 源文档
 
-## Success Criteria
+## 成功标准
 
-[How to evaluate if research achieved its objectives]
+[如何评估研究是否达到其目标]
 
-## Timeline and Priority
+## 时间表和优先级
 
-[If applicable, any time constraints or phasing]
+[如果适用，任何时间限制或分期]
 ```
 
-### 5. Review and Refinement
+### 5. 审查和完善
 
-1. **Present Complete Prompt**
+1.  **呈现完整的提示**
-   - Show the full research prompt
+    -   显示完整的​​研究提示
-   - Explain key elements and rationale
+    -   解释关键要素和理由
-   - Highlight any assumptions made
+    -   突出任何假设
 
-2. **Gather Feedback**
+2.  **收集反馈**
-   - Are the objectives clear and correct?
+    -   目标是否清晰正确？
-   - Do the questions address all concerns?
+    -   问题是否解决了所有疑虑？
-   - Is the scope appropriate?
+    -   范围是否合适？
-   - Are output requirements sufficient?
+    -   输出要求是否足够？
 
-3. **Refine as Needed**
+3.  **根据需要进行完善**
-   - Incorporate user feedback
+    -   采纳用户反馈
-   - Adjust scope or focus
+    -   调整范围或重点
-   - Add missing elements
+    -   添加缺失的元素
-   - Clarify ambiguities
+    -   澄清模糊之处
 
-### 6. Next Steps Guidance
+### 6. 后续步骤指导
 
-**Execution Options:**
+**执行选项：**
 
-1. **Use with AI Research Assistant**: Provide this prompt to an AI model with research capabilities
+1.  **与AI研究助理一起使用**：将此提示提供给具有研究能力的AI模型
-2. **Guide Human Research**: Use as a framework for manual research efforts
+2.  **指导人工研究**：作为人工研究工作的框架
-3. **Hybrid Approach**: Combine AI and human research using this structure
+3.  **混合方法**：使用此结构结合AI和人工研究
 
-**Integration Points:**
+**集成点：**
 
-- How findings will feed into next phases
+-   研究结果将如何融入下一阶段
-- Which team members should review results
+-   哪些团队成员应该审查结果
-- How to validate findings
+-   如何验证研究结果
-- When to revisit or expand research
+-   何时重新审视或扩展研究
 
-## Important Notes
+## 重要说明
 
-- The quality of the research prompt directly impacts the quality of insights gathered
+-   研究提示的质量直接影响所收集见解的质量
-- Be specific rather than general in research questions
+-   研究问题要具体而非笼统
-- Consider both current state and future implications
+-   同时考虑当前状态和未来影响
-- Balance comprehensiveness with focus
+-   在全面性和专注性之间取得平衡
-- Document assumptions and limitations clearly
+-   清晰地记录假设和限制
-- Plan for iterative refinement based on initial findings
+-   根据初步发现计划迭代完善

bmad-core/tasks/create-next-story.md

@@ -1,114 +1,114 @@
-<!-- Powered by BMAD™ Core -->
+<!-- 由 BMAD™ Core 驱动 -->
 
-# Create Next Story Task
+# 创建下一个故事任务
 
-## Purpose
+## 目的
 
-To identify the next logical story based on project progress and epic definitions, and then to prepare a comprehensive, self-contained, and actionable story file using the `Story Template`. This task ensures the story is enriched with all necessary technical context, requirements, and acceptance criteria, making it ready for efficient implementation by a Developer Agent with minimal need for additional research or finding its own context.
+根据项目进度和史诗定义，确定下一个合乎逻辑的故事，然后使用 `故事模板` 准备一个全面的、自包含的、可操作的故事文件。此任务确保故事富含所有必要的技术背景、需求和验收标准，使其准备好由开发代理高效实施，而无需额外的研究或寻找自身背景。
 
-## SEQUENTIAL Task Execution (Do not proceed until current Task is complete)
+## 顺序任务执行（在当前任务完成前不要继续）
 
-### 0. Load Core Configuration and Check Workflow
+### 0. 加载核心配置并检查工作流
 
-- Load `{root}/core-config.yaml` from the project root
+-   从项目根目录加载 `{root}/core-config.yaml`
-- If the file does not exist, HALT and inform the user: "core-config.yaml not found. This file is required for story creation. You can either: 1) Copy it from GITHUB bmad-core/core-config.yaml and configure it for your project OR 2) Run the BMad installer against your project to upgrade and add the file automatically. Please add and configure core-config.yaml before proceeding."
+-   如果文件不存在，则停止并通知用户：“未找到 core-config.yaml。此文件是创建故事所必需的。您可以：1) 从 GITHUB bmad-core/core-config.yaml 复制并为您的项目配置它 或 2) 对您的项目运行 BMad 安装程序以自动升级并添加该文件。请在继续之前添加并配置 core-config.yaml。”
-- Extract key configurations: `devStoryLocation`, `prd.*`, `architecture.*`, `workflow.*`
+-   提取关键配置：`devStoryLocation`、`prd.*`、`architecture.*`、`workflow.*`
 
-### 1. Identify Next Story for Preparation
+### 1. 确定要准备的下一个故事
 
-#### 1.1 Locate Epic Files and Review Existing Stories
+#### 1.1 定位史诗文件并审查现有故事
 
-- Based on `prdSharded` from config, locate epic files (sharded location/pattern or monolithic PRD sections)
+-   根据配置中的 `prdSharded`，定位史诗文件（分片位置/模式或单片PRD部分）
-- If `devStoryLocation` has story files, load the highest `{epicNum}.{storyNum}.story.md` file
+-   如果 `devStoryLocation` 有故事文件，则加载最高的 `{epicNum}.{storyNum}.story.md` 文件
-- **If highest story exists:**
+-   **如果存在最高的故事：**
-  - Verify status is 'Done'. If not, alert user: "ALERT: Found incomplete story! File: {lastEpicNum}.{lastStoryNum}.story.md Status: [current status] You should fix this story first, but would you like to accept risk & override to create the next story in draft?"
+    -   验证状态是否为“完成”。如果不是，则提醒用户：“警报：发现未完成的故事！文件：{lastEpicNum}.{lastStoryNum}.story.md 状态：[当前状态] 您应首先修复此故事，但您想接受风险并覆盖以草稿形式创建下一个故事吗？”
-  - If proceeding, select next sequential story in the current epic
+    -   如果继续，则选择当前史诗中的下一个顺序故事
-  - If epic is complete, prompt user: "Epic {epicNum} Complete: All stories in Epic {epicNum} have been completed. Would you like to: 1) Begin Epic {epicNum + 1} with story 1 2) Select a specific story to work on 3) Cancel story creation"
+    -   如果史诗已完成，则提示用户：“史诗 {epicNum} 已完成：史诗 {epicNum} 中的所有故事均已完成。您想：1) 从故事1开始史诗 {epicNum + 1} 2) 选择要处理的特定故事 3) 取消故事创建”
-  - **CRITICAL**: NEVER automatically skip to another epic. User MUST explicitly instruct which story to create.
+    -   **关键**：切勿自动跳到另一个史诗。用户必须明确指示要创建哪个故事。
-- **If no story files exist:** The next story is ALWAYS 1.1 (first story of first epic)
+-   **如果没有故事文件：** 下一个故事始终是 1.1（第一个史诗的第一个故事）
-- Announce the identified story to the user: "Identified next story for preparation: {epicNum}.{storyNum} - {Story Title}"
+-   向用户宣布已识别的故事：“已确定要准备的下一个故事：{epicNum}.{storyNum} - {故事标题}”
 
-### 2. Gather Story Requirements and Previous Story Context
+### 2. 收集故事需求和上一个故事的背景
 
-- Extract story requirements from the identified epic file
+-   从已识别的史诗文件中提取故事需求
-- If previous story exists, review Dev Agent Record sections for:
+-   如果存在上一个故事，则审查开发代理记录部分以获取：
-  - Completion Notes and Debug Log References
+    -   完成说明和调试日志参考
-  - Implementation deviations and technical decisions
+    -   实施偏差和技术决策
-  - Challenges encountered and lessons learned
+    -   遇到的挑战和经验教训
-- Extract relevant insights that inform the current story's preparation
+-   提取为当前故事准备提供信息的相​​关见解
 
-### 3. Gather Architecture Context
+### 3. 收集架构背景
 
-#### 3.1 Determine Architecture Reading Strategy
+#### 3.1 确定架构阅读策略
 
-- **If `architectureVersion: >= v4` and `architectureSharded: true`**: Read `{architectureShardedLocation}/index.md` then follow structured reading order below
+-   **如果 `architectureVersion: >= v4` 且 `architectureSharded: true`**：阅读 `{architectureShardedLocation}/index.md`，然后按照下面的结构化阅读顺序进行
-- **Else**: Use monolithic `architectureFile` for similar sections
+-   **否则**：对类似部分使用单片 `architectureFile`
 
-#### 3.2 Read Architecture Documents Based on Story Type
+#### 3.2 根据故事类型阅读架构文档
 
-**For ALL Stories:** tech-stack.md, unified-project-structure.md, coding-standards.md, testing-strategy.md
+**对于所有故事：** tech-stack.md、unified-project-structure.md、coding-standards.md、testing-strategy.md
 
-**For Backend/API Stories, additionally:** data-models.md, database-schema.md, backend-architecture.md, rest-api-spec.md, external-apis.md
+**对于后端/API故事，另外：** data-models.md、database-schema.md、backend-architecture.md、rest-api-spec.md、external-apis.md
 
-**For Frontend/UI Stories, additionally:** frontend-architecture.md, components.md, core-workflows.md, data-models.md
+**对于前端/UI故事，另外：** frontend-architecture.md、components.md、core-workflows.md、data-models.md
 
-**For Full-Stack Stories:** Read both Backend and Frontend sections above
+**对于全栈故事：** 阅读上面的后端和前端部分
 
-#### 3.3 Extract Story-Specific Technical Details
+#### 3.3 提取特定于故事的技术细节
 
-Extract ONLY information directly relevant to implementing the current story. Do NOT invent new libraries, patterns, or standards not in the source documents.
+仅提取与实施当前故事直接相关的信息。不要发明源文档中没有的新库、模式或标准。
 
-Extract:
+提取：
 
-- Specific data models, schemas, or structures the story will use
+-   故事将使用的特定数据模型、模式或结构
-- API endpoints the story must implement or consume
+-   故事必须实施或使用的API端点
-- Component specifications for UI elements in the story
+-   故事中UI元素的组件规范
-- File paths and naming conventions for new code
+-   新代码的文件路径和命名约定
-- Testing requirements specific to the story's features
+-   特定于故事功能的测试要求
-- Security or performance considerations affecting the story
+-   影响故事的安全或性能考虑
 
-ALWAYS cite source documents: `[Source: architecture/{filename}.md#{section}]`
+始终引用源文档：`[来源：architecture/{filename}.md#{section}]`
 
-### 4. Verify Project Structure Alignment
+### 4. 验证项目结构对齐
 
-- Cross-reference story requirements with Project Structure Guide from `docs/architecture/unified-project-structure.md`
+-   将故事需求与 `docs/architecture/unified-project-structure.md` 中的项目结构指南进行交叉引用
-- Ensure file paths, component locations, or module names align with defined structures
+-   确保文件路径、组件位置或模块名称与定义的结构保持一致
-- Document any structural conflicts in "Project Structure Notes" section within the story draft
+-   在故事草稿的“项目结构说明”部分记录任何结构冲突
 
-### 5. Populate Story Template with Full Context
+### 5. 用完整上下文填充故事模板
 
-- Create new story file: `{devStoryLocation}/{epicNum}.{storyNum}.story.md` using Story Template
+-   创建新故事文件：使用故事模板在 `{devStoryLocation}/{epicNum}.{storyNum}.story.md` 创建
-- Fill in basic story information: Title, Status (Draft), Story statement, Acceptance Criteria from Epic
+-   填写基本故事信息：标题、状态（草稿）、故事陈述、来自史诗的验收标准
-- **`Dev Notes` section (CRITICAL):**
+-   **`开发说明`部分（关键）：**
-  - CRITICAL: This section MUST contain ONLY information extracted from architecture documents. NEVER invent or assume technical details.
+    -   关键：此部分必须仅包含从架构文档中提取的信息。切勿发明或假设技术细节。
-  - Include ALL relevant technical details from Steps 2-3, organized by category:
+    -   包括步骤2-3中的所有相关技术细节，按类别组织：
-    - **Previous Story Insights**: Key learnings from previous story
+        -   **上一个故事的见解**：上一个故事的关键经验教训
-    - **Data Models**: Specific schemas, validation rules, relationships [with source references]
+        -   **数据模型**：特定的模式、验证规则、关系[附带来源参考]
-    - **API Specifications**: Endpoint details, request/response formats, auth requirements [with source references]
+        -   **API规范**：端点细节、请求/响应格式、身份验证要求[附带来源参考]
-    - **Component Specifications**: UI component details, props, state management [with source references]
+        -   **组件规范**：UI组件细节、属性、状态管理[附带来源参考]
-    - **File Locations**: Exact paths where new code should be created based on project structure
+        -   **文件位置**：根据项目结构应创建新代码的确切路径
-    - **Testing Requirements**: Specific test cases or strategies from testing-strategy.md
+        -   **测试要求**：来自testing-strategy.md的特定测试用例或策略
-    - **Technical Constraints**: Version requirements, performance considerations, security rules
+        -   **技术约束**：版本要求、性能考虑、安全规则
-  - Every technical detail MUST include its source reference: `[Source: architecture/{filename}.md#{section}]`
+    -   每个技术细节都必须包含其来源参考：`[来源：architecture/{filename}.md#{section}]`
-  - If information for a category is not found in the architecture docs, explicitly state: "No specific guidance found in architecture docs"
+    -   如果在架构文档中未找到某个类别的信息，则明确说明：“在架构文档中未找到具体指导”
-- **`Tasks / Subtasks` section:**
+-   **`任务/子任务`部分：**
-  - Generate detailed, sequential list of technical tasks based ONLY on: Epic Requirements, Story AC, Reviewed Architecture Information
+    -   仅根据：史诗需求、故事AC、审查过的架构信息，生成详细的、顺序的技术任务列表
-  - Each task must reference relevant architecture documentation
+    -   每个任务都必须引用相关的架构文档
-  - Include unit testing as explicit subtasks based on the Testing Strategy
+    -   根据测试策略，将单元测试作为明确的子任务包括在内
-  - Link tasks to ACs where applicable (e.g., `Task 1 (AC: 1, 3)`)
+    -   在适用的情况下将任务链接到AC（例如，`任务1 (AC: 1, 3)`）
-- Add notes on project structure alignment or discrepancies found in Step 4
+-   在步骤4中添加有关项目结构对齐或发现的差异的说明
 
-### 6. Story Draft Completion and Review
+### 6. 故事草稿完成和审查
 
-- Review all sections for completeness and accuracy
+-   审查所有部分的完整性和准确性
-- Verify all source references are included for technical details
+-   验证技术细节的所有来源参考都已包括在内
-- Ensure tasks align with both epic requirements and architecture constraints
+-   确保任务与史诗需求和架构约束保持一致
-- Update status to "Draft" and save the story file
+-   将状态更新为“草稿”并保存故事文件
-- Execute `{root}/tasks/execute-checklist` `{root}/checklists/story-draft-checklist`
+-   执行 `{root}/tasks/execute-checklist` `{root}/checklists/story-draft-checklist`
-- Provide summary to user including:
+-   向用户提供摘要，包括：
-  - Story created: `{devStoryLocation}/{epicNum}.{storyNum}.story.md`
+    -   创建的故事：`{devStoryLocation}/{epicNum}.{storyNum}.story.md`
-  - Status: Draft
+    -   状态：草稿
-  - Key technical components included from architecture docs
+    -   从架构文档中包含的关键技术组件
-  - Any deviations or conflicts noted between epic and architecture
+    -   注意到的史诗和架构之间的任何偏差或冲突
-  - Checklist Results
+    -   清单结果
-  - Next steps: For Complex stories, suggest the user carefully review the story draft and also optionally have the PO run the task `{root}/tasks/validate-next-story`
+    -   下一步：对于复杂的故事，建议用户仔细审查故事草稿，并可选择让PO运行任务 `{root}/tasks/validate-next-story`

bmad-core/tasks/document-project.md

@@ -1,345 +1,345 @@
-<!-- Powered by BMAD™ Core -->
+<!-- 由 BMAD™ Core 驱动 -->
 
-# Document an Existing Project
+# 记录现有项目
 
-## Purpose
+## 目的
 
-Generate comprehensive documentation for existing projects optimized for AI development agents. This task creates structured reference materials that enable AI agents to understand project context, conventions, and patterns for effective contribution to any codebase.
+为现有项目生成为AI开发代理优化的综合文档。此任务创建结构化的参考资料，使AI代理能够理解项目背景、惯例和模式，从而有效地为任何代码库做出贡献。
 
-## Task Instructions
+## 任务说明
 
-### 1. Initial Project Analysis
+### 1. 初步项目分析
 
-**CRITICAL:** First, check if a PRD or requirements document exists in context. If yes, use it to focus your documentation efforts on relevant areas only.
+**关键：** 首先，检查上下文中是否存在PRD或需求文档。如果存在，则用它来将您的文档工作重点放在相关领域。
 
-**IF PRD EXISTS**:
+**如果存在PRD：**
 
-- Review the PRD to understand what enhancement/feature is planned
+-   审查PRD以了解计划中的增强/功能
-- Identify which modules, services, or areas will be affected
+-   确定将受影响的模块、服务或区域
-- Focus documentation ONLY on these relevant areas
+-   仅将文档重点放在这些相关区域
-- Skip unrelated parts of the codebase to keep docs lean
+-   跳过代码库中不相关的部分，以保持文档精简
 
-**IF NO PRD EXISTS**:
+**如果不存在PRD：**
-Ask the user:
+询问用户：
 
-"I notice you haven't provided a PRD or requirements document. To create more focused and useful documentation, I recommend one of these options:
+“我注意到您没有提供PRD或需求文档。为了创建更专注、更有用的文档，我推荐以下选项之一：
 
-1. **Create a PRD first** - Would you like me to help create a brownfield PRD before documenting? This helps focus documentation on relevant areas.
+1.  **首先创建PRD** - 您希望我在记录之前帮助创建棕地PRD吗？这有助于将文档重点放在相关领域。
 
-2. **Provide existing requirements** - Do you have a requirements document, epic, or feature description you can share?
+2.  **提供现有需求** - 您是否有可以共享的需求文档、史诗或功能描述？
 
-3. **Describe the focus** - Can you briefly describe what enhancement or feature you're planning? For example:
+3.  **描述重点** - 您能简要描述您计划的增强或功能吗？例如：
-   - 'Adding payment processing to the user service'
+    -   ‘向用户服务添加支付处理’
-   - 'Refactoring the authentication module'
+    -   ‘重构身份验证模块’
-   - 'Integrating with a new third-party API'
+    -   ‘与新的第三方API集成’
 
-4. **Document everything** - Or should I proceed with comprehensive documentation of the entire codebase? (Note: This may create excessive documentation for large projects)
+4.  **记录所有内容** - 或者我应该继续对整个代码库进行综合文档记录？（注意：对于大型项目，这可能会产生过多的文档）
 
-Please let me know your preference, or I can proceed with full documentation if you prefer."
+请告诉我您的偏好，或者如果您愿意，我可以继续进行完整的文档记录。”
 
-Based on their response:
+根据他们的回应：
 
-- If they choose option 1-3: Use that context to focus documentation
+-   如果他们选择选项1-3：使用该背景来专注文档记录
-- If they choose option 4 or decline: Proceed with comprehensive analysis below
+-   如果他们选择选项4或拒绝：继续下面的综合分析
 
-Begin by conducting analysis of the existing project. Use available tools to:
+首先对现有项目进行分析。使用可用工具：
 
-1. **Project Structure Discovery**: Examine the root directory structure, identify main folders, and understand the overall organization
+1.  **项目结构发现**：检查根目录结构，识别主文件夹，并了解整体组织
-2. **Technology Stack Identification**: Look for package.json, requirements.txt, Cargo.toml, pom.xml, etc. to identify languages, frameworks, and dependencies
+2.  **技术栈识别**：查找package.json、requirements.txt、Cargo.toml、pom.xml等，以识别语言、框架和依赖项
-3. **Build System Analysis**: Find build scripts, CI/CD configurations, and development commands
+3.  **构建系统分析**：查找构建脚本、CI/CD配置和开发命令
-4. **Existing Documentation Review**: Check for README files, docs folders, and any existing documentation
+4.  **现有文档审查**：检查README文件、docs文件夹和任何现有文档
-5. **Code Pattern Analysis**: Sample key files to understand coding patterns, naming conventions, and architectural approaches
+5.  **代码模式分析**：抽样关键文件以了解编码模式、命名约定和架构方法
 
-Ask the user these elicitation questions to better understand their needs:
+向用户提出这些启发性问题，以更好地了解他们的需求：
 
-- What is the primary purpose of this project?
+-   该项目的主要目的是什么？
-- Are there any specific areas of the codebase that are particularly complex or important for agents to understand?
+-   代码库中是否有任何特定领域对于代理理解特别复杂或重要？
-- What types of tasks do you expect AI agents to perform on this project? (e.g., bug fixes, feature additions, refactoring, testing)
+-   您希望AI代理在该项目上执行哪些类型的任务？（例如，错误修复、功能添加、重构、测试）
-- Are there any existing documentation standards or formats you prefer?
+-   您是否有任何偏好的现有文档标准或格式？
-- What level of technical detail should the documentation target? (junior developers, senior developers, mixed team)
+-   文档应针对哪个技术细节级别？（初级开发人员、高级开发人员、混合团队）
-- Is there a specific feature or enhancement you're planning? (This helps focus documentation)
+-   您是否正在计划特定的功能或增强？（这有助于专注文档记录）
 
-### 2. Deep Codebase Analysis
+### 2. 深入代码库分析
 
-CRITICAL: Before generating documentation, conduct extensive analysis of the existing codebase:
+关键：在生成文档之前，对现有代码库进行广泛分析：
 
-1. **Explore Key Areas**:
+1.  **探索关键领域**：
-   - Entry points (main files, index files, app initializers)
+    -   入口点（主文件、索引文件、应用程序初始化程序）
-   - Configuration files and environment setup
+    -   配置文件和环境设置
-   - Package dependencies and versions
+    -   包依赖项和版本
-   - Build and deployment configurations
+    -   构建和部署配置
-   - Test suites and coverage
+    -   测试套件和覆盖率
 
-2. **Ask Clarifying Questions**:
+2.  **提出澄清问题**：
-   - "I see you're using [technology X]. Are there any custom patterns or conventions I should document?"
+    -   “我看到您正在使用[技术X]。我应该记录任何自定义模式或惯例吗？”
-   - "What are the most critical/complex parts of this system that developers struggle with?"
+    -   “开发人员在此系统中最关键/复杂的部分是什么？”
-   - "Are there any undocumented 'tribal knowledge' areas I should capture?"
+    -   “我应该捕获任何未记录的‘部落知识’领域吗？”
-   - "What technical debt or known issues should I document?"
+    -   “我应该记录哪些技术债务或已知问题？”
-   - "Which parts of the codebase change most frequently?"
+    -   “代码库的哪些部分更改最频繁？”
 
-3. **Map the Reality**:
+3.  **映射现实**：
-   - Identify ACTUAL patterns used (not theoretical best practices)
+    -   识别实际使用的模式（而不是理论上的最佳实践）
-   - Find where key business logic lives
+    -   找到关键业务逻辑的位置
-   - Locate integration points and external dependencies
+    -   定位集成点和外部依赖项
-   - Document workarounds and technical debt
+    -   记录变通方法和技术债务
-   - Note areas that differ from standard patterns
+    -   注意与标准模式不同的区域
 
-**IF PRD PROVIDED**: Also analyze what would need to change for the enhancement
+**如果提供了PRD**：还要分析增强功能需要更改什么
 
-### 3. Core Documentation Generation
+### 3. 核心文档生成
 
-[[LLM: Generate a comprehensive BROWNFIELD architecture document that reflects the ACTUAL state of the codebase.
+[[LLM: 生成一份反映代码库实际状态的综合性棕地架构文档。
 
-**CRITICAL**: This is NOT an aspirational architecture document. Document what EXISTS, including:
+**关键**：这不是一份理想化的架构文档。记录存在的内容，包括：
 
-- Technical debt and workarounds
+-   技术债务和变通方法
-- Inconsistent patterns between different parts
+-   不同部分之间不一致的模式
-- Legacy code that can't be changed
+-   无法更改的旧代码
-- Integration constraints
+-   集成约束
-- Performance bottlenecks
+-   性能瓶颈
 
-**Document Structure**:
+**文档结构**：
 
-# [Project Name] Brownfield Architecture Document
+# [项目名称] 棕地架构文档
 
-## Introduction
+## 引言
 
-This document captures the CURRENT STATE of the [Project Name] codebase, including technical debt, workarounds, and real-world patterns. It serves as a reference for AI agents working on enhancements.
+本文档记录了[项目名称]代码库的当前状态，包括技术债务、变通方法和实际模式。它作为AI代理进行增强工作的参考。
 
-### Document Scope
+### 文档范围
 
-[If PRD provided: "Focused on areas relevant to: {enhancement description}"]
+[如果提供了PRD：“专注于与以下内容相关的领域：{增强描述}”]
-[If no PRD: "Comprehensive documentation of entire system"]
+[如果没有PRD：“整个系统的综合文档”]
 
-### Change Log
+### 变更日志
 
-| Date   | Version | Description                 | Author    |
+| 日期 | 版本 | 描述 | 作者 |
-| ------ | ------- | --------------------------- | --------- |
+| --- | --- | --- | --- |
-| [Date] | 1.0     | Initial brownfield analysis | [Analyst] |
+| [日期] | 1.0 | 初始棕地分析 | [分析师] |
 
-## Quick Reference - Key Files and Entry Points
+## 快速参考 - 关键文件和入口点
 
-### Critical Files for Understanding the System
+### 理解系统的关键文件
 
-- **Main Entry**: `src/index.js` (or actual entry point)
+-   **主入口**：`src/index.js`（或实际入口点）
-- **Configuration**: `config/app.config.js`, `.env.example`
+-   **配置**：`config/app.config.js`、`.env.example`
-- **Core Business Logic**: `src/services/`, `src/domain/`
+-   **核心业务逻辑**：`src/services/`、`src/domain/`
-- **API Definitions**: `src/routes/` or link to OpenAPI spec
+-   **API定义**：`src/routes/`或指向OpenAPI规范的链接
-- **Database Models**: `src/models/` or link to schema files
+-   **数据库模型**：`src/models/`或指向模式文件的链接
-- **Key Algorithms**: [List specific files with complex logic]
+-   **关键算法**：[列出具有复杂逻辑的特定文件]
 
-### If PRD Provided - Enhancement Impact Areas
+### 如果提供了PRD - 增强影响区域
 
-[Highlight which files/modules will be affected by the planned enhancement]
+[突出显示计划的增强将影响哪些文件/模块]
 
-## High Level Architecture
+## 高层架构
 
-### Technical Summary
+### 技术摘要
 
-### Actual Tech Stack (from package.json/requirements.txt)
+### 实际技术栈（来自package.json/requirements.txt）
 
-| Category  | Technology | Version | Notes                      |
+| 类别 | 技术 | 版本 | 说明 |
-| --------- | ---------- | ------- | -------------------------- |
+| --- | --- | --- | --- |
-| Runtime   | Node.js    | 16.x    | [Any constraints]          |
+| 运行时 | Node.js | 16.x | [任何约束] |
-| Framework | Express    | 4.18.2  | [Custom middleware?]       |
+| 框架 | Express | 4.18.2 | [自定义中间件？] |
-| Database  | PostgreSQL | 13      | [Connection pooling setup] |
+| 数据库 | PostgreSQL | 13 | [连接池设置] |
 
-etc...
+等等...
 
-### Repository Structure Reality Check
+### 存储库结构现实检查
 
-- Type: [Monorepo/Polyrepo/Hybrid]
+-   类型：[单体仓库/多仓库/混合]
-- Package Manager: [npm/yarn/pnpm]
+-   包管理器：[npm/yarn/pnpm]
-- Notable: [Any unusual structure decisions]
+-   值得注意的：[任何不寻常的结构决策]
 
-## Source Tree and Module Organization
+## 源代码树和模块组织
 
-### Project Structure (Actual)
+### 项目结构（实际）
 
 ```text
 project-root/
 ├── src/
-│   ├── controllers/     # HTTP request handlers
+│   ├── controllers/     # HTTP请求处理程序
-│   ├── services/        # Business logic (NOTE: inconsistent patterns between user and payment services)
+│   ├── services/        # 业务逻辑（注意：用户和支付服务之间的模式不一致）
-│   ├── models/          # Database models (Sequelize)
+│   ├── models/          # 数据库模型（Sequelize）
-│   ├── utils/           # Mixed bag - needs refactoring
+│   ├── utils/           # 混合包 - 需要重构
-│   └── legacy/          # DO NOT MODIFY - old payment system still in use
+│   └── legacy/          # 请勿修改 - 仍在使用的旧支付系统
-├── tests/               # Jest tests (60% coverage)
+├── tests/               # Jest测试（覆盖率60%）
-├── scripts/             # Build and deployment scripts
+├── scripts/             # 构建和部署脚本
-└── config/              # Environment configs
+└── config/              # 环境配置
 ```
 
-### Key Modules and Their Purpose
+### 关键模块及其用途
 
-- **User Management**: `src/services/userService.js` - Handles all user operations
+-   **用户管理**：`src/services/userService.js` - 处理所有用户操作
-- **Authentication**: `src/middleware/auth.js` - JWT-based, custom implementation
+-   **身份验证**：`src/middleware/auth.js` - 基于JWT的自定义实现
-- **Payment Processing**: `src/legacy/payment.js` - CRITICAL: Do not refactor, tightly coupled
+-   **支付处理**：`src/legacy/payment.js` - 关键：不要重构，紧密耦合
-- **[List other key modules with their actual files]**
+-   **[列出其他关键模块及其各自的文件]**
 
-## Data Models and APIs
+## 数据模型和API
 
-### Data Models
+### 数据模型
 
-Instead of duplicating, reference actual model files:
+不要重复，而是引用实际的模型文件：
 
-- **User Model**: See `src/models/User.js`
+-   **用户模型**：参见 `src/models/User.js`
-- **Order Model**: See `src/models/Order.js`
+-   **订单模型**：参见 `src/models/Order.js`
-- **Related Types**: TypeScript definitions in `src/types/`
+-   **相关类型**：`src/types/` 中的TypeScript定义
 
-### API Specifications
+### API规范
 
-- **OpenAPI Spec**: `docs/api/openapi.yaml` (if exists)
+-   **OpenAPI规范**：`docs/api/openapi.yaml`（如果存在）
-- **Postman Collection**: `docs/api/postman-collection.json`
+-   **Postman集合**：`docs/api/postman-collection.json`
-- **Manual Endpoints**: [List any undocumented endpoints discovered]
+-   **手动端点**：[列出发现的任何未记录的端点]
 
-## Technical Debt and Known Issues
+## 技术债务和已知问题
 
-### Critical Technical Debt
+### 关键技术债务
 
-1. **Payment Service**: Legacy code in `src/legacy/payment.js` - tightly coupled, no tests
+1.  **支付服务**：`src/legacy/payment.js` 中的旧代码 - 紧密耦合，没有测试
-2. **User Service**: Different pattern than other services, uses callbacks instead of promises
+2.  **用户服务**：与其他服务模式不同，使用回调而不是Promise
-3. **Database Migrations**: Manually tracked, no proper migration tool
+3.  **数据库迁移**：手动跟踪，没有合适的迁移工具
-4. **[Other significant debt]**
+4.  **[其他重大债务]**
 
-### Workarounds and Gotchas
+### 变通方法和陷阱
 
-- **Environment Variables**: Must set `NODE_ENV=production` even for staging (historical reason)
+-   **环境变量**：即使对于预发环境，也必须设置 `NODE_ENV=production`（历史原因）
-- **Database Connections**: Connection pool hardcoded to 10, changing breaks payment service
+-   **数据库连接**：连接池硬编码为10，更改会破坏支付服务
-- **[Other workarounds developers need to know]**
+-   **[开发人员需要知道的其他变通方法]**
 
-## Integration Points and External Dependencies
+## 集成点和外部依赖
 
-### External Services
+### 外部服务
 
-| Service  | Purpose  | Integration Type | Key Files                      |
+| 服务 | 目的 | 集成类型 | 关键文件 |
-| -------- | -------- | ---------------- | ------------------------------ |
+| --- | --- | --- | --- |
-| Stripe   | Payments | REST API         | `src/integrations/stripe/`     |
+| Stripe | 支付 | REST API | `src/integrations/stripe/` |
-| SendGrid | Emails   | SDK              | `src/services/emailService.js` |
+| SendGrid | 电子邮件 | SDK | `src/services/emailService.js` |
 
-etc...
+等等...
 
-### Internal Integration Points
+### 内部集成点
 
-- **Frontend Communication**: REST API on port 3000, expects specific headers
+-   **前端通信**：端口3000上的REST API，需要特定的头信息
-- **Background Jobs**: Redis queue, see `src/workers/`
+-   **后台作业**：Redis队列，参见 `src/workers/`
-- **[Other integrations]**
+-   **[其他集成]**
 
-## Development and Deployment
+## 开发和部署
 
-### Local Development Setup
+### 本地开发设置
 
-1. Actual steps that work (not ideal steps)
+1.  实际可行的步骤（不是理想步骤）
-2. Known issues with setup
+2.  设置的已知问题
-3. Required environment variables (see `.env.example`)
+3.  所需的环境变量（参见 `.env.example`）
 
-### Build and Deployment Process
+### 构建和部署过程
 
-- **Build Command**: `npm run build` (webpack config in `webpack.config.js`)
+-   **构建命令**：`npm run build`（webpack配置在 `webpack.config.js` 中）
-- **Deployment**: Manual deployment via `scripts/deploy.sh`
+-   **部署**：通过 `scripts/deploy.sh` 手动部署
-- **Environments**: Dev, Staging, Prod (see `config/environments/`)
+-   **环境**：开发、预发、生产（参见 `config/environments/`）
 
-## Testing Reality
+## 测试现状
 
-### Current Test Coverage
+### 当前测试覆盖率
 
-- Unit Tests: 60% coverage (Jest)
+-   单元测试：60%覆盖率（Jest）
-- Integration Tests: Minimal, in `tests/integration/`
+-   集成测试：最少，在 `tests/integration/` 中
-- E2E Tests: None
+-   端到端测试：无
-- Manual Testing: Primary QA method
+-   手动测试：主要的QA方法
 
-### Running Tests
+### 运行测试
 
 ```bash
-npm test           # Runs unit tests
+npm test           # 运行单元测试
-npm run test:integration  # Runs integration tests (requires local DB)
+npm run test:integration  # 运行集成测试（需要本地数据库）
 ```
 
-## If Enhancement PRD Provided - Impact Analysis
+## 如果提供了增强PRD - 影响分析
 
-### Files That Will Need Modification
+### 需要修改的文件
 
-Based on the enhancement requirements, these files will be affected:
+根据增强需求，这些文件将受到影响：
 
-- `src/services/userService.js` - Add new user fields
+-   `src/services/userService.js` - 添加新的用户字段
-- `src/models/User.js` - Update schema
+-   `src/models/User.js` - 更新模式
-- `src/routes/userRoutes.js` - New endpoints
+-   `src/routes/userRoutes.js` - 新的端点
-- [etc...]
+-   [等等...]
 
-### New Files/Modules Needed
+### 需要的新文件/模块
 
-- `src/services/newFeatureService.js` - New business logic
+-   `src/services/newFeatureService.js` - 新的业务逻辑
-- `src/models/NewFeature.js` - New data model
+-   `src/models/NewFeature.js` - 新的数据模型
-- [etc...]
+-   [等等...]
 
-### Integration Considerations
+### 集成注意事项
 
-- Will need to integrate with existing auth middleware
+-   需要与现有的身份验证中间件集成
-- Must follow existing response format in `src/utils/responseFormatter.js`
+-   必须遵循 `src/utils/responseFormatter.js` 中的现有响应格式
-- [Other integration points]
+-   [其他集成点]
 
-## Appendix - Useful Commands and Scripts
+## 附录 - 有用的命令和脚本
 
-### Frequently Used Commands
+### 常用命令
 
 ```bash
-npm run dev         # Start development server
+npm run dev         # 启动开发服务器
-npm run build       # Production build
+npm run build       # 生产构建
-npm run migrate     # Run database migrations
+npm run migrate     # 运行数据库迁移
-npm run seed        # Seed test data
+npm run seed        # 填充测试数据
 ```
 
-### Debugging and Troubleshooting
+### 调试和故障排除
 
-- **Logs**: Check `logs/app.log` for application logs
+-   **日志**：检查 `logs/app.log` 以获取应用程序日志
-- **Debug Mode**: Set `DEBUG=app:*` for verbose logging
+-   **调试模式**：设置 `DEBUG=app:*` 以获取详细日志
-- **Common Issues**: See `docs/troubleshooting.md`]]
+-   **常见问题**：参见 `docs/troubleshooting.md`]]
 
-### 4. Document Delivery
+### 4. 文档交付
 
-1. **In Web UI (Gemini, ChatGPT, Claude)**:
+1.  **在Web UI中（Gemini, ChatGPT, Claude）**：
-   - Present the entire document in one response (or multiple if too long)
+    -   在一个响应中呈现整个文档（如果太长则分多个）
-   - Tell user to copy and save as `docs/brownfield-architecture.md` or `docs/project-architecture.md`
+    -   告诉用户复制并另存为 `docs/brownfield-architecture.md` 或 `docs/project-architecture.md`
-   - Mention it can be sharded later in IDE if needed
+    -   如果需要，提及以后可以在IDE中分片
 
-2. **In IDE Environment**:
+2.  **在IDE环境中**：
-   - Create the document as `docs/brownfield-architecture.md`
+    -   将文档创建为 `docs/brownfield-architecture.md`
-   - Inform user this single document contains all architectural information
+    -   告知用户此单个文档包含所有架构信息
-   - Can be sharded later using PO agent if desired
+    -   如果需要，以后可以使用PO代理分片
 
-The document should be comprehensive enough that future agents can understand:
+文档应足够全面，以便将来的代理能够理解：
 
-- The actual state of the system (not idealized)
+-   系统的实际状态（非理想化）
-- Where to find key files and logic
+-   在哪里找到关键文件和逻辑
-- What technical debt exists
+-   存在哪些技术债务
-- What constraints must be respected
+-   必须遵守哪些约束
-- If PRD provided: What needs to change for the enhancement]]
+-   如果提供了PRD：增强功能需要更改什么]]
 
-### 5. Quality Assurance
+### 5. 质量保证
 
-CRITICAL: Before finalizing the document:
+关键：在最终确定文档之前：
 
-1. **Accuracy Check**: Verify all technical details match the actual codebase
+1.  **准确性检查**：验证所有技术细节与实际代码库匹配
-2. **Completeness Review**: Ensure all major system components are documented
+2.  **完整性审查**：确保所有主要系统组件都已记录
-3. **Focus Validation**: If user provided scope, verify relevant areas are emphasized
+3.  **重点验证**：如果用户提供了范围，验证相关领域是否被强调
-4. **Clarity Assessment**: Check that explanations are clear for AI agents
+4.  **清晰度评估**：检查解释对AI代理是否清晰
-5. **Navigation**: Ensure document has clear section structure for easy reference
+5.  **导航**：确保文档具有清晰的章节结构，便于参考
 
-Apply the advanced elicitation task after major sections to refine based on user feedback.
+在主要章节后应用高级启发任务，以根据用户反馈进行完善。
 
-## Success Criteria
+## 成功标准
 
-- Single comprehensive brownfield architecture document created
+-   创建了单一的综合性棕地架构文档
-- Document reflects REALITY including technical debt and workarounds
+-   文档反映了现实，包括技术债务和变通方法
-- Key files and modules are referenced with actual paths
+-   关键文件和模块用实际路径引用
-- Models/APIs reference source files rather than duplicating content
+-   模型/API引用源文件而不是重复内容
-- If PRD provided: Clear impact analysis showing what needs to change
+-   如果提供了PRD：清晰的影响分析，显示需要更改的内容
-- Document enables AI agents to navigate and understand the actual codebase
+-   文档使AI代理能够导航和理解实际代码库
-- Technical constraints and "gotchas" are clearly documented
+-   清楚地记录了技术约束和“陷阱”
 
-## Notes
+## 说明
 
-- This task creates ONE document that captures the TRUE state of the system
+-   此任务创建一个捕获系统真实状态的单一文档
-- References actual files rather than duplicating content when possible
+-   尽可能引用实际文件而不是重复内容
-- Documents technical debt, workarounds, and constraints honestly
+-   诚实地记录技术债务、变通方法和约束
-- For brownfield projects with PRD: Provides clear enhancement impact analysis
+-   对于有PRD的棕地项目：提供清晰的增强影响分析
-- The goal is PRACTICAL documentation for AI agents doing real work
+-   目标是为从事实际工作的AI代理提供实用的文档

bmad-core/tasks/facilitate-brainstorming-session.md

@@ -1,138 +1,138 @@
-## <!-- Powered by BMAD™ Core -->
+<!-- 由 BMAD™ Core 驱动 -->
 
 docOutputLocation: docs/brainstorming-session-results.md
 template: '{root}/templates/brainstorming-output-tmpl.yaml'
 
 ---
 
-# Facilitate Brainstorming Session Task
+# 主持头脑风暴会议任务
 
-Facilitate interactive brainstorming sessions with users. Be creative and adaptive in applying techniques.
+与用户一起主持互动式头脑风暴会议。在应用技巧时要富有创造性和适应性。
 
-## Process
+## 流程
 
-### Step 1: Session Setup
+### 步骤1：会议设置
 
-Ask 4 context questions (don't preview what happens next):
+提出4个背景问题（不要预告下一步会发生什么）：
 
-1. What are we brainstorming about?
+1.  我们正在为什么进行头脑风暴？
-2. Any constraints or parameters?
+2.  有什么限制或参数吗？
-3. Goal: broad exploration or focused ideation?
+3.  目标是：广泛探索还是集中构思？
-4. Do you want a structured document output to reference later? (Default Yes)
+4.  您是否希望有一个结构化的文档输出来供以后参考？（默认为是）
 
-### Step 2: Present Approach Options
+### 步骤2：呈现方法选项
 
-After getting answers to Step 1, present 4 approach options (numbered):
+在得到步骤1的答案后，呈现4个方法选项（编号）：
 
-1. User selects specific techniques
+1.  用户选择具体技巧
-2. Analyst recommends techniques based on context
+2.  分析师根据背景推荐技巧
-3. Random technique selection for creative variety
+3.  随机选择技巧以获得创意多样性
-4. Progressive technique flow (start broad, narrow down)
+4.  渐进式技巧流程（从广泛开始，然后收窄）
 
-### Step 3: Execute Techniques Interactively
+### 步骤3：互动式执行技巧
 
-**KEY PRINCIPLES:**
+**关键原则：**
 
-- **FACILITATOR ROLE**: Guide user to generate their own ideas through questions, prompts, and examples
+-   **引导者角色**：通过问题、提示和示例引导用户产生自己的想法
-- **CONTINUOUS ENGAGEMENT**: Keep user engaged with chosen technique until they want to switch or are satisfied
+-   **持续参与**：让用户持续参与所选技巧，直到他们想切换或满意为止
-- **CAPTURE OUTPUT**: If (default) document output requested, capture all ideas generated in each technique section to the document from the beginning.
+-   **捕获输出**：如果（默认）请求了文档输出，则从一开始就将每个技巧部分产生的所有想法捕获到文档中。
 
-**Technique Selection:**
+**技巧选择：**
-If user selects Option 1, present numbered list of techniques from the brainstorming-techniques data file. User can select by number..
+如果用户选择选项1，则从头脑风暴技巧数据文件中呈现编号的技巧列表。用户可以通过数字选择。
 
-**Technique Execution:**
+**技巧执行：**
 
-1. Apply selected technique according to data file description
+1.  根据数据文件描述应用所选技巧
-2. Keep engaging with technique until user indicates they want to:
+2.  持续使用该技巧，直到用户表示他们想：
-   - Choose a different technique
+    -   选择一个不同的技巧
-   - Apply current ideas to a new technique
+    -   将当前的想法应用于一个新的技巧
-   - Move to convergent phase
+    -   进入收敛阶段
-   - End session
+    -   结束会议
 
-**Output Capture (if requested):**
+**输出捕获（如果请求）：**
-For each technique used, capture:
+对于每个使用的技巧，捕获：
 
-- Technique name and duration
+-   技巧名称和持续时间
-- Key ideas generated by user
+-   用户产生的关键想法
-- Insights and patterns identified
+-   识别出的见解和模式
-- User's reflections on the process
+-   用户对过程的反思
 
-### Step 4: Session Flow
+### 步骤4：会议流程
 
-1. **Warm-up** (5-10 min) - Build creative confidence
+1.  **热身**（5-10分钟）- 建立创造性信心
-2. **Divergent** (20-30 min) - Generate quantity over quality
+2.  **发散**（20-30分钟）- 追求数量而非质量
-3. **Convergent** (15-20 min) - Group and categorize ideas
+3.  **收敛**（15-20分钟）- 分组和分类想法
-4. **Synthesis** (10-15 min) - Refine and develop concepts
+4.  **综合**（10-15分钟）- 完善和发展概念
 
-### Step 5: Document Output (if requested)
+### 步骤5：文档输出（如果请求）
 
-Generate structured document with these sections:
+生成包含以下部分的结构化文档：
 
-**Executive Summary**
+**执行摘要**
 
-- Session topic and goals
+-   会议主题和目标
-- Techniques used and duration
+-   使用的技巧和持续时间
-- Total ideas generated
+-   产生的总想法数
-- Key themes and patterns identified
+-   识别出的关键主题和模式
 
-**Technique Sections** (for each technique used)
+**技巧部分**（针对每个使用的技巧）
 
-- Technique name and description
+-   技巧名称和描述
-- Ideas generated (user's own words)
+-   产生的想法（用户的原话）
-- Insights discovered
+-   发现的见解
-- Notable connections or patterns
+-   值得注意的联系或模式
 
-**Idea Categorization**
+**想法分类**
 
-- **Immediate Opportunities** - Ready to implement now
+-   **即时机会** - 现在就可以实施
-- **Future Innovations** - Requires development/research
+-   **未来创新** - 需要开发/研究
-- **Moonshots** - Ambitious, transformative concepts
+-   **登月计划** - 雄心勃勃的、变革性的概念
-- **Insights & Learnings** - Key realizations from session
+-   **见解与学习** - 会议中的关键认识
 
-**Action Planning**
+**行动计划**
 
-- Top 3 priority ideas with rationale
+-   前3个优先想法及其理由
-- Next steps for each priority
+-   每个优先事项的后续步骤
-- Resources/research needed
+-   需要的资源/研究
-- Timeline considerations
+-   时间线考虑
 
-**Reflection & Follow-up**
+**反思与跟进**
 
-- What worked well in this session
+-   本次会议中哪些方面做得很好
-- Areas for further exploration
+-   需要进一步探索的领域
-- Recommended follow-up techniques
+-   推荐的后续技巧
-- Questions that emerged for future sessions
+-   未来会议中出现的问题
 
-## Key Principles
+## 关键原则
 
-- **YOU ARE A FACILITATOR**: Guide the user to brainstorm, don't brainstorm for them (unless they request it persistently)
+-   **你是一名引导者**：引导用户进行头脑风暴，而不是替他们头脑风暴（除非他们坚持要求）
-- **INTERACTIVE DIALOGUE**: Ask questions, wait for responses, build on their ideas
+-   **互动对话**：提问，等待回应，在他们的想法上进行构建
-- **ONE TECHNIQUE AT A TIME**: Don't mix multiple techniques in one response
+-   **一次一个技巧**：不要在一个回应中混合多种技巧
-- **CONTINUOUS ENGAGEMENT**: Stay with one technique until user wants to switch
+-   **持续参与**：坚持使用一个技巧，直到用户想切换
-- **DRAW IDEAS OUT**: Use prompts and examples to help them generate their own ideas
+-   **引出想法**：使用提示和示例帮助他们产生自己的想法
-- **REAL-TIME ADAPTATION**: Monitor engagement and adjust approach as needed
+-   **实时适应**：监控参与度并根据需要调整方法
-- Maintain energy and momentum
+-   保持精力和势头
-- Defer judgment during generation
+-   在产生想法时推迟判断
-- Quantity leads to quality (aim for 100 ideas in 60 minutes)
+-   数量带来质量（目标是在60分钟内产生100个想法）
-- Build on ideas collaboratively
+-   协作构建想法
-- Document everything in output document
+-   在输出文档中记录所有内容
 
-## Advanced Engagement Strategies
+## 高级参与策略
 
-**Energy Management**
+**精力管理**
 
-- Check engagement levels: "How are you feeling about this direction?"
+-   检查参与水平：“您对这个方向感觉如何？”
-- Offer breaks or technique switches if energy flags
+-   如果精力下降，提供休息或切换技巧
-- Use encouraging language and celebrate idea generation
+-   使用鼓励性语言并庆祝想法的产生
 
-**Depth vs. Breadth**
+**深度与广度**
 
-- Ask follow-up questions to deepen ideas: "Tell me more about that..."
+-   提出后续问题以深化想法：“能再多告诉我一些关于那个…”
-- Use "Yes, and..." to build on their ideas
+-   使用“是的，而且…”来构建他们的想法
-- Help them make connections: "How does this relate to your earlier idea about...?"
+-   帮助他们建立联系：“这与您之前关于…的想法有什么关系？”
 
-**Transition Management**
+**过渡管理**
 
-- Always ask before switching techniques: "Ready to try a different approach?"
+-   在切换技巧前总是询问：“准备好尝试一种不同的方法了吗？”
-- Offer options: "Should we explore this idea deeper or generate more alternatives?"
+-   提供选项：“我们应该更深入地探讨这个想法，还是产生更多的替代方案？”
-- Respect their process and timing
+-   尊重他们的过程和时间安排

bmad-core/tasks/generate-ai-frontend-prompt.md

@@ -1,53 +1,53 @@
-<!-- Powered by BMAD™ Core -->
+<!-- 由 BMAD™ Core 驱动 -->
 
-# Create AI Frontend Prompt Task
+# 创建AI前端提示任务
 
-## Purpose
+## 目的
 
-To generate a masterful, comprehensive, and optimized prompt that can be used with any AI-driven frontend development tool (e.g., Vercel v0, Lovable.ai, or similar) to scaffold or generate significant portions of a frontend application.
+生成一个精湛、全面且优化的提示，可用于任何AI驱动的前端开发工具（例如，Vercel v0、Lovable.ai或类似工具），以搭建或生成前端应用程序的重要部分。
 
-## Inputs
+## 输入
 
-- Completed UI/UX Specification (`front-end-spec.md`)
+-   完整的UI/UX规范 (`front-end-spec.md`)
-- Completed Frontend Architecture Document (`front-end-architecture`) or a full stack combined architecture such as `architecture.md`
+-   完整的前端架构文档 (`front-end-architecture`) 或全栈组合架构，例如 `architecture.md`
-- Main System Architecture Document (`architecture` - for API contracts and tech stack to give further context)
+-   主系统架构文档 (`architecture` - 用于API合约和技术栈以提供更多上下文)
 
-## Key Activities & Instructions
+## 关键活动与说明
 
-### 1. Core Prompting Principles
+### 1. 核心提示原则
 
-Before generating the prompt, you must understand these core principles for interacting with a generative AI for code.
+在生成提示之前，您必须了解与用于代码的生成式AI交互的这些核心原则。
 
-- **Be Explicit and Detailed**: The AI cannot read your mind. Provide as much detail and context as possible. Vague requests lead to generic or incorrect outputs.
+-   **明确具体**：AI无法读懂您的心思。提供尽可能多的细节和上下文。模糊的请求会导致通用或不正确的输出。
-- **Iterate, Don't Expect Perfection**: Generating an entire complex application in one go is rare. The most effective method is to prompt for one component or one section at a time, then build upon the results.
+-   **迭代，不要期望完美**：一次性生成整个复杂的应用程序很少见。最有效的方法是一次提示一个组件或一个部分，然后在结果的基础上进行构建。
-- **Provide Context First**: Always start by providing the AI with the necessary context, such as the tech stack, existing code snippets, and overall project goals.
+-   **首先提供上下文**：始终首先向AI提供必要的上下文，例如技术栈、现有代码片段和总体项目目标。
-- **Mobile-First Approach**: Frame all UI generation requests with a mobile-first design mindset. Describe the mobile layout first, then provide separate instructions for how it should adapt for tablet and desktop.
+-   **移动优先方法**：以移动优先的设计思维来构建所有UI生成请求。首先描述移动布局，然后提供关于它应如何适应平板电脑和桌面的单独说明。
 
-### 2. The Structured Prompting Framework
+### 2. 结构化提示框架
 
-To ensure the highest quality output, you MUST structure every prompt using the following four-part framework.
+为确保最高质量的输出，您必须使用以下四部分框架来构建每个提示。
 
-1. **High-Level Goal**: Start with a clear, concise summary of the overall objective. This orients the AI on the primary task.
+1.  **高层目标**：以清晰、简洁的总体目标摘要开始。这可以使AI明确主要任务。
-   - _Example: "Create a responsive user registration form with client-side validation and API integration."_
+    -   *示例：“创建一个具有客户端验证和API集成的响应式用户注册表单。”*
-2. **Detailed, Step-by-Step Instructions**: Provide a granular, numbered list of actions the AI should take. Break down complex tasks into smaller, sequential steps. This is the most critical part of the prompt.
+2.  **详细的、分步的说明**：提供一个细粒度的、编号的AI应采取的行动列表。将复杂的任务分解为更小的、顺序的步骤。这是提示中最关键的部分。
-   - _Example: "1. Create a new file named `RegistrationForm.js`. 2. Use React hooks for state management. 3. Add styled input fields for 'Name', 'Email', and 'Password'. 4. For the email field, ensure it is a valid email format. 5. On submission, call the API endpoint defined below."_
+    -   *示例：“1. 创建一个名为 `RegistrationForm.js` 的新文件。2. 使用React钩子进行状态管理。3. 为‘姓名’、‘电子邮件’和‘密码’添加带样式的输入字段。4. 对于电子邮件字段，确保其为有效的电子邮件格式。5. 提交时，调用下面定义的API端点。”*
-3. **Code Examples, Data Structures & Constraints**: Include any relevant snippets of existing code, data structures, or API contracts. This gives the AI concrete examples to work with. Crucially, you must also state what _not_ to do.
+3.  **代码示例、数据结构和约束**：包括任何相关的现有代码片段、数据结构或API合约。这为AI提供了具体的示例。至关重要的是，您还必须说明*不*该做什么。
-   - _Example: "Use this API endpoint: `POST /api/register`. The expected JSON payload is `{ "name": "string", "email": "string", "password": "string" }`. Do NOT include a 'confirm password' field. Use Tailwind CSS for all styling."_
+    -   *示例：“使用此API端点：`POST /api/register`。预期的JSON负载是 `{ "name": "string", "email": "string", "password": "string" }`。不要包括‘确认密码’字段。所有样式都使用Tailwind CSS。”*
-4. **Define a Strict Scope**: Explicitly define the boundaries of the task. Tell the AI which files it can modify and, more importantly, which files to leave untouched to prevent unintended changes across the codebase.
+4.  **定义严格的范围**：明确定义任务的边界。告诉AI它可以修改哪些文件，更重要的是，哪些文件要保持不变，以防止在整个代码库中发生意外更改。
-   - _Example: "You should only create the `RegistrationForm.js` component and add it to the `pages/register.js` file. Do NOT alter the `Navbar.js` component or any other existing page or component."_
+    -   *示例：“您只应创建 `RegistrationForm.js` 组件并将其添加到 `pages/register.js` 文件中。不要更改 `Navbar.js` 组件或任何其他现有页面或组件。”*
 
-### 3. Assembling the Master Prompt
+### 3. 组装主提示
 
-You will now synthesize the inputs and the above principles into a final, comprehensive prompt.
+您现在将综合输入和上述原则，形成一个最终的、全面的提示。
 
-1. **Gather Foundational Context**:
+1.  **收集基础上下文**：
-   - Start the prompt with a preamble describing the overall project purpose, the full tech stack (e.g., Next.js, TypeScript, Tailwind CSS), and the primary UI component library being used.
+    -   以描述总体项目目的、完整技术栈（例如，Next.js、TypeScript、Tailwind CSS）和正在使用的主要UI组件库的前言开始提示。
-2. **Describe the Visuals**:
+2.  **描述视觉效果**：
-   - If the user has design files (Figma, etc.), instruct them to provide links or screenshots.
+    -   如果用户有设计文件（Figma等），请指示他们提供链接或屏幕截图。
-   - If not, describe the visual style: color palette, typography, spacing, and overall aesthetic (e.g., "minimalist", "corporate", "playful").
+    -   如果没有，请描述视觉风格：调色板、排版、间距和整体美学（例如，“简约”、“企业”、“俏皮”）。
-3. **Build the Prompt using the Structured Framework**:
+3.  **使用结构化框架构建提示**：
-   - Follow the four-part framework from Section 2 to build out the core request, whether it's for a single component or a full page.
+    -   遵循第2节中的四部分框架来构建核心请求，无论是针对单个组件还是整个页面。
-4. **Present and Refine**:
+4.  **呈现和完善**：
-   - Output the complete, generated prompt in a clear, copy-pasteable format (e.g., a large code block).
+    -   以清晰、可复制粘贴的格式（例如，一个大的代码块）输出完整的、生成的提示。
-   - Explain the structure of the prompt and why certain information was included, referencing the principles above.
+    -   解释提示的结构以及为何包含某些信息，并参考上述原则。
-   - <important_note>Conclude by reminding the user that all AI-generated code will require careful human review, testing, and refinement to be considered production-ready.</important_note>
+    -   <important_note>最后提醒用户，所有AI生成的代码都需要仔细的人工审查、测试和完善，才能被认为是生产就绪的。</important_note>

bmad-core/tasks/index-docs.md

@@ -1,175 +1,175 @@
-<!-- Powered by BMAD™ Core -->
+<!-- 由 BMAD™ Core 驱动 -->
 
-# Index Documentation Task
+# 索引文档任务
 
-## Purpose
+## 目的
 
-This task maintains the integrity and completeness of the `docs/index.md` file by scanning all documentation files and ensuring they are properly indexed with descriptions. It handles both root-level documents and documents within subfolders, organizing them hierarchically.
+此任务通过扫描所有文档文件并确保它们都已正确索引并附有描述，来维护`docs/index.md`文件的完整性。它处理根级文档和子文件夹中的文档，并按层次结构组织它们。
 
-## Task Instructions
+## 任务说明
 
-You are now operating as a Documentation Indexer. Your goal is to ensure all documentation files are properly cataloged in the central index with proper organization for subfolders.
+您现在作为文档索引员操作。您的目标是确保所有文档文件都已在中央索引中正确编目，并为子文件夹进行适当的组织。
 
-### Required Steps
+### 所需步骤
 
-1. First, locate and scan:
+1.  首先，定位并扫描：
-   - The `docs/` directory and all subdirectories
+    -   `docs/`目录及其所有子目录
-   - The existing `docs/index.md` file (create if absent)
+    -   现有的`docs/index.md`文件（如果不存在则创建）
-   - All markdown (`.md`) and text (`.txt`) files in the documentation structure
+    -   文档结构中的所有markdown (`.md`)和文本(`.txt`)文件
-   - Note the folder structure for hierarchical organization
+    -   注意文件夹结构以进行分层组织
 
-2. For the existing `docs/index.md`:
+2.  对于现有的`docs/index.md`：
-   - Parse current entries
+    -   解析当前条目
-   - Note existing file references and descriptions
+    -   注意现有的文件引用和描述
-   - Identify any broken links or missing files
+    -   识别任何损坏的链接或丢失的文件
-   - Keep track of already-indexed content
+    -   跟踪已索引的内容
-   - Preserve existing folder sections
+    -   保留现有的文件夹部分
 
-3. For each documentation file found:
+3.  对于找到的每个文档文件：
-   - Extract the title (from first heading or filename)
+    -   提取标题（从第一个标题或文件名）
-   - Generate a brief description by analyzing the content
+    -   通过分析内容生成简要描述
-   - Create a relative markdown link to the file
+    -   创建到文件的相对markdown链接
-   - Check if it's already in the index
+    -   检查它是否已在索引中
-   - Note which folder it belongs to (if in a subfolder)
+    -   注意它属于哪个文件夹（如果在子文件夹中）
-   - If missing or outdated, prepare an update
+    -   如果丢失或过时，则准备更新
 
-4. For any missing or non-existent files found in index:
+4.  对于在索引中找到但不存在的任何文件：
-   - Present a list of all entries that reference non-existent files
+    -   呈现引用不存在的文件的所有条目的列表
-   - For each entry:
+    -   对于每个条目：
-     - Show the full entry details (title, path, description)
+        -   显示完整的条目详细信息（标题、路径、描述）
-     - Ask for explicit confirmation before removal
+        -   在删除前要求明确确认
-     - Provide option to update the path if file was moved
+        -   如果文件已移动，则提供更新路径的选项
-     - Log the decision (remove/update/keep) for final report
+        -   记录决定（删除/更新/保留）以供最终报告
 
-5. Update `docs/index.md`:
+5.  更新`docs/index.md`：
-   - Maintain existing structure and organization
+    -   保持现有的结构和组织
-   - Create level 2 sections (`##`) for each subfolder
+    -   为每个子文件夹创建2级部分（`##`）
-   - List root-level documents first
+    -   首先列出根级文档
-   - Add missing entries with descriptions
+    -   添加带有描述的缺失条目
-   - Update outdated entries
+    -   更新过时的条目
-   - Remove only entries that were confirmed for removal
+    -   仅删除已确认为删除的条目
-   - Ensure consistent formatting throughout
+    -   确保整个格式一致
 
-### Index Structure Format
+### 索引结构格式
 
-The index should be organized as follows:
+索引应按以下方式组织：
 
 ```markdown
-# Documentation Index
+# 文档索引
 
-## Root Documents
+## 根文档
 
-### [Document Title](./document.md)
+### [文档标题](./document.md)
 
-Brief description of the document's purpose and contents.
+文档目的和内容的简要描述。
 
-### [Another Document](./another.md)
+### [另一个文档](./another.md)
 
-Description here.
+此处的描述。
 
-## Folder Name
+## 文件夹名称
 
-Documents within the `folder-name/` directory:
+`folder-name/`目录中的文档：
 
-### [Document in Folder](./folder-name/document.md)
+### [文件夹中的文档](./folder-name/document.md)
 
-Description of this document.
+此文档的描述。
 
-### [Another in Folder](./folder-name/another.md)
+### [文件夹中的另一个](./folder-name/another.md)
 
-Description here.
+此处的描述。
 
-## Another Folder
+## 另一个文件夹
 
-Documents within the `another-folder/` directory:
+`another-folder/`目录中的文档：
 
-### [Nested Document](./another-folder/document.md)
+### [嵌套文档](./another-folder/document.md)
 
-Description of nested document.
+嵌套文档的描述。
 ```
 
-### Index Entry Format
+### 索引条目格式
 
-Each entry should follow this format:
+每个条目应遵循此格式：
 
 ```markdown
-### [Document Title](relative/path/to/file.md)
+### [文档标题](relative/path/to/file.md)
 
-Brief description of the document's purpose and contents.
+文档目的和内容的简要描述。
 ```
 
-### Rules of Operation
+### 操作规则
 
-1. NEVER modify the content of indexed files
+1.  切勿修改索引文件的内容
-2. Preserve existing descriptions in index.md when they are adequate
+2.  在现有描述足够的情况下，保留index.md中的现有描述
-3. Maintain any existing categorization or grouping in the index
+3.  保持索引中任何现有的分类或分组
-4. Use relative paths for all links (starting with `./`)
+4.  对所有链接使用相对路径（以`./`开头）
-5. Ensure descriptions are concise but informative
+5.  确保描述简洁但信息丰富
-6. NEVER remove entries without explicit confirmation
+6.  未经明确确认，切勿删除条目
-7. Report any broken links or inconsistencies found
+7.  报告发现的任何损坏链接或不一致之处
-8. Allow path updates for moved files before considering removal
+8.  在考虑删除之前，允许为移动的文件更新路径
-9. Create folder sections using level 2 headings (`##`)
+9.  使用2级标题（`##`）创建文件夹部分
-10. Sort folders alphabetically, with root documents listed first
+10. 按字母顺序对文件夹进行排序，根文档列在最前面
-11. Within each section, sort documents alphabetically by title
+11. 在每个部分内，按标题字母顺序对文档进行排序
 
-### Process Output
+### 流程输出
 
-The task will provide:
+该任务将提供：
 
-1. A summary of changes made to index.md
+1.  对index.md所做更改的摘要
-2. List of newly indexed files (organized by folder)
+2.  新索引文件的列表（按文件夹组织）
-3. List of updated entries
+3.  更新条目的列表
-4. List of entries presented for removal and their status:
+4.  为删除而呈现的条目及其状态列表：
-   - Confirmed removals
+    -   已确认删除
-   - Updated paths
+    -   已更新路径
-   - Kept despite missing file
+    -   尽管文件丢失但仍保留
-5. Any new folders discovered
+5.  发现的任何新文件夹
-6. Any other issues or inconsistencies found
+6.  发现的任何其他问题或不一致之处
 
-### Handling Missing Files
+### 处理丢失的文件
 
-For each file referenced in the index but not found in the filesystem:
+对于索引中引用但在文件系统中未找到的每个文件：
 
-1. Present the entry:
+1.  呈现该条目：
 
     ```markdown
-   Missing file detected:
+    检测到丢失文件：
-   Title: [Document Title]
+    标题：[文档标题]
-   Path: relative/path/to/file.md
+    路径：relative/path/to/file.md
-   Description: Existing description
+    描述：现有描述
-   Section: [Root Documents | Folder Name]
+    部分：[根文档 | 文件夹名称]
 
-   Options:
+    选项：
 
-   1. Remove this entry
+    1. 删除此条目
-   2. Update the file path
+    2. 更新文件路径
-   3. Keep entry (mark as temporarily unavailable)
+    3. 保留条目（标记为暂时不可用）
 
-   Please choose an option (1/2/3):
+    请选择一个选项（1/2/3）：
     ```
 
-2. Wait for user confirmation before taking any action
+2.  在采取任何行动之前等待用户确认
-3. Log the decision for the final report
+3.  记录决定以供最终报告
 
-### Special Cases
+### 特殊情况
 
-1. **Sharded Documents**: If a folder contains an `index.md` file, treat it as a sharded document:
+1.  **分片文档**：如果文件夹包含`index.md`文件，则将其视为分片文档：
-   - Use the folder's `index.md` title as the section title
+    -   使用文件夹的`index.md`标题作为章节标题
-   - List the folder's documents as subsections
+    -   将文件夹的文档列为子部分
-   - Note in the description that this is a multi-part document
+    -   在描述中注明这是一个多部分文档
 
-2. **README files**: Convert `README.md` to more descriptive titles based on content
+2.  **README文件**：根据内容将`README.md`转换为更具描述性的标题
 
-3. **Nested Subfolders**: For deeply nested folders, maintain the hierarchy but limit to 2 levels in the main index. Deeper structures should have their own index files.
+3.  **嵌套子文件夹**：对于深度嵌套的文件夹，保持层次结构，但在主索引中限制为2级。更深的结构应有自己的索引文件。
 
-## Required Input
+## 所需输入
 
-Please provide:
+请提供：
 
-1. Location of the `docs/` directory (default: `./docs`)
+1.  `docs/`目录的位置（默认：`./docs`）
-2. Confirmation of write access to `docs/index.md`
+2.  对`docs/index.md`的写访问权限的确认
-3. Any specific categorization preferences
+3.  任何特定的分类偏好
-4. Any files or directories to exclude from indexing (e.g., `.git`, `node_modules`)
+4.  任何要从索引中排除的文件或目录（例如，`.git`、`node_modules`）
-5. Whether to include hidden files/folders (starting with `.`)
+5.  是否包括隐藏文件/文件夹（以`.`开头）
 
-Would you like to proceed with documentation indexing? Please provide the required input above.
+您想继续进行文档索引吗？请提供上述所需输入。

bmad-core/tasks/kb-mode-interaction.md

@@ -1,77 +1,77 @@
-<!-- Powered by BMAD™ Core -->
+<!-- 由 BMAD™ Core 驱动 -->
 
-# KB Mode Interaction Task
+# 知识库模式交互任务
 
-## Purpose
+## 目的
 
-Provide a user-friendly interface to the BMad knowledge base without overwhelming users with information upfront.
+为BMad知识库提供一个用户友好的界面，而不会预先用信息淹没用户。
 
-## Instructions
+## 说明
 
-When entering KB mode (\*kb-mode), follow these steps:
+进入知识库模式（\*kb-mode）时，请遵循以下步骤：
 
-### 1. Welcome and Guide
+### 1. 欢迎和引导
 
-Announce entering KB mode with a brief, friendly introduction.
+以简短、友好的介绍宣布进入知识库模式。
 
-### 2. Present Topic Areas
+### 2. 呈现主题领域
 
-Offer a concise list of main topic areas the user might want to explore:
+提供一个简洁的主题领域列表，用户可能想要探索：
 
-**What would you like to know more about?**
+**您想了解更多关于什么的信息？**
 
-1. **Setup & Installation** - Getting started with BMad
+1.  **设置与安装** - 开始使用BMad
-2. **Workflows** - Choosing the right workflow for your project
+2.  **工作流** - 为您的项目选择正确的工作流
-3. **Web vs IDE** - When to use each environment
+3.  **Web vs IDE** - 何时使用每个环境
-4. **Agents** - Understanding specialized agents and their roles
+4.  **代理** - 理解专业代理及其角色
-5. **Documents** - PRDs, Architecture, Stories, and more
+5.  **文档** - PRD、架构、故事等
-6. **Agile Process** - How BMad implements Agile methodologies
+6.  **敏捷流程** - BMad如何实施敏捷方法论
-7. **Configuration** - Customizing BMad for your needs
+7.  **配置** - 根据您的需求定制BMad
-8. **Best Practices** - Tips for effective BMad usage
+8.  **最佳实践** - 有效使用BMad的技巧
 
-Or ask me about anything else related to BMad-Method!
+或者向我询问任何与BMad-Method相关的其他问题！
 
-### 3. Respond Contextually
+### 3. 上下文响应
 
-- Wait for user's specific question or topic selection
+-   等待用户的具体问题或主题选择
-- Provide focused, relevant information from the knowledge base
+-   从知识库中提供专注、相关的信息
-- Offer to dive deeper or explore related topics
+-   提议深入探讨或探索相关主题
-- Keep responses concise unless user asks for detailed explanations
+-   除非用户要求详细解释，否则保持响应简洁
 
-### 4. Interactive Exploration
+### 4. 互动探索
 
-- After answering, suggest related topics they might find helpful
+-   回答后，建议他们可能会觉得有帮助的相关主题
-- Maintain conversational flow rather than data dumping
+-   保持对话流畅，而不是数据倾倒
-- Use examples when appropriate
+-   在适当时使用示例
-- Reference specific documentation sections when relevant
+-   在相关时引用特定的文档部分
 
-### 5. Exit Gracefully
+### 5. 优雅退出
 
-When user is done or wants to exit KB mode:
+当用户完成或想要退出知识库模式时：
 
-- Summarize key points discussed if helpful
+-   如果需要，总结讨论的要点
-- Remind them they can return to KB mode anytime with \*kb-mode
+-   提醒他们可以随时使用\*kb-mode返回知识库模式
-- Suggest next steps based on what was discussed
+-   根据讨论的内容建议下一步
 
-## Example Interaction
+## 示例交互
 
-**User**: \*kb-mode
+**用户**：\*kb-mode
 
-**Assistant**: I've entered KB mode and have access to the full BMad knowledge base. I can help you with detailed information about any aspect of BMad-Method.
+**助手**：我已进入知识库模式，可以访问完整的BMad知识库。我可以为您提供有关BMad-Method任何方面的详细信息。
 
-**What would you like to know more about?**
+**您想了解更多关于什么的信息？**
 
-1. **Setup & Installation** - Getting started with BMad
+1.  **设置与安装** - 开始使用BMad
-2. **Workflows** - Choosing the right workflow for your project
+2.  **工作流** - 为您的项目选择正确的工作流
-3. **Web vs IDE** - When to use each environment
+3.  **Web vs IDE** - 何时使用每个环境
-4. **Agents** - Understanding specialized agents and their roles
+4.  **代理** - 理解专业代理及其角色
-5. **Documents** - PRDs, Architecture, Stories, and more
+5.  **文档** - PRD、架构、故事等
-6. **Agile Process** - How BMad implements Agile methodologies
+6.  **敏捷流程** - BMad如何实施敏捷方法论
-7. **Configuration** - Customizing BMad for your needs
+7.  **配置** - 根据您的需求定制BMad
-8. **Best Practices** - Tips for effective BMad usage
+8.  **最佳实践** - 有效使用BMad的技巧
 
-Or ask me about anything else related to BMad-Method!
+或者向我询问任何与BMad-Method相关的其他问题！
 
-**User**: Tell me about workflows
+**用户**：告诉我关于工作流的信息
 
-**Assistant**: [Provides focused information about workflows from the KB, then offers to explore specific workflow types or related topics]
+**助手**：[从知识库中提供关于工作流的专注信息，然后提议探索特定的工作流类型或相关主题]

bmad-core/tasks/nfr-assess.md

@@ -1,329 +1,329 @@
-<!-- Powered by BMAD™ Core -->
+<!-- 由 BMAD™ Core 驱动 -->
 
 # nfr-assess
 
-Quick NFR validation focused on the core four: security, performance, reliability, maintainability.
+快速NFR验证，专注于四个核心：安全性、性能、可靠性、可维护性。
 
-## Inputs
+## 输入
 
 ```yaml
 required:
-  - story_id: '{epic}.{story}' # e.g., "1.3"
+  - story_id: '{epic}.{story}' # 例如, "1.3"
-  - story_path: `bmad-core/core-config.yaml` for the `devStoryLocation`
+  - story_path: `bmad-core/core-config.yaml` 中的 `devStoryLocation`
 
 optional:
-  - architecture_refs: `bmad-core/core-config.yaml` for the `architecture.architectureFile`
+  - architecture_refs: `bmad-core/core-config.yaml` 中的 `architecture.architectureFile`
-  - technical_preferences: `bmad-core/core-config.yaml` for the `technicalPreferences`
+  - technical_preferences: `bmad-core/core-config.yaml` 中的 `technicalPreferences`
-  - acceptance_criteria: From story file
+  - acceptance_criteria: 来自故事文件
 ```
 
-## Purpose
+## 目的
 
-Assess non-functional requirements for a story and generate:
+评估故事的非功能性需求并生成：
 
-1. YAML block for the gate file's `nfr_validation` section
+1.  用于门禁文件的 `nfr_validation` 部分的YAML块
-2. Brief markdown assessment saved to `qa.qaLocation/assessments/{epic}.{story}-nfr-{YYYYMMDD}.md`
+2.  保存到 `qa.qaLocation/assessments/{epic}.{story}-nfr-{YYYYMMDD}.md` 的简短markdown评估
 
-## Process
+## 流程
 
-### 0. Fail-safe for Missing Inputs
+### 0. 输入缺失的故障安全
 
-If story_path or story file can't be found:
+如果找不到story_path或故事文件：
 
-- Still create assessment file with note: "Source story not found"
+-   仍然创建评估文件，并附注：“未找到源故事”
-- Set all selected NFRs to CONCERNS with notes: "Target unknown / evidence missing"
+-   将所有选定的NFR设置为CONCERNS，并附注：“目标未知/证据缺失”
-- Continue with assessment to provide value
+-   继续评估以提供价值
 
-### 1. Elicit Scope
+### 1. 启发范围
 
-**Interactive mode:** Ask which NFRs to assess
+**交互模式：** 询问要评估哪些NFR
-**Non-interactive mode:** Default to core four (security, performance, reliability, maintainability)
+**非交互模式：** 默认为核心四个（安全性、性能、可靠性、可维护性）
 
 ```text
-Which NFRs should I assess? (Enter numbers or press Enter for default)
+我应该评估哪些NFR？（输入数字或按Enter键使用默认值）
-[1] Security (default)
+[1] 安全性 (默认)
-[2] Performance (default)
+[2] 性能 (默认)
-[3] Reliability (default)
+[3] 可靠性 (默认)
-[4] Maintainability (default)
+[4] 可维护性 (默认)
-[5] Usability
+[5] 可用性
-[6] Compatibility
+[6] 兼容性
-[7] Portability
+[7] 可移植性
-[8] Functional Suitability
+[8] 功能适用性
 
-> [Enter for 1-4]
+> [按Enter键选择1-4]
 ```
 
-### 2. Check for Thresholds
+### 2. 检查阈值
 
-Look for NFR requirements in:
+在以下位置查找NFR要求：
 
-- Story acceptance criteria
+-   故事验收标准
-- `docs/architecture/*.md` files
+-   `docs/architecture/*.md` 文件
 -   `docs/technical-preferences.md`
 
-**Interactive mode:** Ask for missing thresholds
+**交互模式：** 询问缺失的阈值
-**Non-interactive mode:** Mark as CONCERNS with "Target unknown"
+**非交互模式：** 标记为CONCERNS，并附注：“目标未知”
 
 ```text
-No performance requirements found. What's your target response time?
+未找到性能要求。您的目标响应时间是多少？
-> 200ms for API calls
+> API调用为200毫秒
 
-No security requirements found. Required auth method?
+未找到安全要求。需要的身份验证方法是什么？
-> JWT with refresh tokens
+> 带刷新令牌的JWT
 ```
 
-**Unknown targets policy:** If a target is missing and not provided, mark status as CONCERNS with notes: "Target unknown"
+**未知目标策略：** 如果目标缺失且未提供，则将状态标记为CONCERNS，并附注：“目标未知”
 
-### 3. Quick Assessment
+### 3. 快速评估
 
-For each selected NFR, check:
+对于每个选定的NFR，检查：
 
-- Is there evidence it's implemented?
+-   是否有证据表明它已实施？
-- Can we validate it?
+-   我们能验证它吗？
-- Are there obvious gaps?
+-   是否有明显的差距？
 
-### 4. Generate Outputs
+### 4. 生成输出
 
-## Output 1: Gate YAML Block
+## 输出1：门禁YAML块
 
-Generate ONLY for NFRs actually assessed (no placeholders):
+仅为实际评估的NFR生成（无占位符）：
 
 ```yaml
-# Gate YAML (copy/paste):
+# 门禁YAML（复制/粘贴）：
 nfr_validation:
   _assessed: [security, performance, reliability, maintainability]
   security:
     status: CONCERNS
-    notes: 'No rate limiting on auth endpoints'
+    notes: '认证端点上没有速率限制'
   performance:
     status: PASS
-    notes: 'Response times < 200ms verified'
+    notes: '已验证响应时间<200毫秒'
   reliability:
     status: PASS
-    notes: 'Error handling and retries implemented'
+    notes: '已实现错误处理和重试'
   maintainability:
     status: CONCERNS
-    notes: 'Test coverage at 65%, target is 80%'
+    notes: '测试覆盖率为65%，目标为80%'
 ```
 
-## Deterministic Status Rules
+## 确定性状态规则
 
-- **FAIL**: Any selected NFR has critical gap or target clearly not met
+-   **FAIL**：任何选定的NFR存在严重差距或明确未达到目标
-- **CONCERNS**: No FAILs, but any NFR is unknown/partial/missing evidence
+-   **CONCERNS**：没有FAIL，但任何NFR未知/部分/证据缺失
-- **PASS**: All selected NFRs meet targets with evidence
+-   **PASS**：所有选定的NFR都已达到目标并有证据
 
-## Quality Score Calculation
+## 质量分数计算
 
 ```
 quality_score = 100
-- 20 for each FAIL attribute
+- 每个FAIL属性扣20分
-- 10 for each CONCERNS attribute
+- 每个CONCERNS属性扣10分
-Floor at 0, ceiling at 100
+最低为0，最高为100
 ```
 
-If `technical-preferences.md` defines custom weights, use those instead.
+如果`technical-preferences.md`定义了自定义权重，则使用这些权重。
 
-## Output 2: Brief Assessment Report
+## 输出2：简短评估报告
 
-**ALWAYS save to:** `qa.qaLocation/assessments/{epic}.{story}-nfr-{YYYYMMDD}.md`
+**始终保存到：** `qa.qaLocation/assessments/{epic}.{story}-nfr-{YYYYMMDD}.md`
 
 ```markdown
-# NFR Assessment: {epic}.{story}
+# NFR评估：{epic}.{story}
 
-Date: {date}
+日期：{date}
-Reviewer: Quinn
+审查员：Quinn
 
-<!-- Note: Source story not found (if applicable) -->
+<!-- 注意：未找到源故事（如果适用） -->
 
-## Summary
+## 摘要
 
-- Security: CONCERNS - Missing rate limiting
+- 安全性：CONCERNS - 缺少速率限制
-- Performance: PASS - Meets <200ms requirement
+- 性能：PASS - 满足<200毫秒的要求
-- Reliability: PASS - Proper error handling
+- 可靠性：PASS - 正确的错误处理
-- Maintainability: CONCERNS - Test coverage below target
+- 可维护性：CONCERNS - 测试覆盖率低于目标
 
-## Critical Issues
+## 关键问题
 
-1. **No rate limiting** (Security)
+1.  **无速率限制**（安全性）
-   - Risk: Brute force attacks possible
+    -   风险：可能遭受暴力破解攻击
-   - Fix: Add rate limiting middleware to auth endpoints
+    -   修复：向认证端点添加速率限制中间件
 
-2. **Test coverage 65%** (Maintainability)
+2.  **测试覆盖率65%**（可维护性）
-   - Risk: Untested code paths
+    -   风险：未经测试的代码路径
-   - Fix: Add tests for uncovered branches
+    -   修复：为未覆盖的分支添加测试
 
-## Quick Wins
+## 快速见效的修复
 
-- Add rate limiting: ~2 hours
+-   添加速率限制：约2小时
-- Increase test coverage: ~4 hours
+-   增加测试覆盖率：约4小时
-- Add performance monitoring: ~1 hour
+-   添加性能监控：约1小时
 ```
 
-## Output 3: Story Update Line
+## 输出3：故事更新行
 
-**End with this line for the review task to quote:**
+**以该行结束，供审查任务引用：**
 
 ```
-NFR assessment: qa.qaLocation/assessments/{epic}.{story}-nfr-{YYYYMMDD}.md
+NFR评估：qa.qaLocation/assessments/{epic}.{story}-nfr-{YYYYMMDD}.md
 ```
 
-## Output 4: Gate Integration Line
+## 输出4：门禁集成行
 
-**Always print at the end:**
+**始终在末尾打印：**
 
 ```
-Gate NFR block ready → paste into qa.qaLocation/gates/{epic}.{story}-{slug}.yml under nfr_validation
+门禁NFR块已准备好 → 粘贴到 qa.qaLocation/gates/{epic}.{story}-{slug}.yml 的 nfr_validation 下
 ```
 
-## Assessment Criteria
+## 评估标准
 
-### Security
+### 安全性
 
-**PASS if:**
+**PASS如果：**
 
-- Authentication implemented
+-   已实现身份验证
-- Authorization enforced
+-   已强制执行授权
-- Input validation present
+-   存在输入验证
-- No hardcoded secrets
+-   无硬编码机密
 
-**CONCERNS if:**
+**CONCERNS如果：**
 
-- Missing rate limiting
+-   缺少速率限制
-- Weak encryption
+-   加密较弱
-- Incomplete authorization
+-   授权不完整
 
-**FAIL if:**
+**FAIL如果：**
 
-- No authentication
+-   无身份验证
-- Hardcoded credentials
+-   硬编码凭据
-- SQL injection vulnerabilities
+-   SQL注入漏洞
 
-### Performance
+### 性能
 
-**PASS if:**
+**PASS如果：**
 
-- Meets response time targets
+-   满足响应时间目标
-- No obvious bottlenecks
+-   无明显瓶颈
-- Reasonable resource usage
+-   合理的资源使用
 
-**CONCERNS if:**
+**CONCERNS如果：**
 
-- Close to limits
+-   接近极限
-- Missing indexes
+-   缺少索引
-- No caching strategy
+-   无缓存策略
 
-**FAIL if:**
+**FAIL如果：**
 
-- Exceeds response time limits
+-   超过响应时间限制
-- Memory leaks
+-   内存泄漏
-- Unoptimized queries
+-   未优化的查询
 
-### Reliability
+### 可靠性
 
-**PASS if:**
+**PASS如果：**
 
-- Error handling present
+-   存在错误处理
-- Graceful degradation
+-   优雅降级
-- Retry logic where needed
+-   在需要时有重试逻辑
 
-**CONCERNS if:**
+**CONCERNS如果：**
 
-- Some error cases unhandled
+-   某些错误情况未处理
-- No circuit breakers
+-   无断路器
-- Missing health checks
+-   缺少健康检查
 
-**FAIL if:**
+**FAIL如果：**
 
-- No error handling
+-   无错误处理
-- Crashes on errors
+-   出错时崩溃
-- No recovery mechanisms
+-   无恢复机制
 
-### Maintainability
+### 可维护性
 
-**PASS if:**
+**PASS如果：**
 
-- Test coverage meets target
+-   测试覆盖率达到目标
-- Code well-structured
+-   代码结构良好
-- Documentation present
+-   存在文档
 
-**CONCERNS if:**
+**CONCERNS如果：**
 
-- Test coverage below target
+-   测试覆盖率低于目标
-- Some code duplication
+-   一些代码重复
-- Missing documentation
+-   缺少文档
 
-**FAIL if:**
+**FAIL如果：**
 
-- No tests
+-   无测试
-- Highly coupled code
+-   代码高度耦合
-- No documentation
+-   无文档
 
-## Quick Reference
+## 快速参考
 
-### What to Check
+### 要检查的内容
 
 ```yaml
 security:
-  - Authentication mechanism
+  - 身份验证机制
-  - Authorization checks
+  - 授权检查
-  - Input validation
+  - 输入验证
-  - Secret management
+  - 密钥管理
-  - Rate limiting
+  - 速率限制
 
 performance:
-  - Response times
+  - 响应时间
-  - Database queries
+  - 数据库查询
-  - Caching usage
+  - 缓存使用
-  - Resource consumption
+  - 资源消耗
 
 reliability:
-  - Error handling
+  - 错误处理
-  - Retry logic
+  - 重试逻辑
-  - Circuit breakers
+  - 断路器
-  - Health checks
+  - 健康检查
-  - Logging
+  - 日志记录
 
 maintainability:
-  - Test coverage
+  - 测试覆盖率
-  - Code structure
+  - 代码结构
-  - Documentation
+  - 文档
-  - Dependencies
+  - 依赖项
 ```
 
-## Key Principles
+## 关键原则
 
-- Focus on the core four NFRs by default
+-   默认专注于核心四个NFR
-- Quick assessment, not deep analysis
+-   快速评估，而非深入分析
-- Gate-ready output format
+-   门禁就绪的输出格式
-- Brief, actionable findings
+-   简短、可操作的发现
-- Skip what doesn't apply
+-   跳过不适用的内容
-- Deterministic status rules for consistency
+-   确定性状态规则以保持一致性
-- Unknown targets → CONCERNS, not guesses
+-   未知目标 → CONCERNS，而非猜测
 
 ---
 
-## Appendix: ISO 25010 Reference
+## 附录：ISO 25010参考
 
 <details>
-<summary>Full ISO 25010 Quality Model (click to expand)</summary>
+<summary>完整的ISO 25010质量模型（点击展开）</summary>
 
-### All 8 Quality Characteristics
+### 所有8个质量特性
 
-1. **Functional Suitability**: Completeness, correctness, appropriateness
+1.  **功能适用性**：完整性、正确性、适当性
-2. **Performance Efficiency**: Time behavior, resource use, capacity
+2.  **性能效率**：时间行为、资源使用、容量
-3. **Compatibility**: Co-existence, interoperability
+3.  **兼容性**：共存性、互操作性
-4. **Usability**: Learnability, operability, accessibility
+4.  **可用性**：易学性、可操作性、可访问性
-5. **Reliability**: Maturity, availability, fault tolerance
+5.  **可靠性**：成熟度、可用性、容错性
-6. **Security**: Confidentiality, integrity, authenticity
+6.  **安全性**：机密性、完整性、真实性
-7. **Maintainability**: Modularity, reusability, testability
+7.  **可维护性**：模块化、可重用性、可测试性
-8. **Portability**: Adaptability, installability
+8.  **可移植性**：适应性、可安装性
 
-Use these when assessing beyond the core four.
+在评估核心四个之外的内容时使用这些。
 
 </details>
 
 <details>
-<summary>Example: Deep Performance Analysis (click to expand)</summary>
+<summary>示例：深度性能分析（点击展开）</summary>
 
 ```yaml
 performance_deep_dive:
@@ -336,7 +336,7 @@ performance_deep_dive:
     missing_indexes: ['users.email', 'orders.user_id']
   caching:
     hit_rate: 0%
-    recommendation: 'Add Redis for session data'
+    recommendation: '为会话数据添加Redis'
   load_test:
     max_rps: 150
     breaking_point: 200 rps

bmad-core/tasks/qa-gate.md

@@ -1,163 +1,163 @@
-<!-- Powered by BMAD™ Core -->
+<!-- 由 BMAD™ Core 驱动 -->
 
 # qa-gate
 
-Create or update a quality gate decision file for a story based on review findings.
+根据审查结果为故事创建或更新质量门禁决策文件。
 
-## Purpose
+## 目的
 
-Generate a standalone quality gate file that provides a clear pass/fail decision with actionable feedback. This gate serves as an advisory checkpoint for teams to understand quality status.
+生成一个独立的质量门禁文件，提供明确的通过/失败决策和可操作的反馈。此门禁作为团队了解质量状态的咨询性检查点。
 
-## Prerequisites
+## 先决条件
 
-- Story has been reviewed (manually or via review-story task)
+-   故事已经过审查（手动或通过review-story任务）
-- Review findings are available
+-   审查结果可用
-- Understanding of story requirements and implementation
+-   了解故事需求和实现
 
-## Gate File Location
+## 门禁文件位置
 
-**ALWAYS** check the `bmad-core/core-config.yaml` for the `qa.qaLocation/gates`
+**始终**检查`bmad-core/core-config.yaml`中的`qa.qaLocation/gates`
 
-Slug rules:
+**别名规则：**
 
-- Convert to lowercase
+-   转换为小写
-- Replace spaces with hyphens
+-   用连字符替换空格
-- Strip punctuation
+-   去除标点符号
-- Example: "User Auth - Login!" becomes "user-auth-login"
+-   示例：“User Auth - Login!”变为“user-auth-login”
 
-## Minimal Required Schema
+## 最低要求的模式
 
 ```yaml
 schema: 1
 story: '{epic}.{story}'
 gate: PASS|CONCERNS|FAIL|WAIVED
-status_reason: '1-2 sentence explanation of gate decision'
+status_reason: '1-2句话解释门禁决策'
 reviewer: 'Quinn'
-updated: '{ISO-8601 timestamp}'
+updated: '{ISO-8601时间戳}'
-top_issues: [] # Empty array if no issues
+top_issues: [] # 如果没有问题则为空数组
-waiver: { active: false } # Only set active: true if WAIVED
+waiver: { active: false } # 仅在WAIVED时设置active: true
 ```
 
-## Schema with Issues
+## 带有问题的模式
 
 ```yaml
 schema: 1
 story: '1.3'
 gate: CONCERNS
-status_reason: 'Missing rate limiting on auth endpoints poses security risk.'
+status_reason: '认证端点上缺少速率限制，存在安全风险。'
 reviewer: 'Quinn'
 updated: '2025-01-12T10:15:00Z'
 top_issues:
   - id: 'SEC-001'
-    severity: high # ONLY: low|medium|high
+    severity: high # 仅限：low|medium|high
-    finding: 'No rate limiting on login endpoint'
+    finding: '登录端点上没有速率限制'
-    suggested_action: 'Add rate limiting middleware before production'
+    suggested_action: '在生产前添加速率限制中间件'
   - id: 'TEST-001'
     severity: medium
-    finding: 'No integration tests for auth flow'
+    finding: '认证流程没有集成测试'
-    suggested_action: 'Add integration test coverage'
+    suggested_action: '添加集成测试覆盖'
 waiver: { active: false }
 ```
 
-## Schema when Waived
+## 豁免时的模式
 
 ```yaml
 schema: 1
 story: '1.3'
 gate: WAIVED
-status_reason: 'Known issues accepted for MVP release.'
+status_reason: '为MVP版本接受了已知问题。'
 reviewer: 'Quinn'
 updated: '2025-01-12T10:15:00Z'
 top_issues:
   - id: 'PERF-001'
     severity: low
-    finding: 'Dashboard loads slowly with 1000+ items'
+    finding: '有1000+个项目时仪表板加载缓慢'
-    suggested_action: 'Implement pagination in next sprint'
+    suggested_action: '在下一个冲刺中实现分页'
 waiver:
   active: true
-  reason: 'MVP release - performance optimization deferred'
+  reason: 'MVP版本 - 性能优化已推迟'
-  approved_by: 'Product Owner'
+  approved_by: '产品负责人'
 ```
 
-## Gate Decision Criteria
+## 门禁决策标准
 
 ### PASS
 
-- All acceptance criteria met
+-   所有验收标准均已满足
-- No high-severity issues
+-   没有高严重性问题
-- Test coverage meets project standards
+-   测试覆盖率符合项目标准
 
 ### CONCERNS
 
-- Non-blocking issues present
+-   存在非阻塞性问题
-- Should be tracked and scheduled
+-   应进行跟踪和安排
-- Can proceed with awareness
+-   可以在知情的情况下继续进行
 
 ### FAIL
 
-- Acceptance criteria not met
+-   未满足验收标准
-- High-severity issues present
+-   存在高严重性问题
-- Recommend return to InProgress
+-   建议返回到进行中状态
 
 ### WAIVED
 
-- Issues explicitly accepted
+-   问题已明确接受
-- Requires approval and reason
+-   需要批准和理由
-- Proceed despite known issues
+-   尽管存在已知问题，仍继续进行
 
-## Severity Scale
+## 严重性等级
 
-**FIXED VALUES - NO VARIATIONS:**
+**固定值 - 无变体：**
 
-- `low`: Minor issues, cosmetic problems
+-   `low`: 次要问题，外观问题
-- `medium`: Should fix soon, not blocking
+-   `medium`: 应尽快修复，非阻塞性
-- `high`: Critical issues, should block release
+-   `high`: 严重问题，应阻止发布
 
-## Issue ID Prefixes
+## 问题ID前缀
 
-- `SEC-`: Security issues
+-   `SEC-`: 安全问题
-- `PERF-`: Performance issues
+-   `PERF-`: 性能问题
-- `REL-`: Reliability issues
+-   `REL-`: 可靠性问题
-- `TEST-`: Testing gaps
+-   `TEST-`: 测试差距
-- `MNT-`: Maintainability concerns
+-   `MNT-`: 可维护性问题
-- `ARCH-`: Architecture issues
+-   `ARCH-`: 架构问题
-- `DOC-`: Documentation gaps
+-   `DOC-`: 文档差距
-- `REQ-`: Requirements issues
+-   `REQ-`: 需求问题
 
-## Output Requirements
+## 输出要求
 
-1. **ALWAYS** create gate file at: `qa.qaLocation/gates` from `bmad-core/core-config.yaml`
+1.  **始终**在`bmad-core/core-config.yaml`中的`qa.qaLocation/gates`创建门禁文件
-2. **ALWAYS** append this exact format to story's QA Results section:
+2.  **始终**将此确切格式附加到故事的QA结果部分：
 
     ```text
     Gate: {STATUS} → qa.qaLocation/gates/{epic}.{story}-{slug}.yml
     ```
 
-3. Keep status_reason to 1-2 sentences maximum
+3.  将status_reason保持在最多1-2句话
-4. Use severity values exactly: `low`, `medium`, or `high`
+4.  完全使用严重性值：`low`、`medium`或`high`
 
-## Example Story Update
+## 示例故事更新
 
-After creating gate file, append to story's QA Results section:
+创建门禁文件后，附加到故事的QA结果部分：
 
 ```markdown
-## QA Results
+## QA结果
 
-### Review Date: 2025-01-12
+### 审查日期：2025-01-12
 
-### Reviewed By: Quinn (Test Architect)
+### 审查员：Quinn（测试架构师）
 
-[... existing review content ...]
+[...现有审查内容...]
 
-### Gate Status
+### 门禁状态
 
 Gate: CONCERNS → qa.qaLocation/gates/{epic}.{story}-{slug}.yml
 ```
 
-## Key Principles
+## 关键原则
 
-- Keep it minimal and predictable
+-   保持最小化和可预测性
-- Fixed severity scale (low/medium/high)
+-   固定的严重性等级（低/中/高）
-- Always write to standard path
+-   始终写入标准路径
-- Always update story with gate reference
+-   始终用门禁参考更新故事
-- Clear, actionable findings
+-   清晰、可操作的发现

bmad-core/tasks/review-story.md

@@ -1,316 +1,316 @@
-<!-- Powered by BMAD™ Core -->
+<!-- 由 BMAD™ Core 驱动 -->
 
 # review-story
 
-Perform a comprehensive test architecture review with quality gate decision. This adaptive, risk-aware review creates both a story update and a detailed gate file.
+执行全面的测试架构审查并做出质量门禁决策。这种自适应、风险感知的审查会创建一个故事更新和一个详细的门禁文件。
 
-## Inputs
+## 输入
 
 ```yaml
 required:
-  - story_id: '{epic}.{story}' # e.g., "1.3"
+  - story_id: '{epic}.{story}' # 例如, "1.3"
-  - story_path: '{devStoryLocation}/{epic}.{story}.*.md' # Path from core-config.yaml
+  - story_path: '{devStoryLocation}/{epic}.{story}.*.md' # 来自core-config.yaml的路径
-  - story_title: '{title}' # If missing, derive from story file H1
+  - story_title: '{title}' # 如果缺少，则从故事文件的H1派生
-  - story_slug: '{slug}' # If missing, derive from title (lowercase, hyphenated)
+  - story_slug: '{slug}' # 如果缺少，则从标题派生 (小写，连字符连接)
 ```
 
-## Prerequisites
+## 先决条件
 
-- Story status must be "Review"
+-   故事状态必须是“待审查”
-- Developer has completed all tasks and updated the File List
+-   开发人员已完成所有任务并更新了文件列表
-- All automated tests are passing
+-   所有自动化测试均已通过
 
-## Review Process - Adaptive Test Architecture
+## 审查流程 - 自适应测试架构
 
-### 1. Risk Assessment (Determines Review Depth)
+### 1. 风险评估（决定审查深度）
 
-**Auto-escalate to deep review when:**
+**在以下情况下自动升级为深度审查：**
 
-- Auth/payment/security files touched
+-   触及了认证/支付/安全文件
-- No tests added to story
+-   故事中没有添加任何测试
-- Diff > 500 lines
+-   差异 > 500行
-- Previous gate was FAIL/CONCERNS
+-   上一个门禁是FAIL/CONCERNS
-- Story has > 5 acceptance criteria
+-   故事有 > 5个验收标准
 
-### 2. Comprehensive Analysis
+### 2. 综合分析
 
-**A. Requirements Traceability**
+**A. 需求可追溯性**
 
-- Map each acceptance criteria to its validating tests (document mapping with Given-When-Then, not test code)
+-   将每个验收标准映射到其验证测试（用Given-When-Then记录映射，而非测试代码）
-- Identify coverage gaps
+-   识别覆盖差距
-- Verify all requirements have corresponding test cases
+-   验证所有需求都有相应的测试用例
 
-**B. Code Quality Review**
+**B. 代码质量审查**
 
-- Architecture and design patterns
+-   架构和设计模式
-- Refactoring opportunities (and perform them)
+-   重构机会（并执行它们）
-- Code duplication or inefficiencies
+-   代码重复或效率低下
-- Performance optimizations
+-   性能优化
-- Security vulnerabilities
+-   安全漏洞
-- Best practices adherence
+-   遵守最佳实践
 
-**C. Test Architecture Assessment**
+**C. 测试架构评估**
 
-- Test coverage adequacy at appropriate levels
+-   在适当级别上的测试覆盖率是否足够
-- Test level appropriateness (what should be unit vs integration vs e2e)
+-   测试级别的适当性（什么是单元测试、集成测试、端到端测试）
-- Test design quality and maintainability
+-   测试设计的质量和可维护性
-- Test data management strategy
+-   测试数据管理策略
-- Mock/stub usage appropriateness
+-   模拟/桩的使用是否适当
-- Edge case and error scenario coverage
+-   边缘情况和错误场景的覆盖
-- Test execution time and reliability
+-   测试执行时间和可靠性
 
-**D. Non-Functional Requirements (NFRs)**
+**D. 非功能性需求（NFR）**
 
-- Security: Authentication, authorization, data protection
+-   安全性：认证、授权、数据保护
-- Performance: Response times, resource usage
+-   性能：响应时间、资源使用
-- Reliability: Error handling, recovery mechanisms
+-   可靠性：错误处理、恢复机制
-- Maintainability: Code clarity, documentation
+-   可维护性：代码清晰度、文档
 
-**E. Testability Evaluation**
+**E. 可测试性评估**
 
-- Controllability: Can we control the inputs?
+-   可控性：我们能控制输入吗？
-- Observability: Can we observe the outputs?
+-   可观察性：我们能观察输出吗？
-- Debuggability: Can we debug failures easily?
+-   可调试性：我们能轻松调试失败吗？
 
-**F. Technical Debt Identification**
+**F. 技术债务识别**
 
-- Accumulated shortcuts
+-   累积的捷径
-- Missing tests
+-   缺失的测试
-- Outdated dependencies
+-   过时的依赖项
-- Architecture violations
+-   违反架构
 
-### 3. Active Refactoring
+### 3. 主动重构
 
-- Refactor code where safe and appropriate
+-   在安全和适当的情况下重构代码
-- Run tests to ensure changes don't break functionality
+-   运行测试以确保更改不会破坏功能
-- Document all changes in QA Results section with clear WHY and HOW
+-   在QA结果部分记录所有更改，并附上清晰的“为什么”和“如何”
-- Do NOT alter story content beyond QA Results section
+-   不要修改QA结果部分之外的故事内容
-- Do NOT change story Status or File List; recommend next status only
+-   不要更改故事状态或文件列表；仅建议下一个状态
 
-### 4. Standards Compliance Check
+### 4. 标准合规性检查
 
-- Verify adherence to `docs/coding-standards.md`
+-   验证是否遵守`docs/coding-standards.md`
-- Check compliance with `docs/unified-project-structure.md`
+-   检查是否符合`docs/unified-project-structure.md`
-- Validate testing approach against `docs/testing-strategy.md`
+-   根据`docs/testing-strategy.md`验证测试方法
-- Ensure all guidelines mentioned in the story are followed
+-   确保遵守故事中提到的所有准则
 
-### 5. Acceptance Criteria Validation
+### 5. 验收标准验证
 
-- Verify each AC is fully implemented
+-   验证每个AC是否已完全实现
-- Check for any missing functionality
+-   检查是否有任何缺失的功能
-- Validate edge cases are handled
+-   验证边缘情况是否已处理
 
-### 6. Documentation and Comments
+### 6. 文档和注释
 
-- Verify code is self-documenting where possible
+-   验证代码在可能的情况下是否是自文档化的
-- Add comments for complex logic if missing
+-   如果缺少，为复杂逻辑添加注释
-- Ensure any API changes are documented
+-   确保任何API更改都已记录
 
-## Output 1: Update Story File - QA Results Section ONLY
+## 输出1：仅更新故事文件 - QA结果部分
 
-**CRITICAL**: You are ONLY authorized to update the "QA Results" section of the story file. DO NOT modify any other sections.
+**关键**：您仅被授权更新故事文件的“QA结果”部分。请勿修改任何其他部分。
 
-**QA Results Anchor Rule:**
+**QA结果锚点规则：**
 
-- If `## QA Results` doesn't exist, append it at end of file
+-   如果`## QA结果`不存在，则在文件末尾追加它
-- If it exists, append a new dated entry below existing entries
+-   如果存在，则在现有条目下方追加一个新的带日期的条目
-- Never edit other sections
+-   切勿编辑其他部分
 
-After review and any refactoring, append your results to the story file in the QA Results section:
+审查和任何重构后，将您的结果附加到故事文件的QA结果部分：
 
 ```markdown
-## QA Results
+## QA结果
 
-### Review Date: [Date]
+### 审查日期：[日期]
 
-### Reviewed By: Quinn (Test Architect)
+### 审查员：Quinn（测试架构师）
 
-### Code Quality Assessment
+### 代码质量评估
 
-[Overall assessment of implementation quality]
+[对实施质量的总体评估]
 
-### Refactoring Performed
+### 执行的重构
 
-[List any refactoring you performed with explanations]
+[列出您执行的任何重构并附上解释]
 
-- **File**: [filename]
+-   **文件**：[文件名]
-  - **Change**: [what was changed]
+    -   **更改**：[更改了什么]
-  - **Why**: [reason for change]
+    -   **原因**：[更改原因]
-  - **How**: [how it improves the code]
+    -   **方式**：[它如何改进代码]
 
-### Compliance Check
+### 合规性检查
 
-- Coding Standards: [✓/✗] [notes if any]
+-   编码标准：[✓/✗] [如有说明]
-- Project Structure: [✓/✗] [notes if any]
+-   项目结构：[✓/✗] [如有说明]
-- Testing Strategy: [✓/✗] [notes if any]
+-   测试策略：[✓/✗] [如有说明]
-- All ACs Met: [✓/✗] [notes if any]
+-   所有AC均已满足：[✓/✗] [如有说明]
 
-### Improvements Checklist
+### 改进清单
 
-[Check off items you handled yourself, leave unchecked for dev to address]
+[勾选您自己处理的项目，未勾选的留给开发人员处理]
 
-- [x] Refactored user service for better error handling (services/user.service.ts)
+-   [x] 为更好的错误处理重构了用户服务 (services/user.service.ts)
-- [x] Added missing edge case tests (services/user.service.test.ts)
+-   [x] 添加了缺失的边缘情况测试 (services/user.service.test.ts)
-- [ ] Consider extracting validation logic to separate validator class
+-   [ ] 考虑将验证逻辑提取到单独的验证器类中
-- [ ] Add integration test for error scenarios
+-   [ ] 为错误场景添加集成测试
-- [ ] Update API documentation for new error codes
+-   [ ] 为新的错误代码更新API文档
 
-### Security Review
+### 安全审查
 
-[Any security concerns found and whether addressed]
+[发现的任何安全问题以及是否已解决]
 
-### Performance Considerations
+### 性能考虑
 
-[Any performance issues found and whether addressed]
+[发现的任何性能问题以及是否已解决]
 
-### Files Modified During Review
+### 审查期间修改的文件
 
-[If you modified files, list them here - ask Dev to update File List]
+[如果您修改了文件，请在此处列出 - 要求开发人员更新文件列表]
 
-### Gate Status
+### 门禁状态
 
 Gate: {STATUS} → qa.qaLocation/gates/{epic}.{story}-{slug}.yml
 Risk profile: qa.qaLocation/assessments/{epic}.{story}-risk-{YYYYMMDD}.md
 NFR assessment: qa.qaLocation/assessments/{epic}.{story}-nfr-{YYYYMMDD}.md
 
-# Note: Paths should reference core-config.yaml for custom configurations
+# 注意：路径应引用core-config.yaml以获取自定义配置
 
-### Recommended Status
+### 推荐状态
 
-[✓ Ready for Done] / [✗ Changes Required - See unchecked items above]
+[✓ 准备完成] / [✗ 需要更改 - 见上方未勾选项目]
-(Story owner decides final status)
+（故事所有者决定最终状态）
 ```
 
-## Output 2: Create Quality Gate File
+## 输出2：创建质量门禁文件
 
-**Template and Directory:**
+**模板和目录：**
 
-- Render from `../templates/qa-gate-tmpl.yaml`
+-   从`../templates/qa-gate-tmpl.yaml`渲染
-- Create directory defined in `qa.qaLocation/gates` (see `bmad-core/core-config.yaml`) if missing
+-   在`qa.qaLocation/gates`中创建目录（参见`bmad-core/core-config.yaml`），如果不存在
-- Save to: `qa.qaLocation/gates/{epic}.{story}-{slug}.yml`
+-   保存到：`qa.qaLocation/gates/{epic}.{story}-{slug}.yml`
 
-Gate file structure:
+门禁文件结构：
 
 ```yaml
 schema: 1
 story: '{epic}.{story}'
 story_title: '{story title}'
 gate: PASS|CONCERNS|FAIL|WAIVED
-status_reason: '1-2 sentence explanation of gate decision'
+status_reason: '1-2句话解释门禁决策'
-reviewer: 'Quinn (Test Architect)'
+reviewer: 'Quinn (测试架构师)'
-updated: '{ISO-8601 timestamp}'
+updated: '{ISO-8601时间戳}'
 
-top_issues: [] # Empty if no issues
+top_issues: [] # 如果没有问题则为空
-waiver: { active: false } # Set active: true only if WAIVED
+waiver: { active: false } # 仅在WAIVED时设置active: true
 
-# Extended fields (optional but recommended):
+# 扩展字段（可选但推荐）：
-quality_score: 0-100 # 100 - (20*FAILs) - (10*CONCERNS) or use technical-preferences.md weights
+quality_score: 0-100 # 100 - (20*FAILs) - (10*CONCERNS) 或使用technical-preferences.md权重
-expires: '{ISO-8601 timestamp}' # Typically 2 weeks from review
+expires: '{ISO-8601时间戳}' # 通常为审查后2周
 
 evidence:
   tests_reviewed: { count }
   risks_identified: { count }
   trace:
-    ac_covered: [1, 2, 3] # AC numbers with test coverage
+    ac_covered: [1, 2, 3] # 有测试覆盖的AC编号
-    ac_gaps: [4] # AC numbers lacking coverage
+    ac_gaps: [4] # 缺少覆盖的AC编号
 
 nfr_validation:
   security:
     status: PASS|CONCERNS|FAIL
-    notes: 'Specific findings'
+    notes: '具体发现'
   performance:
     status: PASS|CONCERNS|FAIL
-    notes: 'Specific findings'
+    notes: '具体发现'
   reliability:
     status: PASS|CONCERNS|FAIL
-    notes: 'Specific findings'
+    notes: '具体发现'
   maintainability:
     status: PASS|CONCERNS|FAIL
-    notes: 'Specific findings'
+    notes: '具体发现'
 
 recommendations:
-  immediate: # Must fix before production
+  immediate: # 生产前必须修复
-    - action: 'Add rate limiting'
+    - action: '添加速率限制'
       refs: ['api/auth/login.ts']
-  future: # Can be addressed later
+  future: # 以后可以解决
-    - action: 'Consider caching'
+    - action: '考虑缓存'
       refs: ['services/data.ts']
 ```
 
-### Gate Decision Criteria
+### 门禁决策标准
 
-**Deterministic rule (apply in order):**
+**确定性规则（按顺序应用）：**
 
-If risk_summary exists, apply its thresholds first (≥9 → FAIL, ≥6 → CONCERNS), then NFR statuses, then top_issues severity.
+如果存在risk_summary，则首先应用其阈值（≥9 → FAIL，≥6 → CONCERNS），然后是NFR状态，然后是top_issues严重性。
 
-1. **Risk thresholds (if risk_summary present):**
+1.  **风险阈值（如果存在risk_summary）：**
-   - If any risk score ≥ 9 → Gate = FAIL (unless waived)
+    -   如果任何风险评分≥9 → Gate = FAIL（除非豁免）
-   - Else if any score ≥ 6 → Gate = CONCERNS
+    -   否则如果任何评分≥6 → Gate = CONCERNS
 
-2. **Test coverage gaps (if trace available):**
+2.  **测试覆盖差距（如果trace可用）：**
-   - If any P0 test from test-design is missing → Gate = CONCERNS
+    -   如果缺少任何来自test-design的P0测试 → Gate = CONCERNS
-   - If security/data-loss P0 test missing → Gate = FAIL
+    -   如果缺少安全/数据丢失P0测试 → Gate = FAIL
 
-3. **Issue severity:**
+3.  **问题严重性：**
-   - If any `top_issues.severity == high` → Gate = FAIL (unless waived)
+    -   如果任何`top_issues.severity == high` → Gate = FAIL（除非豁免）
-   - Else if any `severity == medium` → Gate = CONCERNS
+    -   否则如果任何`severity == medium` → Gate = CONCERNS
 
-4. **NFR statuses:**
+4.  **NFR状态：**
-   - If any NFR status is FAIL → Gate = FAIL
+    -   如果任何NFR状态为FAIL → Gate = FAIL
-   - Else if any NFR status is CONCERNS → Gate = CONCERNS
+    -   否则如果任何NFR状态为CONCERNS → Gate = CONCERNS
-   - Else → Gate = PASS
+    -   否则 → Gate = PASS
 
-- WAIVED only when waiver.active: true with reason/approver
+-   WAIVED仅在waiver.active: true并有理由/批准者时
 
-Detailed criteria:
+详细标准：
 
-- **PASS**: All critical requirements met, no blocking issues
+-   **PASS**：所有关键要求均已满足，没有阻塞性问题
-- **CONCERNS**: Non-critical issues found, team should review
+-   **CONCERNS**：存在非关键问题，团队应审查
-- **FAIL**: Critical issues that should be addressed
+-   **FAIL**：应解决的关键问题
-- **WAIVED**: Issues acknowledged but explicitly waived by team
+-   **WAIVED**：问题已确认但团队明确豁免
 
-### Quality Score Calculation
+### 质量分数计算
 
 ```text
-quality_score = 100 - (20 × number of FAILs) - (10 × number of CONCERNS)
+quality_score = 100 - (20 × FAIL数量) - (10 × CONCERNS数量)
-Bounded between 0 and 100
+范围在0到100之间
 ```
 
-If `technical-preferences.md` defines custom weights, use those instead.
+如果`technical-preferences.md`定义了自定义权重，则使用这些权重。
 
-### Suggested Owner Convention
+### 建议的所有者约定
 
-For each issue in `top_issues`, include a `suggested_owner`:
+对于`top_issues`中的每个问题，包括一个`suggested_owner`：
 
-- `dev`: Code changes needed
+-   `dev`：需要代码更改
-- `sm`: Requirements clarification needed
+-   `sm`：需要澄清需求
-- `po`: Business decision needed
+-   `po`：需要业务决策
 
-## Key Principles
+## 关键原则
 
-- You are a Test Architect providing comprehensive quality assessment
+-   您是一名提供全面质量评估的测试架构师
-- You have the authority to improve code directly when appropriate
+-   在适当时，您有权直接改进代码
-- Always explain your changes for learning purposes
+-   始终解释您的更改以供学习
-- Balance between perfection and pragmatism
+-   在完美与实用之间取得平衡
-- Focus on risk-based prioritization
+-   专注于基于风险的优先级排序
-- Provide actionable recommendations with clear ownership
+-   提供具有明确所有权的可操作建议
 
-## Blocking Conditions
+## 阻塞条件
 
-Stop the review and request clarification if:
+如果出现以下情况，请停止审查并请求澄清：
 
-- Story file is incomplete or missing critical sections
+-   故事文件不完整或缺少关键部分
-- File List is empty or clearly incomplete
+-   文件列表为空或明显不完整
-- No tests exist when they were required
+-   在需要时不存在测试
-- Code changes don't align with story requirements
+-   代码更改与故事需求不符
-- Critical architectural issues that require discussion
+-   需要讨论的关键架构问题
 
-## Completion
+## 完成
 
-After review:
+审查后：
 
-1. Update the QA Results section in the story file
+1.  更新故事文件中的QA结果部分
-2. Create the gate file in directory from `qa.qaLocation/gates`
+2.  在`qa.qaLocation/gates`的目录中创建门禁文件
-3. Recommend status: "Ready for Done" or "Changes Required" (owner decides)
+3.  推荐状态：“准备完成”或“需要更改”（所有者决定）
-4. If files were modified, list them in QA Results and ask Dev to update File List
+4.  如果修改了文件，请在QA结果中列出并要求开发人员更新文件列表
-5. Always provide constructive feedback and actionable recommendations
+5.  始终提供建设性反馈和可操作的建议

bmad-core/tasks/risk-profile.md

@@ -1,355 +1,355 @@
-<!-- Powered by BMAD™ Core -->
+<!-- 由 BMAD™ Core 驱动 -->
 
-# risk-profile
+# 风险概况
 
-Generate a comprehensive risk assessment matrix for a story implementation using probability × impact analysis.
+使用概率×影响分析，为故事实施生成全面的风险评估矩阵。
 
-## Inputs
+## 输入
 
 ```yaml
 required:
-  - story_id: '{epic}.{story}' # e.g., "1.3"
+  - story_id: '{epic}.{story}' # 例如, "1.3"
   - story_path: 'docs/stories/{epic}.{story}.*.md'
-  - story_title: '{title}' # If missing, derive from story file H1
+  - story_title: '{title}' # 如果缺少，则从故事文件的H1派生
-  - story_slug: '{slug}' # If missing, derive from title (lowercase, hyphenated)
+  - story_slug: '{slug}' # 如果缺少，则从标题派生（小写，连字符连接）
 ```
 
-## Purpose
+## 目的
 
-Identify, assess, and prioritize risks in the story implementation. Provide risk mitigation strategies and testing focus areas based on risk levels.
+识别、评估和优先处理故事实施中的风险。根据风险级别提供风险缓解策略和测试重点领域。
 
-## Risk Assessment Framework
+## 风险评估框架
 
-### Risk Categories
+### 风险类别
 
-**Category Prefixes:**
+**类别前缀：**
 
-- `TECH`: Technical Risks
+-   `TECH`: 技术风险
-- `SEC`: Security Risks
+-   `SEC`: 安全风险
-- `PERF`: Performance Risks
+-   `PERF`: 性能风险
-- `DATA`: Data Risks
+-   `DATA`: 数据风险
-- `BUS`: Business Risks
+-   `BUS`: 业务风险
-- `OPS`: Operational Risks
+-   `OPS`: 运营风险
 
-1. **Technical Risks (TECH)**
+1.  **技术风险 (TECH)**
-   - Architecture complexity
+    -   架构复杂性
-   - Integration challenges
+    -   集成挑战
-   - Technical debt
+    -   技术债务
-   - Scalability concerns
+    -   可扩展性问题
-   - System dependencies
+    -   系统依赖
 
-2. **Security Risks (SEC)**
+2.  **安全风险 (SEC)**
-   - Authentication/authorization flaws
+    -   认证/授权缺陷
-   - Data exposure vulnerabilities
+    -   数据泄露漏洞
-   - Injection attacks
+    -   注入攻击
-   - Session management issues
+    -   会话管理问题
-   - Cryptographic weaknesses
+    -   加密弱点
 
-3. **Performance Risks (PERF)**
+3.  **性能风险 (PERF)**
-   - Response time degradation
+    -   响应时间下降
-   - Throughput bottlenecks
+    -   吞吐量瓶颈
-   - Resource exhaustion
+    -   资源耗尽
-   - Database query optimization
+    -   数据库查询优化
-   - Caching failures
+    -   缓存失败
 
-4. **Data Risks (DATA)**
+4.  **数据风险 (DATA)**
-   - Data loss potential
+    -   数据丢失的可能性
-   - Data corruption
+    -   数据损坏
-   - Privacy violations
+    -   侵犯隐私
-   - Compliance issues
+    -   合规性问题
-   - Backup/recovery gaps
+    -   备份/恢复差距
 
-5. **Business Risks (BUS)**
+5.  **业务风险 (BUS)**
-   - Feature doesn't meet user needs
+    -   功能不符合用户需求
-   - Revenue impact
+    -   收入影响
-   - Reputation damage
+    -   声誉损害
-   - Regulatory non-compliance
+    -   法规不合规
-   - Market timing
+    -   市场时机
 
-6. **Operational Risks (OPS)**
+6.  **运营风险 (OPS)**
-   - Deployment failures
+    -   部署失败
-   - Monitoring gaps
+    -   监控差距
-   - Incident response readiness
+    -   事件响应准备情况
-   - Documentation inadequacy
+    -   文档不足
-   - Knowledge transfer issues
+    -   知识转移问题
 
-## Risk Analysis Process
+## 风险分析流程
 
-### 1. Risk Identification
+### 1. 风险识别
 
-For each category, identify specific risks:
+为每个类别识别具体风险：
 
 ```yaml
 risk:
-  id: 'SEC-001' # Use prefixes: SEC, PERF, DATA, BUS, OPS, TECH
+  id: 'SEC-001' # 使用前缀：SEC, PERF, DATA, BUS, OPS, TECH
   category: security
-  title: 'Insufficient input validation on user forms'
+  title: '用户表单输入验证不足'
-  description: 'Form inputs not properly sanitized could lead to XSS attacks'
+  description: '表单输入未正确清理可能导致XSS攻击'
   affected_components:
     - 'UserRegistrationForm'
     - 'ProfileUpdateForm'
-  detection_method: 'Code review revealed missing validation'
+  detection_method: '代码审查发现缺少验证'
 ```
 
-### 2. Risk Assessment
+### 2. 风险评估
 
-Evaluate each risk using probability × impact:
+使用概率×影响评估每个风险：
 
-**Probability Levels:**
+**概率级别：**
 
-- `High (3)`: Likely to occur (>70% chance)
+-   `高 (3)`: 很可能发生 (>70%的几率)
-- `Medium (2)`: Possible occurrence (30-70% chance)
+-   `中 (2)`: 可能发生 (30-70%的几率)
-- `Low (1)`: Unlikely to occur (<30% chance)
+-   `低 (1)`: 不太可能发生 (<30%的几率)
 
-**Impact Levels:**
+**影响级别：**
 
-- `High (3)`: Severe consequences (data breach, system down, major financial loss)
+-   `高 (3)`: 严重后果（数据泄露、系统宕机、重大财务损失）
-- `Medium (2)`: Moderate consequences (degraded performance, minor data issues)
+-   `中 (2)`: 中等后果（性能下降、轻微数据问题）
-- `Low (1)`: Minor consequences (cosmetic issues, slight inconvenience)
+-   `低 (1)`: 轻微后果（外观问题、轻微不便）
 
-### Risk Score = Probability × Impact
+### 风险评分 = 概率 × 影响
 
-- 9: Critical Risk (Red)
+-   9: 严重风险 (红色)
-- 6: High Risk (Orange)
+-   6: 高风险 (橙色)
-- 4: Medium Risk (Yellow)
+-   4: 中风险 (黄色)
-- 2-3: Low Risk (Green)
+-   2-3: 低风险 (绿色)
-- 1: Minimal Risk (Blue)
+-   1: 极小风险 (蓝色)
 
-### 3. Risk Prioritization
+### 3. 风险优先级排序
 
-Create risk matrix:
+创建风险矩阵：
 
 ```markdown
-## Risk Matrix
+## 风险矩阵
 
-| Risk ID  | Description             | Probability | Impact     | Score | Priority |
+| 风险ID | 描述 | 概率 | 影响 | 评分 | 优先级 |
-| -------- | ----------------------- | ----------- | ---------- | ----- | -------- |
+| --- | --- | --- | --- | --- | --- |
-| SEC-001  | XSS vulnerability       | High (3)    | High (3)   | 9     | Critical |
+| SEC-001 | XSS漏洞 | 高 (3) | 高 (3) | 9 | 严重 |
-| PERF-001 | Slow query on dashboard | Medium (2)  | Medium (2) | 4     | Medium   |
+| PERF-001 | 仪表板查询缓慢 | 中 (2) | 中 (2) | 4 | 中 |
-| DATA-001 | Backup failure          | Low (1)     | High (3)   | 3     | Low      |
+| DATA-001 | 备份失败 | 低 (1) | 高 (3) | 3 | 低 |
 ```
 
-### 4. Risk Mitigation Strategies
+### 4. 风险缓解策略
 
-For each identified risk, provide mitigation:
+为每个已识别的风险提供缓解措施：
 
 ```yaml
 mitigation:
   risk_id: 'SEC-001'
-  strategy: 'preventive' # preventive|detective|corrective
+  strategy: '预防性' # 预防性|检测性|纠正性
   actions:
-    - 'Implement input validation library (e.g., validator.js)'
+    - '实施输入验证库（例如，validator.js）'
-    - 'Add CSP headers to prevent XSS execution'
+    - '添加CSP头以防止XSS执行'
-    - 'Sanitize all user inputs before storage'
+    - '在存储前清理所有用户输入'
-    - 'Escape all outputs in templates'
+    - '在模板中对所有输出进行转义'
   testing_requirements:
-    - 'Security testing with OWASP ZAP'
+    - '使用OWASP ZAP进行安全测试'
-    - 'Manual penetration testing of forms'
+    - '对表单进行手动渗透测试'
-    - 'Unit tests for validation functions'
+    - '验证函数的单元测试'
-  residual_risk: 'Low - Some zero-day vulnerabilities may remain'
+  residual_risk: '低 - 可能仍存在一些零日漏洞'
   owner: 'dev'
-  timeline: 'Before deployment'
+  timeline: '部署前'
 ```
 
-## Outputs
+## 输出
 
-### Output 1: Gate YAML Block
+### 输出1：门禁YAML块
 
-Generate for pasting into gate file under `risk_summary`:
+生成用于粘贴到门禁文件的`risk_summary`下的内容：
 
-**Output rules:**
+**输出规则：**
 
-- Only include assessed risks; do not emit placeholders
+-   仅包括评估的风险；不要输出占位符
-- Sort risks by score (desc) when emitting highest and any tabular lists
+-   在输出最高风险和任何表格列表时，按分数（降序）对风险进行排序
-- If no risks: totals all zeros, omit highest, keep recommendations arrays empty
+-   如果没有风险：总数全为零，省略最高风险，保持建议数组为空
 
 ```yaml
-# risk_summary (paste into gate file):
+# risk_summary（粘贴到门禁文件）：
 risk_summary:
   totals:
-    critical: X # score 9
+    critical: X # 评分 9
-    high: Y # score 6
+    high: Y # 评分 6
-    medium: Z # score 4
+    medium: Z # 评分 4
-    low: W # score 2-3
+    low: W # 评分 2-3
   highest:
     id: SEC-001
     score: 9
-    title: 'XSS on profile form'
+    title: '个人资料表单上的XSS'
   recommendations:
     must_fix:
-      - 'Add input sanitization & CSP'
+      - '添加入口清理和CSP'
     monitor:
-      - 'Add security alerts for auth endpoints'
+      - '为认证端点添加安全警报'
 ```
 
-### Output 2: Markdown Report
+### 输出2：Markdown报告
 
-**Save to:** `qa.qaLocation/assessments/{epic}.{story}-risk-{YYYYMMDD}.md`
+**保存到：** `qa.qaLocation/assessments/{epic}.{story}-risk-{YYYYMMDD}.md`
 
 ```markdown
-# Risk Profile: Story {epic}.{story}
+# 风险概况：故事 {epic}.{story}
 
-Date: {date}
+日期：{date}
-Reviewer: Quinn (Test Architect)
+审查员：Quinn（测试架构师）
 
-## Executive Summary
+## 执行摘要
 
-- Total Risks Identified: X
+-   已识别风险总数：X
-- Critical Risks: Y
+-   严重风险：Y
-- High Risks: Z
+-   高风险：Z
-- Risk Score: XX/100 (calculated)
+-   风险评分：XX/100（已计算）
 
-## Critical Risks Requiring Immediate Attention
+## 需要立即关注的严重风险
 
-### 1. [ID]: Risk Title
+### 1. [ID]：风险标题
 
-**Score: 9 (Critical)**
+**评分：9（严重）**
-**Probability**: High - Detailed reasoning
+**概率**：高 - 详细理由
-**Impact**: High - Potential consequences
+**影响**：高 - 潜在后果
-**Mitigation**:
+**缓解**：
 
-- Immediate action required
+-   需要立即采取行动
-- Specific steps to take
+-   要采取的具体步骤
-  **Testing Focus**: Specific test scenarios needed
+  **测试重点**：需要的具体测试场景
 
-## Risk Distribution
+## 风险分布
 
-### By Category
+### 按类别
 
-- Security: X risks (Y critical)
+-   安全性：X个风险（Y个严重）
-- Performance: X risks (Y critical)
+-   性能：X个风险（Y个严重）
-- Data: X risks (Y critical)
+-   数据：X个风险（Y个严重）
-- Business: X risks (Y critical)
+-   业务：X个风险（Y个严重）
-- Operational: X risks (Y critical)
+-   运营：X个风险（Y个严重）
 
-### By Component
+### 按组件
 
-- Frontend: X risks
+-   前端：X个风险
-- Backend: X risks
+-   后端：X个风险
-- Database: X risks
+-   数据库：X个风险
-- Infrastructure: X risks
+-   基础设施：X个风险
 
-## Detailed Risk Register
+## 详细风险登记册
 
-[Full table of all risks with scores and mitigations]
+[包含所有风险、评分和缓解措施的完整表格]
 
-## Risk-Based Testing Strategy
+## 基于风险的测试策略
 
-### Priority 1: Critical Risk Tests
+### 优先级1：严重风险测试
 
-- Test scenarios for critical risks
+-   严重风险的测试场景
-- Required test types (security, load, chaos)
+-   所需的测试类型（安全、负载、混沌）
-- Test data requirements
+-   测试数据要求
 
-### Priority 2: High Risk Tests
+### 优先级2：高风险测试
 
-- Integration test scenarios
+-   集成测试场景
-- Edge case coverage
+-   边缘情况覆盖
 
-### Priority 3: Medium/Low Risk Tests
+### 优先级3：中/低风险测试
 
-- Standard functional tests
+-   标准功能测试
-- Regression test suite
+-   回归测试套件
 
-## Risk Acceptance Criteria
+## 风险接受标准
 
-### Must Fix Before Production
+### 生产前必须修复
 
-- All critical risks (score 9)
+-   所有严重风险（评分9）
-- High risks affecting security/data
+-   影响安全/数据的高风险
 
-### Can Deploy with Mitigation
+### 可以在有缓解措施的情况下部署
 
-- Medium risks with compensating controls
+-   有补偿控制的中等风险
-- Low risks with monitoring in place
+-   有监控的低风险
 
-### Accepted Risks
+### 已接受的风险
 
-- Document any risks team accepts
+-   记录团队接受的任何风险
-- Include sign-off from appropriate authority
+-   包括适当授权的签字
 
-## Monitoring Requirements
+## 监控要求
 
-Post-deployment monitoring for:
+部署后监控：
 
-- Performance metrics for PERF risks
+-   PERF风险的性能指标
-- Security alerts for SEC risks
+-   SEC风险的安全警报
-- Error rates for operational risks
+-   运营风险的错误率
-- Business KPIs for business risks
+-   业务风险的业务KPI
 
-## Risk Review Triggers
+## 风险审查触发器
 
-Review and update risk profile when:
+在以下情况下审查和更新风险概况：
 
-- Architecture changes significantly
+-   架构发生重大变化
-- New integrations added
+-   添加了新的集成
-- Security vulnerabilities discovered
+-   发现了安全漏洞
-- Performance issues reported
+-   报告了性能问题
-- Regulatory requirements change
+-   法规要求变更
 ```
 
-## Risk Scoring Algorithm
+## 风险评分算法
 
-Calculate overall story risk score:
+计算总体故事风险评分：
 
 ```text
-Base Score = 100
+基础分 = 100
-For each risk:
+对于每个风险：
-  - Critical (9): Deduct 20 points
+  - 严重 (9)：扣20分
-  - High (6): Deduct 10 points
+  - 高 (6)：扣10分
-  - Medium (4): Deduct 5 points
+  - 中 (4)：扣5分
-  - Low (2-3): Deduct 2 points
+  - 低 (2-3)：扣2分
 
-Minimum score = 0 (extremely risky)
+最低分 = 0（极度危险）
-Maximum score = 100 (minimal risk)
+最高分 = 100（风险极小）
 ```
 
-## Risk-Based Recommendations
+## 基于风险的建议
 
-Based on risk profile, recommend:
+根据风险概况，建议：
 
-1. **Testing Priority**
+1.  **测试优先级**
-   - Which tests to run first
+    -   首先运行哪些测试
-   - Additional test types needed
+    -   需要哪些额外的测试类型
-   - Test environment requirements
+    -   测试环境要求
 
-2. **Development Focus**
+2.  **开发重点**
-   - Code review emphasis areas
+    -   代码审查重点领域
-   - Additional validation needed
+    -   需要额外的验证
-   - Security controls to implement
+    -   要实施的安全控制
 
-3. **Deployment Strategy**
+3.  **部署策略**
-   - Phased rollout for high-risk changes
+    -   对高风险更改进行分阶段推出
-   - Feature flags for risky features
+    -   对有风险的功能使用功能标志
-   - Rollback procedures
+    -   回滚程序
 
-4. **Monitoring Setup**
+4.  **监控设置**
-   - Metrics to track
+    -   要跟踪的指标
-   - Alerts to configure
+    -   要配置的警报
-   - Dashboard requirements
+    -   仪表板要求
 
-## Integration with Quality Gates
+## 与质量门的集成
 
-**Deterministic gate mapping:**
+**确定性门映射：**
 
-- Any risk with score ≥ 9 → Gate = FAIL (unless waived)
+-   任何风险评分≥9 → 门 = 失败（除非豁免）
-- Else if any score ≥ 6 → Gate = CONCERNS
+-   否则，如果任何评分≥6 → 门 = 关注
-- Else → Gate = PASS
+-   否则 → 门 = 通过
-- Unmitigated risks → Document in gate
+-   未缓解的风险 → 在门中记录
 
-### Output 3: Story Hook Line
+### 输出3：故事钩子行
 
-**Print this line for review task to quote:**
+**打印此行以供审查任务引用：**
 
 ```text
-Risk profile: qa.qaLocation/assessments/{epic}.{story}-risk-{YYYYMMDD}.md
+风险概况：qa.qaLocation/assessments/{epic}.{story}-risk-{YYYYMMDD}.md
 ```
 
-## Key Principles
+## 关键原则
 
-- Identify risks early and systematically
+-   尽早并系统地识别风险
-- Use consistent probability × impact scoring
+-   使用一致的概率×影响评分
-- Provide actionable mitigation strategies
+-   提供可操作的缓解策略
-- Link risks to specific test requirements
+-   将风险与具体的测试要求联系起来
-- Track residual risk after mitigation
+-   跟踪缓解后的剩余风险
-- Update risk profile as story evolves
+-   随着故事的发展更新风险概况

bmad-core/tasks/shard-doc.md

@@ -1,187 +1,187 @@
-<!-- Powered by BMAD™ Core -->
+<!-- 由 BMAD™ Core 驱动 -->
 
-# Document Sharding Task
+# 文档分片任务
 
-## Purpose
+## 目的
 
-- Split a large document into multiple smaller documents based on level 2 sections
+-   根据二级章节将一个大文档分割成多个小文档
-- Create a folder structure to organize the sharded documents
+-   创建一个文件夹结构来组织分片后的文档
-- Maintain all content integrity including code blocks, diagrams, and markdown formatting
+-   保持所有内容的完整性，包括代码块、图表和markdown格式
 
-## Primary Method: Automatic with markdown-tree
+## 主要方法：使用markdown-tree自动进行
 
-[[LLM: First, check if markdownExploder is set to true in {root}/core-config.yaml. If it is, attempt to run the command: `md-tree explode {input file} {output path}`.
+[[LLM: 首先，检查{root}/core-config.yaml中的markdownExploder是否设置为true。如果是，则尝试运行命令：`md-tree explode {input file} {output path}`。
 
-If the command succeeds, inform the user that the document has been sharded successfully and STOP - do not proceed further.
+如果命令成功，请通知用户文档已成功分片并停止 - 不要再继续。
 
-If the command fails (especially with an error indicating the command is not found or not available), inform the user: "The markdownExploder setting is enabled but the md-tree command is not available. Please either:
+如果命令失败（特别是出现命令未找到或不可用的错误），请通知用户：“markdownExploder设置已启用，但md-tree命令不可用。请：
 
-1. Install @kayvan/markdown-tree-parser globally with: `npm install -g @kayvan/markdown-tree-parser`
+1.  使用以下命令全局安装@kayvan/markdown-tree-parser：`npm install -g @kayvan/markdown-tree-parser`
-2. Or set markdownExploder to false in {root}/core-config.yaml
+2.  或者在{root}/core-config.yaml中将markdownExploder设置为false
 
-**IMPORTANT: STOP HERE - do not proceed with manual sharding until one of the above actions is taken.**"
+**重要提示：在此处停止 - 在采取上述操作之一之前，不要继续手动分片。**”
 
-If markdownExploder is set to false, inform the user: "The markdownExploder setting is currently false. For better performance and reliability, you should:
+如果markdownExploder设置为false，请通知用户：“markdownExploder设置当前为false。为了获得更好的性能和可靠性，您应该：
 
-1. Set markdownExploder to true in {root}/core-config.yaml
+1.  在{root}/core-config.yaml中将markdownExploder设置为true
-2. Install @kayvan/markdown-tree-parser globally with: `npm install -g @kayvan/markdown-tree-parser`
+2.  使用以下命令全局安装@kayvan/markdown-tree-parser：`npm install -g @kayvan/markdown-tree-parser`
 
-I will now proceed with the manual sharding process."
+我现在将继续手动分片过程。”
 
-Then proceed with the manual method below ONLY if markdownExploder is false.]]
+然后仅在markdownExploder为false时才继续下面的手动方法。]]
 
-### Installation and Usage
+### 安装和使用
 
-1. **Install globally**:
+1.  **全局安装**：
 
     ```bash
     npm install -g @kayvan/markdown-tree-parser
     ```
 
-2. **Use the explode command**:
+2.  **使用explode命令**：
 
     ```bash
-   # For PRD
+    # 对于PRD
     md-tree explode docs/prd.md docs/prd
 
-   # For Architecture
+    # 对于架构
     md-tree explode docs/architecture.md docs/architecture
 
-   # For any document
+    # 对于任何文档
     md-tree explode [source-document] [destination-folder]
     ```
 
-3. **What it does**:
+3.  **它的作用**：
-   - Automatically splits the document by level 2 sections
+    -   按二级章节自动分割文档
-   - Creates properly named files
+    -   创建正确命名的文件
-   - Adjusts heading levels appropriately
+    -   适当地调整标题级别
-   - Handles all edge cases with code blocks and special markdown
+    -   处理所有带有代码块和特殊markdown的边缘情况
 
-If the user has @kayvan/markdown-tree-parser installed, use it and skip the manual process below.
+如果用户已安装@kayvan/markdown-tree-parser，请使用它并跳过下面的手动过程。
 
 ---
 
-## Manual Method (if @kayvan/markdown-tree-parser is not available or user indicated manual method)
+## 手动方法（如果@kayvan/markdown-tree-parser不可用或用户指示使用手动方法）
 
-### Task Instructions
+### 任务说明
 
-1. Identify Document and Target Location
+1.  识别文档和目标位置
 
-- Determine which document to shard (user-provided path)
+    -   确定要分片的文档（用户提供的路径）
-- Create a new folder under `docs/` with the same name as the document (without extension)
+    -   在`docs/`下创建一个与文档同名的新文件夹（不带扩展名）
-- Example: `docs/prd.md` → create folder `docs/prd/`
+    -   示例：`docs/prd.md` → 创建文件夹 `docs/prd/`
 
-2. Parse and Extract Sections
+2.  解析和提取章节
 
-CRITICAL AEGNT SHARDING RULES:
+关键的代理分片规则：
 
-1. Read the entire document content
+1.  读取整个文档内容
-2. Identify all level 2 sections (## headings)
+2.  识别所有二级章节（## 标题）
-3. For each level 2 section:
+3.  对于每个二级章节：
-   - Extract the section heading and ALL content until the next level 2 section
+    -   提取章节标题和直到下一个二级章节的所有内容
-   - Include all subsections, code blocks, diagrams, lists, tables, etc.
+    -   包括所有子章节、代码块、图表、列表、表格等。
-   - Be extremely careful with:
+    -   要特别小心：
-     - Fenced code blocks (```) - ensure you capture the full block including closing backticks and account for potential misleading level 2's that are actually part of a fenced section example
+        -   围栏代码块（```） - 确保捕获完整的块，包括闭合的反引号，并考虑到实际上是围栏部分示例一部分的潜在误导性二级标题
-     - Mermaid diagrams - preserve the complete diagram syntax
+        -   Mermaid图表 - 保留完整的图表语法
-     - Nested markdown elements
+        -   嵌套的markdown元素
-     - Multi-line content that might contain ## inside code blocks
+        -   可能在代码块中包含##的多行内容
 
-CRITICAL: Use proper parsing that understands markdown context. A ## inside a code block is NOT a section header.]]
+关键：使用能够理解markdown上下文的正确解析。代码块内的##不是章节标题。]]
 
-### 3. Create Individual Files
+### 3. 创建单个文件
 
-For each extracted section:
+对于每个提取的章节：
 
-1. **Generate filename**: Convert the section heading to lowercase-dash-case
+1.  **生成文件名**：将章节标题转换为小写短横线格式
-   - Remove special characters
+    -   删除特殊字符
-   - Replace spaces with dashes
+    -   用短横线替换空格
-   - Example: "## Tech Stack" → `tech-stack.md`
+    -   示例：“## Tech Stack” → `tech-stack.md`
 
-2. **Adjust heading levels**:
+2.  **调整标题级别**：
-   - The level 2 heading becomes level 1 (# instead of ##) in the sharded new document
+    -   在分片的新文档中，二级标题变为一级（# 而不是 ##）
-   - All subsection levels decrease by 1:
+    -   所有子章节级别减1：
 
     ```txt
      - ### → ##
      - #### → ###
      - ##### → ####
-     - etc.
+     - 等等。
     ```
 
-3. **Write content**: Save the adjusted content to the new file
+3.  **写入内容**：将调整后的内容保存到新文件中
 
-### 4. Create Index File
+### 4. 创建索引文件
 
-Create an `index.md` file in the sharded folder that:
+在分片文件夹中创建一个`index.md`文件，该文件：
 
-1. Contains the original level 1 heading and any content before the first level 2 section
+1.  包含原始的一级标题和第一个二级章节之前的任何内容
-2. Lists all the sharded files with links:
+2.  列出所有带有链接的分片文件：
 
 ```markdown
-# Original Document Title
+# 原始文档标题
 
-[Original introduction content if any]
+[原始引言内容，如果有的话]
 
-## Sections
+## 章节
 
-- [Section Name 1](./section-name-1.md)
+- [章节名称 1](./section-name-1.md)
-- [Section Name 2](./section-name-2.md)
+- [章节名称 2](./section-name-2.md)
-- [Section Name 3](./section-name-3.md)
+- [章节名称 3](./section-name-3.md)
   ...
 ```
 
-### 5. Preserve Special Content
+### 5. 保留特殊内容
 
-1. **Code blocks**: Must capture complete blocks including:
+1.  **代码块**：必须捕获完整的块，包括：
 
     ```language
-   content
+    内容
     ```
 
-2. **Mermaid diagrams**: Preserve complete syntax:
+2.  **Mermaid图表**：保留完整的语法：
 
     ```mermaid
     graph TD
     ...
     ```
 
-3. **Tables**: Maintain proper markdown table formatting
+3.  **表格**：保持正确的markdown表格格式
 
-4. **Lists**: Preserve indentation and nesting
+4.  **列表**：保留缩进和嵌套
 
-5. **Inline code**: Preserve backticks
+5.  **内联代码**：保留反引号
 
-6. **Links and references**: Keep all markdown links intact
+6.  **链接和引用**：保持所有markdown链接的完整性
 
-7. **Template markup**: If documents contain {{placeholders}} ,preserve exactly
+7.  **模板标记**：如果文档包含{{占位符}}，请完全保留
 
-### 6. Validation
+### 6. 验证
 
-After sharding:
+分片后：
 
-1. Verify all sections were extracted
+1.  验证所有章节都已提取
-2. Check that no content was lost
+2.  检查没有内容丢失
-3. Ensure heading levels were properly adjusted
+3.  确保标题级别已正确调整
-4. Confirm all files were created successfully
+4.  确认所有文件都已成功创建
 
-### 7. Report Results
+### 7. 报告结果
 
-Provide a summary:
+提供摘要：
 
 ```text
-Document sharded successfully:
+文档分片成功：
-- Source: [original document path]
+- 来源：[原始文档路径]
-- Destination: docs/[folder-name]/
+- 目的地：docs/[文件夹名称]/
-- Files created: [count]
+- 创建的文件：[数量]
-- Sections:
+- 章节：
-  - section-name-1.md: "Section Title 1"
+  - section-name-1.md：“章节标题1”
-  - section-name-2.md: "Section Title 2"
+  - section-name-2.md：“章节标题2”
   ...
 ```
 
-## Important Notes
+## 重要说明
 
-- Never modify the actual content, only adjust heading levels
+-   切勿修改实际内容，只调整标题级别
-- Preserve ALL formatting, including whitespace where significant
+-   保留所有格式，包括重要的空白
-- Handle edge cases like sections with code blocks containing ## symbols
+-   处理包含##符号的代码块等边缘情况
-- Ensure the sharding is reversible (could reconstruct the original from shards)
+-   确保分片是可逆的（可以从分片中重建原始文件）

bmad-core/tasks/test-design.md

@@ -1,137 +1,138 @@
-<!-- Powered by BMAD™ Core -->
+<!-- 由 BMAD™ Core 驱动 -->
 
-# test-design
+# 测试设计
 
-Create comprehensive test scenarios with appropriate test level recommendations for story implementation.
+为故事实施创建具有适当测试级别建议的综合测试场景。
 
-## Inputs
+## 输入
 
 ```yaml
 required:
-  - story_id: '{epic}.{story}' # e.g., "1.3"
+  - story_id: '{epic}.{story}' # 例如, "1.3"
-  - story_path: '{devStoryLocation}/{epic}.{story}.*.md' # Path from core-config.yaml
+  - story_path: '{devStoryLocation}/{epic}.{story}.*.md' # 来自core-config.yaml的路径
-  - story_title: '{title}' # If missing, derive from story file H1
+  - story_title: '{title}' # 如果缺少，则从故事文件的H1派生
-  - story_slug: '{slug}' # If missing, derive from title (lowercase, hyphenated)
+  - story_slug: '{slug}' # 如果缺少，则从标题派生（小写，连字符连接）
 ```
 
-## Purpose
+## 目的
 
-Design a complete test strategy that identifies what to test, at which level (unit/integration/e2e), and why. This ensures efficient test coverage without redundancy while maintaining appropriate test boundaries.
+设计一个完整的测试策略，确定要测试什么，在哪个级别（单元/集成/端到端），以及为什么。这确保了有效的测试覆盖，避免了冗余，同时保持了适当的测试边界。
 
-## Dependencies
+## 依赖
 
 ```yaml
 data:
-  - test-levels-framework.md # Unit/Integration/E2E decision criteria
+  - test-levels-framework.md # 单元/集成/端到端决策标准
-  - test-priorities-matrix.md # P0/P1/P2/P3 classification system
+  - test-priorities-matrix.md # P0/P1/P2/P3分类系统
 ```
 
-## Process
+## 流程
 
-### 1. Analyze Story Requirements
+### 1. 分析故事需求
 
-Break down each acceptance criterion into testable scenarios. For each AC:
+将每个验收标准分解为可测试的场景。对于每个AC：
 
-- Identify the core functionality to test
+-   确定要测试的核心功能
-- Determine data variations needed
+-   确定需要的数据变体
-- Consider error conditions
+-   考虑错误条件
-- Note edge cases
+-   注意边缘情况
 
-### 2. Apply Test Level Framework
+### 2. 应用测试级别框架
 
-**Reference:** Load `test-levels-framework.md` for detailed criteria
+**参考：** 加载`test-levels-framework.md`以获取详细标准
 
-Quick rules:
+**快速规则：**
 
-- **Unit**: Pure logic, algorithms, calculations
+-   **单元**：纯逻辑、算法、计算
-- **Integration**: Component interactions, DB operations
+-   **集成**：组件交互、数据库操作
-- **E2E**: Critical user journeys, compliance
+-   **端到端**：关键用户旅程、合规性
 
-### 3. Assign Priorities
+### 3. 分配优先级
 
-**Reference:** Load `test-priorities-matrix.md` for classification
+**参考：** 加载`test-priorities-matrix.md`进行分类
 
-Quick priority assignment:
+**快速优先级分配：**
 
-- **P0**: Revenue-critical, security, compliance
+-   **P0**：收入关键、安全、合规
-- **P1**: Core user journeys, frequently used
+-   **P1**：核心用户旅程、常用
-- **P2**: Secondary features, admin functions
+-   **P2**：次要功能、管理功能
-- **P3**: Nice-to-have, rarely used
+-   **P3**：锦上添花、很少使用
 
-### 4. Design Test Scenarios
+### 4. 设计测试场景
 
-For each identified test need, create:
+对于每个已识别的测试需求，创建：
 
 ```yaml
 test_scenario:
   id: '{epic}.{story}-{LEVEL}-{SEQ}'
-  requirement: 'AC reference'
+  requirement: 'AC参考'
   priority: P0|P1|P2|P3
   level: unit|integration|e2e
-  description: 'What is being tested'
+  description: '正在测试的内容'
-  justification: 'Why this level was chosen'
+  justification: '为什么选择这个级别'
-  mitigates_risks: ['RISK-001'] # If risk profile exists
+  mitigates_risks: ['RISK-001'] # 如果存在风险概况
 ```
 
-### 5. Validate Coverage
+### 5. 验证覆盖范围
 
-Ensure:
+确保：
 
-- Every AC has at least one test
+-   每个AC至少有一个测试
-- No duplicate coverage across levels
+-   跨级别没有重复的覆盖范围
-- Critical paths have multiple levels
+-   关键路径有多个级别
-- Risk mitigations are addressed
+-   风险缓解措施已得到处理
 
-## Outputs
+## 输出
 
-### Output 1: Test Design Document
+### 输出1：测试设计文档
 
-**Save to:** `qa.qaLocation/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md`
+**保存到：** `qa.qaLocation/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md`
 
 ```markdown
-# Test Design: Story {epic}.{story}
+# 测试设计：故事 {epic}.{story}
 
-Date: {date}
+日期：{date}
-Designer: Quinn (Test Architect)
+设计者：Quinn（测试架构师）
 
-## Test Strategy Overview
+## 测试策略概述
 
-- Total test scenarios: X
+- 总测试场景：X
-- Unit tests: Y (A%)
+- 单元测试：Y (A%)
-- Integration tests: Z (B%)
+- 集成测试：Z (B%)
-- E2E tests: W (C%)
+- 端到端测试：W (C%)
-- Priority distribution: P0: X, P1: Y, P2: Z
+- 优先级分布：P0: X, P1: Y, P2: Z
 
-## Test Scenarios by Acceptance Criteria
+## 按验收标准划分的测试场景
 
-### AC1: {description}
+### AC1：{description}
 
-#### Scenarios
+#### 场景
 
-| ID           | Level       | Priority | Test                      | Justification            |
+| ID | 级别 | 优先级 | 测试 | 理由 |
-| ------------ | ----------- | -------- | ------------------------- | ------------------------ |
+| --- | --- | --- | --- | --- |
-| 1.3-UNIT-001 | Unit        | P0       | Validate input format     | Pure validation logic    |
+| 1.3-UNIT-001 | 单元 | P0 | 验证输入格式 | 纯验证逻辑 |
-| 1.3-INT-001  | Integration | P0       | Service processes request | Multi-component flow     |
+| 1.3-INT-001 | 集成 | P0 | 服务处理请求 | 多组件流程 |
-| 1.3-E2E-001  | E2E         | P1       | User completes journey    | Critical path validation |
+| 1.3-E2E-001 | 端到端 | P1 | 用户完成旅程 | 关键路径验证 |
 
-[Continue for all ACs...]
+[继续所有AC...]
 
-## Risk Coverage
+## 风险覆盖
 
-[Map test scenarios to identified risks if risk profile exists]
+[如果存在风险概况，则将测试场景映射到已识别的风险]
 
-## Recommended Execution Order
+## 推荐的执行顺序
+
+1.  P0单元测试（快速失败）
+2.  P0集成测试
+3.  P0端到端测试
+4.  按顺序执行P1测试
+5.  如果时间允许，则执行P2+
 
-1. P0 Unit tests (fail fast)
-2. P0 Integration tests
-3. P0 E2E tests
-4. P1 tests in order
-5. P2+ as time permits
 ```
 
-### Output 2: Gate YAML Block
+### 输出2：门禁YAML块
 
-Generate for inclusion in quality gate:
+生成以包含在质量门禁中：
 
 ```yaml
 test_design:
@@ -144,33 +145,33 @@ test_design:
     p0: A
     p1: B
     p2: C
-  coverage_gaps: [] # List any ACs without tests
+  coverage_gaps: [] # 列出任何没有测试的AC
 ```
 
-### Output 3: Trace References
+### 输出3：跟踪参考
 
-Print for use by trace-requirements task:
+打印以供trace-requirements任务使用：
 
 ```text
-Test design matrix: qa.qaLocation/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md
+测试设计矩阵：qa.qaLocation/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md
-P0 tests identified: {count}
+已识别的P0测试：{count}
 ```
 
-## Quality Checklist
+## 质量清单
 
-Before finalizing, verify:
+在最终确定之前，验证：
 
-- [ ] Every AC has test coverage
+- [ ] 每个AC都有测试覆盖
-- [ ] Test levels are appropriate (not over-testing)
+- [ ] 测试级别是适当的（没有过度测试）
-- [ ] No duplicate coverage across levels
+- [ ] 跨级别没有重复的覆盖范围
-- [ ] Priorities align with business risk
+- [ ] 优先级与业务风险保持一致
-- [ ] Test IDs follow naming convention
+- [ ] 测试ID遵循命名约定
-- [ ] Scenarios are atomic and independent
+- [ ] 场景是原子的和独立的
 
-## Key Principles
+## 关键原则
 
-- **Shift left**: Prefer unit over integration, integration over E2E
+-   **左移**：优先选择单元测试而非集成测试，集成测试而非端到端测试
-- **Risk-based**: Focus on what could go wrong
+-   **基于风险**：专注于可能出错的地方
-- **Efficient coverage**: Test once at the right level
+-   **有效覆盖**：在正确的级别上测试一次
-- **Maintainability**: Consider long-term test maintenance
+-   **可维护性**：考虑长期的测试维护
-- **Fast feedback**: Quick tests run first
+-   **快速反馈**：首先运行快速测试

bmad-core/tasks/trace-requirements.md

@@ -1,94 +1,94 @@
-<!-- Powered by BMAD™ Core -->
+<!-- 由 BMAD™ Core 驱动 -->
 
-# trace-requirements
+# 跟踪需求
 
-Map story requirements to test cases using Given-When-Then patterns for comprehensive traceability.
+使用Given-When-Then模式将故事需求映射到测试用例，以实现全面的可追溯性。
 
-## Purpose
+## 目的
 
-Create a requirements traceability matrix that ensures every acceptance criterion has corresponding test coverage. This task helps identify gaps in testing and ensures all requirements are validated.
+创建一个需求可追溯性矩阵，确保每个验收标准都有相应的测试覆盖。此任务有助于识别测试中的差距，并确保所有需求都得到验证。
 
-**IMPORTANT**: Given-When-Then is used here for documenting the mapping between requirements and tests, NOT for writing the actual test code. Tests should follow your project's testing standards (no BDD syntax in test code).
+**重要提示**：此处使用Given-When-Then来记录需求和测试之间的映射，而不是编写实际的测试代码。测试应遵循您项目的测试标准（测试代码中不使用BDD语法）。
 
-## Prerequisites
+## 先决条件
 
-- Story file with clear acceptance criteria
+-   具有明确验收标准的故事文件
-- Access to test files or test specifications
+-   访问测试文件或测试规范
-- Understanding of the implementation
+-   理解实现
 
-## Traceability Process
+## 可追溯性流程
 
-### 1. Extract Requirements
+### 1. 提取需求
 
-Identify all testable requirements from:
+从以下来源识别所有可测试的需求：
 
-- Acceptance Criteria (primary source)
+-   验收标准（主要来源）
-- User story statement
+-   用户故事陈述
-- Tasks/subtasks with specific behaviors
+-   具有特定行为的任务/子任务
-- Non-functional requirements mentioned
+-   提到的非功能性需求
-- Edge cases documented
+-   记录的边缘情况
 
-### 2. Map to Test Cases
+### 2. 映射到测试用例
 
-For each requirement, document which tests validate it. Use Given-When-Then to describe what the test validates (not how it's written):
+对于每个需求，记录哪些测试对其进行验证。使用Given-When-Then描述测试验证的内容（而不是如何编写）：
 
 ```yaml
-requirement: 'AC1: User can login with valid credentials'
+requirement: 'AC1：用户可以使用有效凭据登录'
 test_mappings:
   - test_file: 'auth/login.test.ts'
-    test_case: 'should successfully login with valid email and password'
+    test_case: '应该使用有效的电子邮件和密码成功登录'
-    # Given-When-Then describes WHAT the test validates, not HOW it's coded
+    # Given-When-Then描述测试验证的内容，而不是如何编码
-    given: 'A registered user with valid credentials'
+    given: '一个具有有效凭据的注册用户'
-    when: 'They submit the login form'
+    when: '他们提交登录表单'
-    then: 'They are redirected to dashboard and session is created'
+    then: '他们被重定向到仪表板并创建了会话'
     coverage: full
 
   - test_file: 'e2e/auth-flow.test.ts'
-    test_case: 'complete login flow'
+    test_case: '完整的登录流程'
-    given: 'User on login page'
+    given: '用户在登录页面上'
-    when: 'Entering valid credentials and submitting'
+    when: '输入有效凭据并提交'
-    then: 'Dashboard loads with user data'
+    then: '仪表板加载用户数据'
     coverage: integration
 ```
 
-### 3. Coverage Analysis
+### 3. 覆盖率分析
 
-Evaluate coverage for each requirement:
+评估每个需求的覆盖率：
 
-**Coverage Levels:**
+**覆盖级别：**
 
-- `full`: Requirement completely tested
+-   `full`：需求已完全测试
-- `partial`: Some aspects tested, gaps exist
+-   `partial`：部分方面已测试，存在差距
-- `none`: No test coverage found
+-   `none`：未找到测试覆盖
-- `integration`: Covered in integration/e2e tests only
+-   `integration`：仅在集成/端到端测试中覆盖
-- `unit`: Covered in unit tests only
+-   `unit`：仅在单元测试中覆盖
 
-### 4. Gap Identification
+### 4. 差距识别
 
-Document any gaps found:
+记录发现的任何差距：
 
 ```yaml
 coverage_gaps:
-  - requirement: 'AC3: Password reset email sent within 60 seconds'
+  - requirement: 'AC3：密码重置邮件在60秒内发送'
-    gap: 'No test for email delivery timing'
+    gap: '没有测试邮件发送时间'
     severity: medium
     suggested_test:
       type: integration
-      description: 'Test email service SLA compliance'
+      description: '测试邮件服务SLA合规性'
 
-  - requirement: 'AC5: Support 1000 concurrent users'
+  - requirement: 'AC5：支持1000个并发用户'
-    gap: 'No load testing implemented'
+    gap: '未实现负载测试'
     severity: high
     suggested_test:
       type: performance
-      description: 'Load test with 1000 concurrent connections'
+      description: '使用1000个并发连接进行负载测试'
 ```
 
-## Outputs
+## 输出
 
-### Output 1: Gate YAML Block
+### 输出1：门禁YAML块
 
-**Generate for pasting into gate file under `trace`:**
+**生成用于粘贴到门禁文件的`trace`下：**
 
 ```yaml
 trace:
@@ -100,167 +100,167 @@ trace:
   planning_ref: 'qa.qaLocation/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md'
   uncovered:
     - ac: 'AC3'
-      reason: 'No test found for password reset timing'
+      reason: '未找到密码重置时间的测试'
-  notes: 'See qa.qaLocation/assessments/{epic}.{story}-trace-{YYYYMMDD}.md'
+  notes: '参见 qa.qaLocation/assessments/{epic}.{story}-trace-{YYYYMMDD}.md'
 ```
 
-### Output 2: Traceability Report
+### 输出2：可追溯性报告
 
-**Save to:** `qa.qaLocation/assessments/{epic}.{story}-trace-{YYYYMMDD}.md`
+**保存到：** `qa.qaLocation/assessments/{epic}.{story}-trace-{YYYYMMDD}.md`
 
-Create a traceability report with:
+创建具有以下内容的可追溯性报告：
 
 ```markdown
-# Requirements Traceability Matrix
+# 需求可追溯性矩阵
 
-## Story: {epic}.{story} - {title}
+## 故事：{epic}.{story} - {title}
 
-### Coverage Summary
+### 覆盖率摘要
 
-- Total Requirements: X
+- 总需求数：X
-- Fully Covered: Y (Z%)
+- 完全覆盖：Y (Z%)
-- Partially Covered: A (B%)
+- 部分覆盖：A (B%)
-- Not Covered: C (D%)
+- 未覆盖：C (D%)
 
-### Requirement Mappings
+### 需求映射
 
-#### AC1: {Acceptance Criterion 1}
+#### AC1：{验收标准1}
 
-**Coverage: FULL**
+**覆盖率：FULL**
 
-Given-When-Then Mappings:
+Given-When-Then映射：
 
-- **Unit Test**: `auth.service.test.ts::validateCredentials`
+-   **单元测试**：`auth.service.test.ts::validateCredentials`
-  - Given: Valid user credentials
+    -   Given：有效的用户凭据
-  - When: Validation method called
+    -   When：调用验证方法
-  - Then: Returns true with user object
+    -   Then：返回true和用户对象
 
-- **Integration Test**: `auth.integration.test.ts::loginFlow`
+-   **集成测试**：`auth.integration.test.ts::loginFlow`
-  - Given: User with valid account
+    -   Given：具有有效帐户的用户
-  - When: Login API called
+    -   When：调用登录API
-  - Then: JWT token returned and session created
+    -   Then：返回JWT令牌并创建会话
 
-#### AC2: {Acceptance Criterion 2}
+#### AC2：{验收标准2}
 
-**Coverage: PARTIAL**
+**覆盖率：PARTIAL**
 
-[Continue for all ACs...]
+[继续所有AC...]
 
-### Critical Gaps
+### 关键差距
 
-1. **Performance Requirements**
+1.  **性能要求**
-   - Gap: No load testing for concurrent users
+    -   差距：没有针对并发用户的负载测试
-   - Risk: High - Could fail under production load
+    -   风险：高 - 可能在生产负载下失败
-   - Action: Implement load tests using k6 or similar
+    -   措施：使用k6或类似工具实施负载测试
 
-2. **Security Requirements**
+2.  **安全要求**
-   - Gap: Rate limiting not tested
+    -   差距：未测试速率限制
-   - Risk: Medium - Potential DoS vulnerability
+    -   风险：中 - 潜在的DoS漏洞
-   - Action: Add rate limit tests to integration suite
+    -   措施：向集成套件添加速率限制测试
 
-### Test Design Recommendations
+### 测试设计建议
 
-Based on gaps identified, recommend:
+根据发现的差距，建议：
 
-1. Additional test scenarios needed
+1.  需要额外的测试场景
-2. Test types to implement (unit/integration/e2e/performance)
+2.  要实施的测试类型（单元/集成/端到端/性能）
-3. Test data requirements
+3.  测试数据要求
-4. Mock/stub strategies
+4.  模拟/桩策略
 
-### Risk Assessment
+### 风险评估
 
-- **High Risk**: Requirements with no coverage
+-   **高风险**：没有覆盖的需求
-- **Medium Risk**: Requirements with only partial coverage
+-   **中风险**：仅部分覆盖的需求
-- **Low Risk**: Requirements with full unit + integration coverage
+-   **低风险**：具有完整单元+集成覆盖的需求
 ```
 
-## Traceability Best Practices
+## 可追溯性最佳实践
 
-### Given-When-Then for Mapping (Not Test Code)
+### 使用Given-When-Then进行映射（而非测试代码）
 
-Use Given-When-Then to document what each test validates:
+使用Given-When-Then记录每个测试验证的内容：
 
-**Given**: The initial context the test sets up
+**Given**：测试设置的初始上下文
 
-- What state/data the test prepares
+-   测试准备的状态/数据
-- User context being simulated
+-   模拟的用户上下文
-- System preconditions
+-   系统先决条件
 
-**When**: The action the test performs
+**When**：测试执行的操作
 
-- What the test executes
+-   测试执行的内容
-- API calls or user actions tested
+-   测试的API调用或用户操作
-- Events triggered
+-   触发的事件
 
-**Then**: What the test asserts
+**Then**：测试断言的内容
 
-- Expected outcomes verified
+-   验证的预期结果
-- State changes checked
+-   检查的状态更改
-- Values validated
+-   验证的值
 
-**Note**: This is for documentation only. Actual test code follows your project's standards (e.g., describe/it blocks, no BDD syntax).
+**注意**：这仅用于文档记录。实际的测试代码遵循您项目的标准（例如，describe/it块，无BDD语法）。
 
-### Coverage Priority
+### 覆盖优先级
 
-Prioritize coverage based on:
+根据以下内容确定覆盖优先级：
 
-1. Critical business flows
+1.  关键业务流程
-2. Security-related requirements
+2.  与安全相关的需求
-3. Data integrity requirements
+3.  数据完整性需求
-4. User-facing features
+4.  面向用户的功能
-5. Performance SLAs
+5.  性能SLA
 
-### Test Granularity
+### 测试粒度
 
-Map at appropriate levels:
+在适当的级别上进行映射：
 
-- Unit tests for business logic
+-   业务逻辑的单元测试
-- Integration tests for component interaction
+-   组件交互的集成测试
-- E2E tests for user journeys
+-   用户旅程的端到端测试
-- Performance tests for NFRs
+-   NFR的性能测试
 
-## Quality Indicators
+## 质量指标
 
-Good traceability shows:
+良好的可追溯性显示：
 
-- Every AC has at least one test
+-   每个AC至少有一个测试
-- Critical paths have multiple test levels
+-   关键路径有多个测试级别
-- Edge cases are explicitly covered
+-   明确覆盖了边缘情况
-- NFRs have appropriate test types
+-   NFR有适当的测试类型
-- Clear Given-When-Then for each test
+-   每个测试都有清晰的Given-When-Then
 
-## Red Flags
+## 危险信号
 
-Watch for:
+注意：
 
-- ACs with no test coverage
+-   没有测试覆盖的AC
-- Tests that don't map to requirements
+-   未映射到需求的测试
-- Vague test descriptions
+-   模糊的测试描述
-- Missing edge case coverage
+-   缺少边缘情况覆盖
-- NFRs without specific tests
+-   没有特定测试的NFR
 
-## Integration with Gates
+## 与质量门的集成
 
-This traceability feeds into quality gates:
+这种可追溯性为质量门提供信息：
 
-- Critical gaps → FAIL
+-   严重差距 → FAIL
-- Minor gaps → CONCERNS
+-   次要差距 → CONCERNS
-- Missing P0 tests from test-design → CONCERNS
+-   缺少来自test-design的P0测试 → CONCERNS
 
-### Output 3: Story Hook Line
+### 输出3：故事钩子行
 
-**Print this line for review task to quote:**
+**打印此行以供审查任务引用：**
 
 ```text
-Trace matrix: qa.qaLocation/assessments/{epic}.{story}-trace-{YYYYMMDD}.md
+跟踪矩阵：qa.qaLocation/assessments/{epic}.{story}-trace-{YYYYMMDD}.md
 ```
 
-- Full coverage → PASS contribution
+-   完全覆盖 → PASS贡献
 
-## Key Principles
+## 关键原则
 
-- Every requirement must be testable
+-   每个需求都必须是可测试的
-- Use Given-When-Then for clarity
+-   使用Given-When-Then以求清晰
-- Identify both presence and absence
+-   识别存在和缺失
-- Prioritize based on risk
+-   基于风险进行优先级排序
-- Make recommendations actionable
+-   使建议可操作

bmad-core/tasks/validate-next-story.md

@@ -1,136 +1,136 @@
-<!-- Powered by BMAD™ Core -->
+<!-- 由 BMAD™ Core 驱动 -->
 
-# Validate Next Story Task
+# 验证下一个故事任务
 
-## Purpose
+## 目的
 
-To comprehensively validate a story draft before implementation begins, ensuring it is complete, accurate, and provides sufficient context for successful development. This task identifies issues and gaps that need to be addressed, preventing hallucinations and ensuring implementation readiness.
+在实施开始前，全面验证故事草稿，确保其完整、准确，并为成功开发提供足够的上下文。此任务旨在识别需要解决的问题和差距，防止产生幻觉，并确保实施准备就绪。
 
-## SEQUENTIAL Task Execution (Do not proceed until current Task is complete)
+## 顺序任务执行（在当前任务完成前不要继续）
 
-### 0. Load Core Configuration and Inputs
+### 0. 加载核心配置和输入
 
-- Load `.bmad-core/core-config.yaml`
+-   加载 `.bmad-core/core-config.yaml`
-- If the file does not exist, HALT and inform the user: "core-config.yaml not found. This file is required for story validation."
+-   如果文件不存在，则停止并通知用户：“未找到 core-config.yaml。此文件是故事验证所必需的。”
-- Extract key configurations: `devStoryLocation`, `prd.*`, `architecture.*`
+-   提取关键配置：`devStoryLocation`、`prd.*`、`architecture.*`
-- Identify and load the following inputs:
+-   识别并加载以下输入：
-  - **Story file**: The drafted story to validate (provided by user or discovered in `devStoryLocation`)
+    -   **故事文件**：要验证的草稿故事（由用户提供或在`devStoryLocation`中发现）
-  - **Parent epic**: The epic containing this story's requirements
+    -   **父史诗**：包含此故事需求的史诗
-  - **Architecture documents**: Based on configuration (sharded or monolithic)
+    -   **架构文档**：根据配置（分片或单片）
-  - **Story template**: `bmad-core/templates/story-tmpl.md` for completeness validation
+    -   **故事模板**：`bmad-core/templates/story-tmpl.md` 用于完整性验证
 
-### 1. Template Completeness Validation
+### 1. 模板完整性验证
 
-- Load `bmad-core/templates/story-tmpl.md` and extract all section headings from the template
+-   加载 `bmad-core/templates/story-tmpl.md` 并从模板中提取所有章节标题
-- **Missing sections check**: Compare story sections against template sections to verify all required sections are present
+-   **缺失章节检查**：将故事章节与模板章节进行比较，以验证所有必需的章节都存在
-- **Placeholder validation**: Ensure no template placeholders remain unfilled (e.g., `{{EpicNum}}`, `{{role}}`, `_TBD_`)
+-   **占位符验证**：确保没有模板占位符未被填充（例如，`{{EpicNum}}`、`{{role}}`、`_TBD_`）
-- **Agent section verification**: Confirm all sections from template exist for future agent use
+-   **代理章节验证**：确认模板中的所有章节都存在，以供将来的代理使用
-- **Structure compliance**: Verify story follows template structure and formatting
+-   **结构合规性**：验证故事遵循模板结构和格式
 
-### 2. File Structure and Source Tree Validation
+### 2. 文件结构和源代码树验证
 
-- **File paths clarity**: Are new/existing files to be created/modified clearly specified?
+-   **文件路径清晰度**：是否清楚地指定了要创建/修改的新/现有文件？
-- **Source tree relevance**: Is relevant project structure included in Dev Notes?
+-   **源代码树相关性**：开发说明中是否包含相关的项目结构？
-- **Directory structure**: Are new directories/components properly located according to project structure?
+-   **目录结构**：新目录/组件是否根据项目结构正确定位？
-- **File creation sequence**: Do tasks specify where files should be created in logical order?
+-   **文件创建顺序**：任务是否按逻辑顺序列出了应在何处创建文件？
-- **Path accuracy**: Are file paths consistent with project structure from architecture docs?
+-   **路径准确性**：文件路径是否与架构文档中的项目结构一致？
 
-### 3. UI/Frontend Completeness Validation (if applicable)
+### 3. UI/前端完整性验证（如果适用）
 
-- **Component specifications**: Are UI components sufficiently detailed for implementation?
+-   **组件规范**：UI组件的详细程度是否足以进行实施？
-- **Styling/design guidance**: Is visual implementation guidance clear?
+-   **样式/设计指导**：视觉实施指导是否清晰？
-- **User interaction flows**: Are UX patterns and behaviors specified?
+-   **用户交互流程**：是否指定了UX模式和行为？
-- **Responsive/accessibility**: Are these considerations addressed if required?
+-   **响应式/可访问性**：如果需要，是否解决了这些考虑因素？
-- **Integration points**: Are frontend-backend integration points clear?
+-   **集成点**：前后端集成点是否清晰？
 
-### 4. Acceptance Criteria Satisfaction Assessment
+### 4. 验收标准满意度评估
 
-- **AC coverage**: Will all acceptance criteria be satisfied by the listed tasks?
+-   **AC覆盖率**：列出的任务是否能满足所有验收标准？
-- **AC testability**: Are acceptance criteria measurable and verifiable?
+-   **AC可测试性**：验收标准是否可衡量和可验证？
-- **Missing scenarios**: Are edge cases or error conditions covered?
+-   **缺失场景**：是否覆盖了边缘情况或错误条件？
-- **Success definition**: Is "done" clearly defined for each AC?
+-   **成功定义**：是否为每个AC明确定义了“完成”？
-- **Task-AC mapping**: Are tasks properly linked to specific acceptance criteria?
+-   **任务-AC映射**：任务是否正确链接到特定的验收标准？
 
-### 5. Validation and Testing Instructions Review
+### 5. 验证和测试说明审查
 
-- **Test approach clarity**: Are testing methods clearly specified?
+-   **测试方法清晰度**：是否清楚地指定了测试方法？
-- **Test scenarios**: Are key test cases identified?
+-   **测试场景**：是否确定了关键测试用例？
-- **Validation steps**: Are acceptance criteria validation steps clear?
+-   **验证步骤**：验收标准验证步骤是否清晰？
-- **Testing tools/frameworks**: Are required testing tools specified?
+-   **测试工具/框架**：是否指定了所需的测试工具？
-- **Test data requirements**: Are test data needs identified?
+-   **测试数据要求**：是否确定了测试数据需求？
 
-### 6. Security Considerations Assessment (if applicable)
+### 6. 安全考虑评估（如果适用）
 
-- **Security requirements**: Are security needs identified and addressed?
+-   **安全要求**：是否确定并解决了安全需求？
-- **Authentication/authorization**: Are access controls specified?
+-   **认证/授权**：是否指定了访问控制？
-- **Data protection**: Are sensitive data handling requirements clear?
+-   **数据保护**：敏感数据处理要求是否清晰？
-- **Vulnerability prevention**: Are common security issues addressed?
+-   **漏洞预防**：是否解决了常见的安全问题？
-- **Compliance requirements**: Are regulatory/compliance needs addressed?
+-   **合规要求**：是否解决了法规/合规需求？
 
-### 7. Tasks/Subtasks Sequence Validation
+### 7. 任务/子任务顺序验证
 
-- **Logical order**: Do tasks follow proper implementation sequence?
+-   **逻辑顺序**：任务是否遵循正确的实施顺序？
-- **Dependencies**: Are task dependencies clear and correct?
+-   **依赖关系**：任务依赖关系是否清晰正确？
-- **Granularity**: Are tasks appropriately sized and actionable?
+-   **粒度**：任务的大小是否适当且可操作？
-- **Completeness**: Do tasks cover all requirements and acceptance criteria?
+-   **完整性**：任务是否涵盖了所有需求和验收标准？
-- **Blocking issues**: Are there any tasks that would block others?
+-   **阻塞问题**：是否有任何任务会阻塞其他任务？
 
-### 8. Anti-Hallucination Verification
+### 8. 反幻觉验证
 
-- **Source verification**: Every technical claim must be traceable to source documents
+-   **来源验证**：每个技术声明都必须可以追溯到源文档
-- **Architecture alignment**: Dev Notes content matches architecture specifications
+-   **架构对齐**：开发说明内容与架构规范匹配
-- **No invented details**: Flag any technical decisions not supported by source documents
+-   **无杜撰细节**：标记任何不受源文档支持的技术决策
-- **Reference accuracy**: Verify all source references are correct and accessible
+-   **引用准确性**：验证所有源引用是否正确且可访问
-- **Fact checking**: Cross-reference claims against epic and architecture documents
+-   **事实核查**：将声明与史诗和架构文档进行交叉引用
 
-### 9. Dev Agent Implementation Readiness
+### 9. 开发代理实施准备情况
 
-- **Self-contained context**: Can the story be implemented without reading external docs?
+-   **自包含上下文**：无需阅读外部文档即可实施故事吗？
-- **Clear instructions**: Are implementation steps unambiguous?
+-   **清晰的说明**：实施步骤是否明确？
-- **Complete technical context**: Are all required technical details present in Dev Notes?
+-   **完整的技术上下文**：开发说明中是否包含所有必需的技术细节？
-- **Missing information**: Identify any critical information gaps
+-   **信息缺失**：识别任何关键信息差距
-- **Actionability**: Are all tasks actionable by a development agent?
+-   **可操作性**：所有任务是否都可由开发代理操作？
 
-### 10. Generate Validation Report
+### 10. 生成验证报告
 
-Provide a structured validation report including:
+提供结构化的验证报告，包括：
 
-#### Template Compliance Issues
+#### 模板合规性问题
 
-- Missing sections from story template
+-   故事模板中缺失的章节
-- Unfilled placeholders or template variables
+-   未填充的占位符或模板变量
-- Structural formatting issues
+-   结构格式问题
 
-#### Critical Issues (Must Fix - Story Blocked)
+#### 关键问题（必须修复 - 故事受阻）
 
-- Missing essential information for implementation
+-   实施所需的基本信息缺失
-- Inaccurate or unverifiable technical claims
+-   不准确或无法验证的技术声明
-- Incomplete acceptance criteria coverage
+-   验收标准覆盖不完整
-- Missing required sections
+-   缺少必需的章节
 
-#### Should-Fix Issues (Important Quality Improvements)
+#### 应修复问题（重要的质量改进）
 
-- Unclear implementation guidance
+-   不清晰的实施指导
-- Missing security considerations
+-   缺少安全考虑
-- Task sequencing problems
+-   任务排序问题
-- Incomplete testing instructions
+-   不完整的测试说明
 
-#### Nice-to-Have Improvements (Optional Enhancements)
+#### 可有可无的改进（可选增强）
 
-- Additional context that would help implementation
+-   有助于实施的额外上下文
-- Clarifications that would improve efficiency
+-   可以提高效率的澄清说明
-- Documentation improvements
+-   文档改进
 
-#### Anti-Hallucination Findings
+#### 反幻觉发现
 
-- Unverifiable technical claims
+-   无法验证的技术声明
-- Missing source references
+-   缺少来源引用
-- Inconsistencies with architecture documents
+-   与架构文档不一致
-- Invented libraries, patterns, or standards
+-   杜撰的库、模式或标准
 
-#### Final Assessment
+#### 最终评估
 
-- **GO**: Story is ready for implementation
+-   **GO**：故事已准备好实施
-- **NO-GO**: Story requires fixes before implementation
+-   **NO-GO**：故事在实施前需要修复
-- **Implementation Readiness Score**: 1-10 scale
+-   **实施准备就绪分数**：1-10分
-- **Confidence Level**: High/Medium/Low for successful implementation
+-   **成功实施的置信度**：高/中/低

bmad-core/templates/brainstorming-output-tmpl.yaml

@@ -1,11 +1,11 @@
 template:
   id: brainstorming-output-template-v2
-  name: Brainstorming Session Results
+  name: 头脑风暴会议结果
   version: 2.0
   output:
     format: markdown
     filename: docs/brainstorming-session-results.md
-    title: "Brainstorming Session Results"
+    title: "头脑风暴会议结果"
 
 workflow:
   mode: non-interactive
@@ -13,144 +13,144 @@ workflow:
 sections:
   - id: header
     content: |
-      **Session Date:** {{date}}
+      **会议日期：** {{date}}
-      **Facilitator:** {{agent_role}} {{agent_name}}
+      **主持人：** {{agent_role}} {{agent_name}}
-      **Participant:** {{user_name}}
+      **参与者：** {{user_name}}
 
   - id: executive-summary
-    title: Executive Summary
+    title: 执行摘要
     sections:
       - id: summary-details
         template: |
-          **Topic:** {{session_topic}}
+          **主题：** {{session_topic}}
 
-          **Session Goals:** {{stated_goals}}
+          **会议目标：** {{stated_goals}}
 
-          **Techniques Used:** {{techniques_list}}
+          **使用技巧：** {{techniques_list}}
 
-          **Total Ideas Generated:** {{total_ideas}}
+          **产生的总想法数：** {{total_ideas}}
       - id: key-themes
-        title: "Key Themes Identified:"
+        title: "识别出的关键主题："
         type: bullet-list
         template: "- {{theme}}"
 
   - id: technique-sessions
-    title: Technique Sessions
+    title: 技巧会议
     repeatable: true
     sections:
       - id: technique
         title: "{{technique_name}} - {{duration}}"
         sections:
           - id: description
-            template: "**Description:** {{technique_description}}"
+            template: "**描述：** {{technique_description}}"
           - id: ideas-generated
-            title: "Ideas Generated:"
+            title: "产生的想法："
             type: numbered-list
             template: "{{idea}}"
           - id: insights
-            title: "Insights Discovered:"
+            title: "发现的见解："
             type: bullet-list
             template: "- {{insight}}"
           - id: connections
-            title: "Notable Connections:"
+            title: "值得注意的联系："
             type: bullet-list
             template: "- {{connection}}"
 
   - id: idea-categorization
-    title: Idea Categorization
+    title: 想法分类
     sections:
       - id: immediate-opportunities
-        title: Immediate Opportunities
+        title: 即时机会
-        content: "*Ideas ready to implement now*"
+        content: "*现在就可以实施的想法*"
         repeatable: true
         type: numbered-list
         template: |
           **{{idea_name}}**
-          - Description: {{description}}
+          - 描述：{{description}}
-          - Why immediate: {{rationale}}
+          - 为何即时：{{rationale}}
-          - Resources needed: {{requirements}}
+          - 所需资源：{{requirements}}
       - id: future-innovations
-        title: Future Innovations
+        title: 未来创新
-        content: "*Ideas requiring development/research*"
+        content: "*需要开发/研究的想法*"
         repeatable: true
         type: numbered-list
         template: |
           **{{idea_name}}**
-          - Description: {{description}}
+          - 描述：{{description}}
-          - Development needed: {{development_needed}}
+          - 需要的开发：{{development_needed}}
-          - Timeline estimate: {{timeline}}
+          - 时间线估计：{{timeline}}
       - id: moonshots
-        title: Moonshots
+        title: 登月计划
-        content: "*Ambitious, transformative concepts*"
+        content: "*雄心勃勃的、变革性的概念*"
         repeatable: true
         type: numbered-list
         template: |
           **{{idea_name}}**
-          - Description: {{description}}
+          - 描述：{{description}}
-          - Transformative potential: {{potential}}
+          - 变革潜力：{{potential}}
-          - Challenges to overcome: {{challenges}}
+          - 需要克服的挑战：{{challenges}}
       - id: insights-learnings
-        title: Insights & Learnings
+        title: 见解与学习
-        content: "*Key realizations from the session*"
+        content: "*会议中的关键认识*"
         type: bullet-list
         template: "- {{insight}}: {{description_and_implications}}"
 
   - id: action-planning
-    title: Action Planning
+    title: 行动计划
     sections:
       - id: top-priorities
-        title: Top 3 Priority Ideas
+        title: 前3个优先想法
         sections:
           - id: priority-1
-            title: "#1 Priority: {{idea_name}}"
+            title: "#1 优先级：{{idea_name}}"
             template: |
-              - Rationale: {{rationale}}
+              - 理由：{{rationale}}
-              - Next steps: {{next_steps}}
+              - 后续步骤：{{next_steps}}
-              - Resources needed: {{resources}}
+              - 所需资源：{{resources}}
-              - Timeline: {{timeline}}
+              - 时间线：{{timeline}}
           - id: priority-2
-            title: "#2 Priority: {{idea_name}}"
+            title: "#2 优先级：{{idea_name}}"
             template: |
-              - Rationale: {{rationale}}
+              - 理由：{{rationale}}
-              - Next steps: {{next_steps}}
+              - 后续步骤：{{next_steps}}
-              - Resources needed: {{resources}}
+              - 所需资源：{{resources}}
-              - Timeline: {{timeline}}
+              - 时间线：{{timeline}}
           - id: priority-3
-            title: "#3 Priority: {{idea_name}}"
+            title: "#3 优先级：{{idea_name}}"
             template: |
-              - Rationale: {{rationale}}
+              - 理由：{{rationale}}
-              - Next steps: {{next_steps}}
+              - 后续步骤：{{next_steps}}
-              - Resources needed: {{resources}}
+              - 所需资源：{{resources}}
-              - Timeline: {{timeline}}
+              - 时间线：{{timeline}}
 
   - id: reflection-followup
-    title: Reflection & Follow-up
+    title: 反思与跟进
     sections:
       - id: what-worked
-        title: What Worked Well
+        title: 哪些方面做得很好
         type: bullet-list
         template: "- {{aspect}}"
       - id: areas-exploration
-        title: Areas for Further Exploration
+        title: 需要进一步探索的领域
         type: bullet-list
         template: "- {{area}}: {{reason}}"
       - id: recommended-techniques
-        title: Recommended Follow-up Techniques
+        title: 推荐的后续技巧
         type: bullet-list
         template: "- {{technique}}: {{reason}}"
       - id: questions-emerged
-        title: Questions That Emerged
+        title: 出现的问题
         type: bullet-list
         template: "- {{question}}"
       - id: next-session
-        title: Next Session Planning
+        title: 下次会议计划
         template: |
-          - **Suggested topics:** {{followup_topics}}
+          - **建议主题：** {{followup_topics}}
-          - **Recommended timeframe:** {{timeframe}}
+          - **推荐时间范围：** {{timeframe}}
-          - **Preparation needed:** {{preparation}}
+          - **需要准备：** {{preparation}}
 
   - id: footer
     content: |
       ---
 
-      *Session facilitated using the BMAD-METHOD™ brainstorming framework*
+      *会议使用BMAD-METHOD™头脑风暴框架进行*

bmad-core/templates/brownfield-architecture-tmpl.yaml

@@ -1,12 +1,12 @@
-# <!-- Powered by BMAD™ Core -->
+# <!-- 由 BMAD™ Core 驱动 -->
 template:
   id: brownfield-architecture-template-v2
-  name: Brownfield Enhancement Architecture
+  name: 棕地增强架构
   version: 2.0
   output:
     format: markdown
     filename: docs/architecture.md
-    title: "{{project_name}} Brownfield Enhancement Architecture"
+    title: "{{project_name}} 棕地增强架构"
 
 workflow:
   mode: interactive
@@ -14,464 +14,464 @@ workflow:
 
 sections:
   - id: introduction
-    title: Introduction
+    title: 引言
     instruction: |
-      IMPORTANT - SCOPE AND ASSESSMENT REQUIRED:
+      重要 - 需要范围和评估：
 
-      This architecture document is for SIGNIFICANT enhancements to existing projects that require comprehensive architectural planning. Before proceeding:
+      此架构文档适用于需要全面架构规划的现有项目的重大增强。在继续之前：
 
-      1. **Verify Complexity**: Confirm this enhancement requires architectural planning. For simple additions, recommend: "For simpler changes that don't require architectural planning, consider using the brownfield-create-epic or brownfield-create-story task with the Product Owner instead."
+      1. **验证复杂性**：确认此增强需要架构规划。对于简单的添加，建议：“对于不需要架构规划的更简单的更改，请考虑改用产品负责人的 brownfield-create-epic 或 brownfield-create-story 任务。”
 
-      2. **REQUIRED INPUTS**:
+      2. **必需输入**：
-         - Completed brownfield-prd.md
+         - 完成的 brownfield-prd.md
-         - Existing project technical documentation (from docs folder or user-provided)
+         - 现有的项目技术文档（来自 docs 文件夹或用户提供）
-         - Access to existing project structure (IDE or uploaded files)
+         - 对现有项目结构的访问权限（IDE 或上传的文件）
 
-      3. **DEEP ANALYSIS MANDATE**: You MUST conduct thorough analysis of the existing codebase, architecture patterns, and technical constraints before making ANY architectural recommendations. Every suggestion must be based on actual project analysis, not assumptions.
+      3. **深度分析任务**：在提出任何架构建议之前，您必须对现有代码库、架构模式和技术约束进行彻底分析。每个建议都必须基于实际的项目分析，而不是假设。
 
-      4. **CONTINUOUS VALIDATION**: Throughout this process, explicitly validate your understanding with the user. For every architectural decision, confirm: "Based on my analysis of your existing system, I recommend [decision] because [evidence from actual project]. Does this align with your system's reality?"
+      4. **持续验证**：在此过程中，明确地与用户验证您的理解。对于每个架构决策，请确认：“根据我对您现有系统的分析，我建议[决策]，因为[来自实际项目的证据]。这是否符合您系统的实际情况？”
 
-      If any required inputs are missing, request them before proceeding.
+      如果缺少任何必需的输入，请在继续之前请求它们。
     elicit: true
     sections:
       - id: intro-content
         content: |
-          This document outlines the architectural approach for enhancing {{project_name}} with {{enhancement_description}}. Its primary goal is to serve as the guiding architectural blueprint for AI-driven development of new features while ensuring seamless integration with the existing system.
+          本文档概述了使用{{enhancement_description}}增强{{project_name}}的架构方法。其主要目标是作为AI驱动开发新功能的指导性架构蓝图，同时确保与现有系统的无缝集成。
 
-          **Relationship to Existing Architecture:**
+          **与现有架构的关系：**
-          This document supplements existing project architecture by defining how new components will integrate with current systems. Where conflicts arise between new and existing patterns, this document provides guidance on maintaining consistency while implementing enhancements.
+          本文档通过定义新组件如何与当前系统集成来补充现有项目架构。当新旧模式之间出现冲突时，本文档提供了在实施增强功能的同时保持一致性的指导。
       - id: existing-project-analysis
-        title: Existing Project Analysis
+        title: 现有项目分析
         instruction: |
-          Analyze the existing project structure and architecture:
+          分析现有项目结构和架构：
 
-          1. Review existing documentation in docs folder
+          1. 审查 docs 文件夹中的现有文档
-          2. Examine current technology stack and versions
+          2. 检查当前的技术栈和版本
-          3. Identify existing architectural patterns and conventions
+          3. 识别现有的架构模式和约定
-          4. Note current deployment and infrastructure setup
+          4. 注意当前的部署和基础设施设置
-          5. Document any constraints or limitations
+          5. 记录任何约束或限制
 
-          CRITICAL: After your analysis, explicitly validate your findings: "Based on my analysis of your project, I've identified the following about your existing system: [key findings]. Please confirm these observations are accurate before I proceed with architectural recommendations."
+          关键：分析后，明确验证您的发现：“根据我对您项目的分析，我确定了您现有系统的以下几点：[关键发现]。在我提出架构建议之前，请确认这些观察结果是准确的。”
         elicit: true
         sections:
           - id: current-state
-            title: Current Project State
+            title: 当前项目状态
             template: |
-              - **Primary Purpose:** {{existing_project_purpose}}
+              - **主要目的：** {{existing_project_purpose}}
-              - **Current Tech Stack:** {{existing_tech_summary}}
+              - **当前技术栈：** {{existing_tech_summary}}
-              - **Architecture Style:** {{existing_architecture_style}}
+              - **架构风格：** {{existing_architecture_style}}
-              - **Deployment Method:** {{existing_deployment_approach}}
+              - **部署方法：** {{existing_deployment_approach}}
           - id: available-docs
-            title: Available Documentation
+            title: 可用文档
             type: bullet-list
             template: "- {{existing_docs_summary}}"
           - id: constraints
-            title: Identified Constraints
+            title: 已识别的约束
             type: bullet-list
             template: "- {{constraint}}"
       - id: changelog
-        title: Change Log
+        title: 变更日志
         type: table
-        columns: [Change, Date, Version, Description, Author]
+        columns: [变更, 日期, 版本, 描述, 作者]
-        instruction: Track document versions and changes
+        instruction: 跟踪文档版本和变更
 
   - id: enhancement-scope
-    title: Enhancement Scope and Integration Strategy
+    title: 增强范围和集成策略
     instruction: |
-      Define how the enhancement will integrate with the existing system:
+      定义增强功能将如何与现有系统集成：
 
-      1. Review the brownfield PRD enhancement scope
+      1. 审查棕地PRD增强范围
-      2. Identify integration points with existing code
+      2. 识别与现有代码的集成点
-      3. Define boundaries between new and existing functionality
+      3. 定义新旧功能之间的界限
-      4. Establish compatibility requirements
+      4. 建立兼容性要求
 
-      VALIDATION CHECKPOINT: Before presenting the integration strategy, confirm: "Based on my analysis, the integration approach I'm proposing takes into account [specific existing system characteristics]. These integration points and boundaries respect your current architecture patterns. Is this assessment accurate?"
+      验证检查点：在提出集成策略之前，请确认：“根据我的分析，我提出的集成方法考虑了[特定的现有系统特征]。这些集成点和边界尊重您当前的架构模式。此评估是否准确？”
     elicit: true
     sections:
       - id: enhancement-overview
-        title: Enhancement Overview
+        title: 增强概述
         template: |
-          **Enhancement Type:** {{enhancement_type}}
+          **增强类型：** {{enhancement_type}}
-          **Scope:** {{enhancement_scope}}
+          **范围：** {{enhancement_scope}}
-          **Integration Impact:** {{integration_impact_level}}
+          **集成影响：** {{integration_impact_level}}
       - id: integration-approach
-        title: Integration Approach
+        title: 集成方法
         template: |
-          **Code Integration Strategy:** {{code_integration_approach}}
+          **代码集成策略：** {{code_integration_approach}}
-          **Database Integration:** {{database_integration_approach}}
+          **数据库集成：** {{database_integration_approach}}
-          **API Integration:** {{api_integration_approach}}
+          **API集成：** {{api_integration_approach}}
-          **UI Integration:** {{ui_integration_approach}}
+          **UI集成：** {{ui_integration_approach}}
       - id: compatibility-requirements
-        title: Compatibility Requirements
+        title: 兼容性要求
         template: |
-          - **Existing API Compatibility:** {{api_compatibility}}
+          - **现有API兼容性：** {{api_compatibility}}
-          - **Database Schema Compatibility:** {{db_compatibility}}
+          - **数据库模式兼容性：** {{db_compatibility}}
-          - **UI/UX Consistency:** {{ui_compatibility}}
+          - **UI/UX一致性：** {{ui_compatibility}}
-          - **Performance Impact:** {{performance_constraints}}
+          - **性能影响：** {{performance_constraints}}
 
   - id: tech-stack-alignment
-    title: Tech Stack Alignment
+    title: 技术栈对齐
     instruction: |
-      Ensure new components align with existing technology choices:
+      确保新组件与现有技术选择保持一致：
 
-      1. Use existing technology stack as the foundation
+      1. 使用现有技术栈作为基础
-      2. Only introduce new technologies if absolutely necessary
+      2. 仅在绝对必要时才引入新技术
-      3. Justify any new additions with clear rationale
+      3. 用明确的理由证明任何新的添加
-      4. Ensure version compatibility with existing dependencies
+      4. 确保与现有依赖项的版本兼容性
     elicit: true
     sections:
       - id: existing-stack
-        title: Existing Technology Stack
+        title: 现有技术栈
         type: table
-        columns: [Category, Current Technology, Version, Usage in Enhancement, Notes]
+        columns: [类别, 当前技术, 版本, 在增强中的用途, 说明]
-        instruction: Document the current stack that must be maintained or integrated with
+        instruction: 记录必须维护或与之集成的当前技术栈
       - id: new-tech-additions
-        title: New Technology Additions
+        title: 新技术添加
-        condition: Enhancement requires new technologies
+        condition: 增强需要新技术
         type: table
-        columns: [Technology, Version, Purpose, Rationale, Integration Method]
+        columns: [技术, 版本, 目的, 理由, 集成方法]
-        instruction: Only include if new technologies are required for the enhancement
+        instruction: 仅在增强需要新技术时包括
 
   - id: data-models
-    title: Data Models and Schema Changes
+    title: 数据模型和模式更改
     instruction: |
-      Define new data models and how they integrate with existing schema:
+      定义新的数据模型以及它们如何与现有模式集成：
 
-      1. Identify new entities required for the enhancement
+      1. 识别增强所需的新实体
-      2. Define relationships with existing data models
+      2. 定义与现有数据模型的关系
-      3. Plan database schema changes (additions, modifications)
+      3. 规划数据库模式更改（添加、修改）
-      4. Ensure backward compatibility
+      4. 确保向后兼容性
     elicit: true
     sections:
       - id: new-models
-        title: New Data Models
+        title: 新数据模型
         repeatable: true
         sections:
           - id: model
             title: "{{model_name}}"
             template: |
-              **Purpose:** {{model_purpose}}
+              **目的：** {{model_purpose}}
-              **Integration:** {{integration_with_existing}}
+              **集成：** {{integration_with_existing}}
 
-              **Key Attributes:**
+              **关键属性：**
               - {{attribute_1}}: {{type_1}} - {{description_1}}
               - {{attribute_2}}: {{type_2}} - {{description_2}}
 
-              **Relationships:**
+              **关系：**
-              - **With Existing:** {{existing_relationships}}
+              - **与现有：** {{existing_relationships}}
-              - **With New:** {{new_relationships}}
+              - **与新的：** {{new_relationships}}
       - id: schema-integration
-        title: Schema Integration Strategy
+        title: 模式集成策略
         template: |
-          **Database Changes Required:**
+          **所需数据库更改：**
-          - **New Tables:** {{new_tables_list}}
+          - **新表：** {{new_tables_list}}
-          - **Modified Tables:** {{modified_tables_list}}
+          - **修改的表：** {{modified_tables_list}}
-          - **New Indexes:** {{new_indexes_list}}
+          - **新索引：** {{new_indexes_list}}
-          - **Migration Strategy:** {{migration_approach}}
+          - **迁移策略：** {{migration_approach}}
 
-          **Backward Compatibility:**
+          **向后兼容性：**
           - {{compatibility_measure_1}}
           - {{compatibility_measure_2}}
 
   - id: component-architecture
-    title: Component Architecture
+    title: 组件架构
     instruction: |
-      Define new components and their integration with existing architecture:
+      定义新组件及其与现有架构的集成：
 
-      1. Identify new components required for the enhancement
+      1. 识别增强所需的新组件
-      2. Define interfaces with existing components
+      2. 定义与现有组件的接口
-      3. Establish clear boundaries and responsibilities
+      3. 建立清晰的边界和职责
-      4. Plan integration points and data flow
+      4. 规划集成点和数据流
 
-      MANDATORY VALIDATION: Before presenting component architecture, confirm: "The new components I'm proposing follow the existing architectural patterns I identified in your codebase: [specific patterns]. The integration interfaces respect your current component structure and communication patterns. Does this match your project's reality?"
+      强制验证：在提出组件架构之前，请确认：“我提出的新组件遵循我在您代码库中识别出的现有架构模式：[特定模式]。集成接口尊重您当前的组件结构和通信模式。这是否符合您项目的实际情况？”
     elicit: true
     sections:
       - id: new-components
-        title: New Components
+        title: 新组件
         repeatable: true
         sections:
           - id: component
             title: "{{component_name}}"
             template: |
-              **Responsibility:** {{component_description}}
+              **职责：** {{component_description}}
-              **Integration Points:** {{integration_points}}
+              **集成点：** {{integration_points}}
 
-              **Key Interfaces:**
+              **关键接口：**
               - {{interface_1}}
               - {{interface_2}}
 
-              **Dependencies:**
+              **依赖：**
-              - **Existing Components:** {{existing_dependencies}}
+              - **现有组件：** {{existing_dependencies}}
-              - **New Components:** {{new_dependencies}}
+              - **新组件：** {{new_dependencies}}
 
-              **Technology Stack:** {{component_tech_details}}
+              **技术栈：** {{component_tech_details}}
       - id: interaction-diagram
-        title: Component Interaction Diagram
+        title: 组件交互图
         type: mermaid
         mermaid_type: graph
-        instruction: Create Mermaid diagram showing how new components interact with existing ones
+        instruction: 创建Mermaid图，显示新组件如何与现有组件交互
 
   - id: api-design
-    title: API Design and Integration
+    title: API设计和集成
-    condition: Enhancement requires API changes
+    condition: 增强需要API更改
     instruction: |
-      Define new API endpoints and integration with existing APIs:
+      定义新的API端点并与现有API集成：
 
-      1. Plan new API endpoints required for the enhancement
+      1. 规划增强所需的新的API端点
-      2. Ensure consistency with existing API patterns
+      2. 确保与现有API模式的一致性
-      3. Define authentication and authorization integration
+      3. 定义身份验证和授权集成
-      4. Plan versioning strategy if needed
+      4. 如果需要，规划版本控制策略
     elicit: true
     sections:
       - id: api-strategy
-        title: API Integration Strategy
+        title: API集成策略
         template: |
-          **API Integration Strategy:** {{api_integration_strategy}}
+          **API集成策略：** {{api_integration_strategy}}
-          **Authentication:** {{auth_integration}}
+          **身份验证：** {{auth_integration}}
-          **Versioning:** {{versioning_approach}}
+          **版本控制：** {{versioning_approach}}
       - id: new-endpoints
-        title: New API Endpoints
+        title: 新的API端点
         repeatable: true
         sections:
           - id: endpoint
             title: "{{endpoint_name}}"
             template: |
-              - **Method:** {{http_method}}
+              - **方法：** {{http_method}}
-              - **Endpoint:** {{endpoint_path}}
+              - **端点：** {{endpoint_path}}
-              - **Purpose:** {{endpoint_purpose}}
+              - **目的：** {{endpoint_purpose}}
-              - **Integration:** {{integration_with_existing}}
+              - **集成：** {{integration_with_existing}}
             sections:
               - id: request
-                title: Request
+                title: 请求
                 type: code
                 language: json
                 template: "{{request_schema}}"
               - id: response
-                title: Response
+                title: 响应
                 type: code
                 language: json
                 template: "{{response_schema}}"
 
   - id: external-api-integration
-    title: External API Integration
+    title: 外部API集成
-    condition: Enhancement requires new external APIs
+    condition: 增强需要新的外部API
-    instruction: Document new external API integrations required for the enhancement
+    instruction: 记录增强所需的新外部API集成
     repeatable: true
     sections:
       - id: external-api
         title: "{{api_name}} API"
         template: |
-          - **Purpose:** {{api_purpose}}
+          - **目的：** {{api_purpose}}
-          - **Documentation:** {{api_docs_url}}
+          - **文档：** {{api_docs_url}}
-          - **Base URL:** {{api_base_url}}
+          - **基本URL：** {{api_base_url}}
-          - **Authentication:** {{auth_method}}
+          - **身份验证：** {{auth_method}}
-          - **Integration Method:** {{integration_approach}}
+          - **集成方法：** {{integration_approach}}
 
-          **Key Endpoints Used:**
+          **使用的关键端点：**
           - `{{method}} {{endpoint_path}}` - {{endpoint_purpose}}
 
-          **Error Handling:** {{error_handling_strategy}}
+          **错误处理：** {{error_handling_strategy}}
 
   - id: source-tree-integration
-    title: Source Tree Integration
+    title: 源代码树集成
     instruction: |
-      Define how new code will integrate with existing project structure:
+      定义新代码将如何与现有项目结构集成：
 
-      1. Follow existing project organization patterns
+      1. 遵循现有项目组织模式
-      2. Identify where new files/folders will be placed
+      2. 确定新文件/文件夹的放置位置
-      3. Ensure consistency with existing naming conventions
+      3. 确保与现有命名约定的一致性
-      4. Plan for minimal disruption to existing structure
+      4. 规划对现有结构的最小干扰
     elicit: true
     sections:
       - id: existing-structure
-        title: Existing Project Structure
+        title: 现有项目结构
         type: code
         language: plaintext
-        instruction: Document relevant parts of current structure
+        instruction: 记录当前结构的相关部分
         template: "{{existing_structure_relevant_parts}}"
       - id: new-file-organization
-        title: New File Organization
+        title: 新文件组织
         type: code
         language: plaintext
-        instruction: Show only new additions to existing structure
+        instruction: 仅显示对现有结构的新增内容
         template: |
           {{project-root}}/
           ├── {{existing_structure_context}}
           │   ├── {{new_folder_1}}/           # {{purpose_1}}
           │   │   ├── {{new_file_1}}
           │   │   └── {{new_file_2}}
-          │   ├── {{existing_folder}}/        # Existing folder with additions
+          │   ├── {{existing_folder}}/        # 带有新增内容的现有文件夹
-          │   │   ├── {{existing_file}}       # Existing file
+          │   │   ├── {{existing_file}}       # 现有文件
-          │   │   └── {{new_file_3}}          # New addition
+          │   │   └── {{new_file_3}}          # 新增内容
           │   └── {{new_folder_2}}/           # {{purpose_2}}
       - id: integration-guidelines
-        title: Integration Guidelines
+        title: 集成指南
         template: |
-          - **File Naming:** {{file_naming_consistency}}
+          - **文件命名：** {{file_naming_consistency}}
-          - **Folder Organization:** {{folder_organization_approach}}
+          - **文件夹组织：** {{folder_organization_approach}}
-          - **Import/Export Patterns:** {{import_export_consistency}}
+          - **导入/导出模式：** {{import_export_consistency}}
 
   - id: infrastructure-deployment
-    title: Infrastructure and Deployment Integration
+    title: 基础设施和部署集成
     instruction: |
-      Define how the enhancement will be deployed alongside existing infrastructure:
+      定义增强功能将如何与现有基础设施一起部署：
 
-      1. Use existing deployment pipeline and infrastructure
+      1. 使用现有的部署管道和基础设施
-      2. Identify any infrastructure changes needed
+      2. 确定任何需要的基础设施更改
-      3. Plan deployment strategy to minimize risk
+      3. 规划部署策略以最小化风险
-      4. Define rollback procedures
+      4. 定义回滚程序
     elicit: true
     sections:
       - id: existing-infrastructure
-        title: Existing Infrastructure
+        title: 现有基础设施
         template: |
-          **Current Deployment:** {{existing_deployment_summary}}
+          **当前部署：** {{existing_deployment_summary}}
-          **Infrastructure Tools:** {{existing_infrastructure_tools}}
+          **基础设施工具：** {{existing_infrastructure_tools}}
-          **Environments:** {{existing_environments}}
+          **环境：** {{existing_environments}}
       - id: enhancement-deployment
-        title: Enhancement Deployment Strategy
+        title: 增强部署策略
         template: |
-          **Deployment Approach:** {{deployment_approach}}
+          **部署方法：** {{deployment_approach}}
-          **Infrastructure Changes:** {{infrastructure_changes}}
+          **基础设施更改：** {{infrastructure_changes}}
-          **Pipeline Integration:** {{pipeline_integration}}
+          **管道集成：** {{pipeline_integration}}
       - id: rollback-strategy
-        title: Rollback Strategy
+        title: 回滚策略
         template: |
-          **Rollback Method:** {{rollback_method}}
+          **回滚方法：** {{rollback_method}}
-          **Risk Mitigation:** {{risk_mitigation}}
+          **风险缓解：** {{risk_mitigation}}
-          **Monitoring:** {{monitoring_approach}}
+          **监控：** {{monitoring_approach}}
 
   - id: coding-standards
-    title: Coding Standards and Conventions
+    title: 编码标准和约定
     instruction: |
-      Ensure new code follows existing project conventions:
+      确保新代码遵循现有项目约定：
 
-      1. Document existing coding standards from project analysis
+      1. 从项目分析中记录现有编码标准
-      2. Identify any enhancement-specific requirements
+      2. 确定任何特定于增强功能的要求
-      3. Ensure consistency with existing codebase patterns
+      3. 确保与现有代码库模式的一致性
-      4. Define standards for new code organization
+      4. 定义新代码组织的标准
     elicit: true
     sections:
       - id: existing-standards
-        title: Existing Standards Compliance
+        title: 现有标准合规性
         template: |
-          **Code Style:** {{existing_code_style}}
+          **代码风格：** {{existing_code_style}}
-          **Linting Rules:** {{existing_linting}}
+          **Linting规则：** {{existing_linting}}
-          **Testing Patterns:** {{existing_test_patterns}}
+          **测试模式：** {{existing_test_patterns}}
-          **Documentation Style:** {{existing_doc_style}}
+          **文档风格：** {{existing_doc_style}}
       - id: enhancement-standards
-        title: Enhancement-Specific Standards
+        title: 特定于增强功能的标准
-        condition: New patterns needed for enhancement
+        condition: 增强需要新模式
         repeatable: true
         template: "- **{{standard_name}}:** {{standard_description}}"
       - id: integration-rules
-        title: Critical Integration Rules
+        title: 关键集成规则
         template: |
-          - **Existing API Compatibility:** {{api_compatibility_rule}}
+          - **现有API兼容性：** {{api_compatibility_rule}}
-          - **Database Integration:** {{db_integration_rule}}
+          - **数据库集成：** {{db_integration_rule}}
-          - **Error Handling:** {{error_handling_integration}}
+          - **错误处理：** {{error_handling_integration}}
-          - **Logging Consistency:** {{logging_consistency}}
+          - **日志记录一致性：** {{logging_consistency}}
 
   - id: testing-strategy
-    title: Testing Strategy
+    title: 测试策略
     instruction: |
-      Define testing approach for the enhancement:
+      定义增强功能的测试方法：
 
-      1. Integrate with existing test suite
+      1. 与现有测试套件集成
-      2. Ensure existing functionality remains intact
+      2. 确保现有功能保持不变
-      3. Plan for testing new features
+      3. 规划测试新功能
-      4. Define integration testing approach
+      4. 定义集成测试方法
     elicit: true
     sections:
       - id: existing-test-integration
-        title: Integration with Existing Tests
+        title: 与现有测试集成
         template: |
-          **Existing Test Framework:** {{existing_test_framework}}
+          **现有测试框架：** {{existing_test_framework}}
-          **Test Organization:** {{existing_test_organization}}
+          **测试组织：** {{existing_test_organization}}
-          **Coverage Requirements:** {{existing_coverage_requirements}}
+          **覆盖率要求：** {{existing_coverage_requirements}}
       - id: new-testing
-        title: New Testing Requirements
+        title: 新的测试要求
         sections:
           - id: unit-tests
-            title: Unit Tests for New Components
+            title: 新组件的单元测试
             template: |
-              - **Framework:** {{test_framework}}
+              - **框架：** {{test_framework}}
-              - **Location:** {{test_location}}
+              - **位置：** {{test_location}}
-              - **Coverage Target:** {{coverage_target}}
+              - **覆盖目标：** {{coverage_target}}
-              - **Integration with Existing:** {{test_integration}}
+              - **与现有集成：** {{test_integration}}
           - id: integration-tests
-            title: Integration Tests
+            title: 集成测试
             template: |
-              - **Scope:** {{integration_test_scope}}
+              - **范围：** {{integration_test_scope}}
-              - **Existing System Verification:** {{existing_system_verification}}
+              - **现有系统验证：** {{existing_system_verification}}
-              - **New Feature Testing:** {{new_feature_testing}}
+              - **新功能测试：** {{new_feature_testing}}
           - id: regression-tests
-            title: Regression Testing
+            title: 回归测试
             template: |
-              - **Existing Feature Verification:** {{regression_test_approach}}
+              - **现有功能验证：** {{regression_test_approach}}
-              - **Automated Regression Suite:** {{automated_regression}}
+              - **自动化回归套件：** {{automated_regression}}
-              - **Manual Testing Requirements:** {{manual_testing_requirements}}
+              - **手动测试要求：** {{manual_testing_requirements}}
 
   - id: security-integration
-    title: Security Integration
+    title: 安全集成
     instruction: |
-      Ensure security consistency with existing system:
+      确保与现有系统的安全一致性：
 
-      1. Follow existing security patterns and tools
+      1. 遵循现有的安全模式和工具
-      2. Ensure new features don't introduce vulnerabilities
+      2. 确保新功能不引入漏洞
-      3. Maintain existing security posture
+      3. 保持现有的安全态势
-      4. Define security testing for new components
+      4. 为新组件定义安全测试
     elicit: true
     sections:
       - id: existing-security
-        title: Existing Security Measures
+        title: 现有安全措施
         template: |
-          **Authentication:** {{existing_auth}}
+          **身份验证：** {{existing_auth}}
-          **Authorization:** {{existing_authz}}
+          **授权：** {{existing_authz}}
-          **Data Protection:** {{existing_data_protection}}
+          **数据保护：** {{existing_data_protection}}
-          **Security Tools:** {{existing_security_tools}}
+          **安全工具：** {{existing_security_tools}}
       - id: enhancement-security
-        title: Enhancement Security Requirements
+        title: 增强安全要求
         template: |
-          **New Security Measures:** {{new_security_measures}}
+          **新安全措施：** {{new_security_measures}}
-          **Integration Points:** {{security_integration_points}}
+          **集成点：** {{security_integration_points}}
-          **Compliance Requirements:** {{compliance_requirements}}
+          **合规要求：** {{compliance_requirements}}
       - id: security-testing
-        title: Security Testing
+        title: 安全测试
         template: |
-          **Existing Security Tests:** {{existing_security_tests}}
+          **现有安全测试：** {{existing_security_tests}}
-          **New Security Test Requirements:** {{new_security_tests}}
+          **新安全测试要求：** {{new_security_tests}}
-          **Penetration Testing:** {{pentest_requirements}}
+          **渗透测试：** {{pentest_requirements}}
 
   - id: checklist-results
-    title: Checklist Results Report
+    title: 清单结果报告
-    instruction: Execute the architect-checklist and populate results here, focusing on brownfield-specific validation
+    instruction: 执行architect-checklist并在此处填充结果，重点关注特定于棕地的验证
 
   - id: next-steps
-    title: Next Steps
+    title: 下一步
     instruction: |
-      After completing the brownfield architecture:
+      完成棕地架构后：
 
-      1. Review integration points with existing system
+      1. 审查与现有系统的集成点
-      2. Begin story implementation with Dev agent
+      2. 与开发代理一起开始故事实施
-      3. Set up deployment pipeline integration
+      3. 设置部署管道集成
-      4. Plan rollback and monitoring procedures
+      4. 规划回滚和监控程序
     sections:
       - id: story-manager-handoff
-        title: Story Manager Handoff
+        title: 故事管理员交接
         instruction: |
-          Create a brief prompt for Story Manager to work with this brownfield enhancement. Include:
+          为此棕地增强创建一个简短的提示，以便与故事管理员一起工作。包括：
-          - Reference to this architecture document
+          - 对此架构文档的引用
-          - Key integration requirements validated with user
+          - 与用户验证的关键集成要求
-          - Existing system constraints based on actual project analysis
+          - 基于实际项目分析的现有系统约束
-          - First story to implement with clear integration checkpoints
+          - 第一个要实施的故事，并带有清晰的集成检查点
-          - Emphasis on maintaining existing system integrity throughout implementation
+          - 强调在整个实施过程中保持现有系统的完整性
       - id: developer-handoff
-        title: Developer Handoff
+        title: 开发人员交接
         instruction: |
-          Create a brief prompt for developers starting implementation. Include:
+          为开始实施的开发人员创建一个简短的提示。包括：
-          - Reference to this architecture and existing coding standards analyzed from actual project
+          - 对此架构和从实际项目中分析的现有编码标准的引用
-          - Integration requirements with existing codebase validated with user
+          - 与用户验证的与现有代码库的集成要求
-          - Key technical decisions based on real project constraints
+          - 基于真实项目约束的关键技术决策
-          - Existing system compatibility requirements with specific verification steps
+          - 具有特定验证步骤的现有系统兼容性要求
-          - Clear sequencing of implementation to minimize risk to existing functionality
+          - 清晰的实施顺序，以最小化对现有功能的风险

bmad-core/templates/brownfield-prd-tmpl.yaml

@@ -1,12 +1,12 @@
-# <!-- Powered by BMAD™ Core -->
+# <!-- 由 BMAD™ Core 驱动 -->
 template:
   id: brownfield-prd-template-v2
-  name: Brownfield Enhancement PRD
+  name: 棕地增强PRD
   version: 2.0
   output:
     format: markdown
     filename: docs/prd.md
-    title: "{{project_name}} Brownfield Enhancement PRD"
+    title: "{{project_name}} 棕地增强PRD"
 
 workflow:
   mode: interactive
@@ -14,133 +14,133 @@ workflow:
 
 sections:
   - id: intro-analysis
-    title: Intro Project Analysis and Context
+    title: 引言项目分析和背景
     instruction: |
-      IMPORTANT - SCOPE ASSESSMENT REQUIRED:
+      重要 - 需要范围评估：
 
-      This PRD is for SIGNIFICANT enhancements to existing projects that require comprehensive planning and multiple stories. Before proceeding:
+      此PRD适用于需要全面规划和多个故事的现有项目的重大增强。在继续之前：
 
-      1. **Assess Enhancement Complexity**: If this is a simple feature addition or bug fix that could be completed in 1-2 focused development sessions, STOP and recommend: "For simpler changes, consider using the brownfield-create-epic or brownfield-create-story task with the Product Owner instead. This full PRD process is designed for substantial enhancements that require architectural planning and multiple coordinated stories."
+      1. **评估增强复杂性**：如果这是一个简单的功能添加或错误修复，可以在1-2个专注的开发会话中完成，请停止并建议：“对于更简单的更改，请考虑改用产品负责人的brownfield-create-epic或brownfield-create-story任务。这个完整的PRD流程是为需要架构规划和多个协调故事的重大增强而设计的。”
 
-      2. **Project Context**: Determine if we're working in an IDE with the project already loaded or if the user needs to provide project information. If project files are available, analyze existing documentation in the docs folder. If insufficient documentation exists, recommend running the document-project task first.
+      2. **项目背景**：确定我们是在已加载项目的IDE中工作，还是需要用户提供项目信息。如果项目文件可用，请分析docs文件夹中的现有文档。如果文档不足，建议首先运行document-project任务。
 
-      3. **Deep Assessment Requirement**: You MUST thoroughly analyze the existing project structure, patterns, and constraints before making ANY suggestions. Every recommendation must be grounded in actual project analysis, not assumptions.
+      3. **深度评估要求**：在提出任何建议之前，您必须彻底分析现有的项目结构、模式和约束。每个建议都必须基于实际的项目分析，而不是假设。
 
-      Gather comprehensive information about the existing project. This section must be completed before proceeding with requirements.
+      收集有关现有项目的全面信息。在继续进行需求之前，必须完成此部分。
 
-      CRITICAL: Throughout this analysis, explicitly confirm your understanding with the user. For every assumption you make about the existing project, ask: "Based on my analysis, I understand that [assumption]. Is this correct?"
+      关键：在此分析过程中，明确地与用户确认您的理解。对于您对现有项目做出的每个假设，请询问：“根据我的分析，我了解到[假设]。这是否正确？”
 
-      Do not proceed with any recommendations until the user has validated your understanding of the existing system.
+      在用户验证您对现有系统的理解之前，不要继续提出任何建议。
     sections:
       - id: existing-project-overview
-        title: Existing Project Overview
+        title: 现有项目概述
-        instruction: Check if document-project analysis was already performed. If yes, reference that output instead of re-analyzing.
+        instruction: 检查是否已执行document-project分析。如果是，请引用该输出而不是重新分析。
         sections:
           - id: analysis-source
-            title: Analysis Source
+            title: 分析来源
             instruction: |
-              Indicate one of the following:
+              指出以下之一：
-              - Document-project output available at: {{path}}
+              - document-project输出位于：{{path}}
-              - IDE-based fresh analysis
+              - 基于IDE的全新分析
-              - User-provided information
+              - 用户提供的信息
           - id: current-state
-            title: Current Project State
+            title: 当前项目状态
             instruction: |
-              - If document-project output exists: Extract summary from "High Level Architecture" and "Technical Summary" sections
+              - 如果存在document-project输出：从“高层架构”和“技术摘要”部分提取摘要
-              - Otherwise: Brief description of what the project currently does and its primary purpose
+              - 否则：简要描述项目当前的功能及其主要目的
       - id: documentation-analysis
-        title: Available Documentation Analysis
+        title: 可用文档分析
         instruction: |
-          If document-project was run:
+          如果已运行document-project：
-          - Note: "Document-project analysis available - using existing technical documentation"
+          - 注意：“可用的document-project分析 - 使用现有的技术文档”
-          - List key documents created by document-project
+          - 列出document-project创建的关键文档
-          - Skip the missing documentation check below
+          - 跳过下面的缺失文档检查
 
-          Otherwise, check for existing documentation:
+          否则，检查现有文档：
         sections:
           - id: available-docs
-            title: Available Documentation
+            title: 可用文档
             type: checklist
             items:
-              - Tech Stack Documentation [[LLM: If from document-project, check ✓]]
+              - 技术栈文档 [[LLM: 如果来自document-project，请勾选 ✓]]
-              - Source Tree/Architecture [[LLM: If from document-project, check ✓]]
+              - 源代码树/架构 [[LLM: 如果来自document-project，请勾选 ✓]]
-              - Coding Standards [[LLM: If from document-project, may be partial]]
+              - 编码标准 [[LLM: 如果来自document-project，可能不完整]]
-              - API Documentation [[LLM: If from document-project, check ✓]]
+              - API文档 [[LLM: 如果来自document-project，请勾选 ✓]]
-              - External API Documentation [[LLM: If from document-project, check ✓]]
+              - 外部API文档 [[LLM: 如果来自document-project，请勾选 ✓]]
-              - UX/UI Guidelines [[LLM: May not be in document-project]]
+              - UX/UI指南 [[LLM: 可能不在document-project中]]
-              - Technical Debt Documentation [[LLM: If from document-project, check ✓]]
+              - 技术债务文档 [[LLM: 如果来自document-project，请勾选 ✓]]
-              - "Other: {{other_docs}}"
+              - "其他：{{other_docs}}"
             instruction: |
-              - If document-project was already run: "Using existing project analysis from document-project output."
+              - 如果已运行document-project：“使用来自document-project输出的现有项目分析。”
-              - If critical documentation is missing and no document-project: "I recommend running the document-project task first..."
+              - 如果缺少关键文档且没有document-project：“我建议首先运行document-project任务...”
       - id: enhancement-scope
-        title: Enhancement Scope Definition
+        title: 增强范围定义
-        instruction: Work with user to clearly define what type of enhancement this is. This is critical for scoping and approach.
+        instruction: 与用户合作，明确定义这是哪种类型的增强。这对于范围界定和方法至关重要。
         sections:
           - id: enhancement-type
-            title: Enhancement Type
+            title: 增强类型
             type: checklist
-            instruction: Determine with user which applies
+            instruction: 与用户确定适用哪种
             items:
-              - New Feature Addition
+              - 新功能添加
-              - Major Feature Modification
+              - 主要功能修改
-              - Integration with New Systems
+              - 与新系统集成
-              - Performance/Scalability Improvements
+              - 性能/可扩展性改进
-              - UI/UX Overhaul
+              - UI/UX大修
-              - Technology Stack Upgrade
+              - 技术栈升级
-              - Bug Fix and Stability Improvements
+              - 错误修复和稳定性改进
-              - "Other: {{other_type}}"
+              - "其他：{{other_type}}"
           - id: enhancement-description
-            title: Enhancement Description
+            title: 增强描述
-            instruction: 2-3 sentences describing what the user wants to add or change
+            instruction: 2-3句话描述用户想要添加或更改的内容
           - id: impact-assessment
-            title: Impact Assessment
+            title: 影响评估
             type: checklist
-            instruction: Assess the scope of impact on existing codebase
+            instruction: 评估对现有代码库的影响范围
             items:
-              - Minimal Impact (isolated additions)
+              - 最小影响（孤立的添加）
-              - Moderate Impact (some existing code changes)
+              - 中等影响（一些现有代码更改）
-              - Significant Impact (substantial existing code changes)
+              - 重大影响（大量的现有代码更改）
-              - Major Impact (architectural changes required)
+              - 主要影响（需要架构更改）
       - id: goals-context
-        title: Goals and Background Context
+        title: 目标和背景
         sections:
           - id: goals
-            title: Goals
+            title: 目标
             type: bullet-list
-            instruction: Bullet list of 1-line desired outcomes this enhancement will deliver if successful
+            instruction: 如果成功，此增强将带来的一行所需结果的要点列表
           - id: background
-            title: Background Context
+            title: 背景
             type: paragraphs
-            instruction: 1-2 short paragraphs explaining why this enhancement is needed, what problem it solves, and how it fits with the existing project
+            instruction: 1-2个简短段落，解释为什么需要此增强，它解决了什么问题，以及它如何与现有项目相适应
       - id: changelog
-        title: Change Log
+        title: 变更日志
         type: table
-        columns: [Change, Date, Version, Description, Author]
+        columns: [变更, 日期, 版本, 描述, 作者]
 
   - id: requirements
-    title: Requirements
+    title: 需求
     instruction: |
-      Draft functional and non-functional requirements based on your validated understanding of the existing project. Before presenting requirements, confirm: "These requirements are based on my understanding of your existing system. Please review carefully and confirm they align with your project's reality."
+      根据您对现有项目的已验证理解，起草功能性和非功能性需求。在提出需求之前，请确认：“这些需求是基于我对您现有系统的理解。请仔细审查并确认它们与您项目的实际情况相符。”
     elicit: true
     sections:
       - id: functional
-        title: Functional
+        title: 功能性
         type: numbered-list
         prefix: FR
-        instruction: Each Requirement will be a bullet markdown with identifier starting with FR
+        instruction: 每个需求都将是一个以FR开头的markdown项目符号
         examples:
-          - "FR1: The existing Todo List will integrate with the new AI duplicate detection service without breaking current functionality."
+          - "FR1：现有的待办事项列表将与新的人工智能重复检测服务集成，而不会破坏当前功能。"
       - id: non-functional
-        title: Non Functional
+        title: 非功能性
         type: numbered-list
         prefix: NFR
-        instruction: Each Requirement will be a bullet markdown with identifier starting with NFR. Include constraints from existing system
+        instruction: 每个需求都将是一个以NFR开头的markdown项目符号。包括来自现有系统的约束
         examples:
-          - "NFR1: Enhancement must maintain existing performance characteristics and not exceed current memory usage by more than 20%."
+          - "NFR1：增强功能必须保持现有的性能特征，并且内存使用量不超过当前的20%。"
       - id: compatibility
-        title: Compatibility Requirements
+        title: 兼容性要求
-        instruction: Critical for brownfield - what must remain compatible
+        instruction: 对于棕地项目至关重要 - 必须保持兼容的内容
         type: numbered-list
         prefix: CR
         template: "{{requirement}}: {{description}}"
@@ -155,124 +155,124 @@ sections:
             template: "CR4: {{integration_compatibility}}"
 
   - id: ui-enhancement-goals
-    title: User Interface Enhancement Goals
+    title: 用户界面增强目标
-    condition: Enhancement includes UI changes
+    condition: 增强包括UI更改
-    instruction: For UI changes, capture how they will integrate with existing UI patterns and design systems
+    instruction: 对于UI更改，捕获它们将如何与现有的UI模式和设计系统集成
     sections:
       - id: existing-ui-integration
-        title: Integration with Existing UI
+        title: 与现有UI集成
-        instruction: Describe how new UI elements will fit with existing design patterns, style guides, and component libraries
+        instruction: 描述新的UI元素将如何适应现有的设计模式、样式指南和组件库
       - id: modified-screens
-        title: Modified/New Screens and Views
+        title: 修改/新屏幕和视图
-        instruction: List only the screens/views that will be modified or added
+        instruction: 仅列出将要修改或添加的屏幕/视图
       - id: ui-consistency
-        title: UI Consistency Requirements
+        title: UI一致性要求
-        instruction: Specific requirements for maintaining visual and interaction consistency with existing application
+        instruction: 保持与现有应用程序的视觉和交互一致性的具体要求
 
   - id: technical-constraints
-    title: Technical Constraints and Integration Requirements
+    title: 技术约束和集成要求
-    instruction: This section replaces separate architecture documentation. Gather detailed technical constraints from existing project analysis.
+    instruction: 本节取代单独的架构文档。从现有项目分析中收集详细的技术约束。
     sections:
       - id: existing-tech-stack
-        title: Existing Technology Stack
+        title: 现有技术栈
         instruction: |
-          If document-project output available:
+          如果document-project输出可用：
-          - Extract from "Actual Tech Stack" table in High Level Architecture section
+          - 从高层架构部分的“实际技术栈”表中提取
-          - Include version numbers and any noted constraints
+          - 包括版本号和任何注意到的约束
 
-          Otherwise, document the current technology stack:
+          否则，记录当前的技术栈：
         template: |
-          **Languages**: {{languages}}
+          **语言**：{{languages}}
-          **Frameworks**: {{frameworks}}
+          **框架**：{{frameworks}}
-          **Database**: {{database}}
+          **数据库**：{{database}}
-          **Infrastructure**: {{infrastructure}}
+          **基础设施**：{{infrastructure}}
-          **External Dependencies**: {{external_dependencies}}
+          **外部依赖**：{{external_dependencies}}
       - id: integration-approach
-        title: Integration Approach
+        title: 集成方法
-        instruction: Define how the enhancement will integrate with existing architecture
+        instruction: 定义增强功能将如何与现有架构集成
         template: |
-          **Database Integration Strategy**: {{database_integration}}
+          **数据库集成策略**：{{database_integration}}
-          **API Integration Strategy**: {{api_integration}}
+          **API集成策略**：{{api_integration}}
-          **Frontend Integration Strategy**: {{frontend_integration}}
+          **前端集成策略**：{{frontend_integration}}
-          **Testing Integration Strategy**: {{testing_integration}}
+          **测试集成策略**：{{testing_integration}}
       - id: code-organization
-        title: Code Organization and Standards
+        title: 代码组织和标准
-        instruction: Based on existing project analysis, define how new code will fit existing patterns
+        instruction: 基于现有项目分析，定义新代码将如何适应现有模式
         template: |
-          **File Structure Approach**: {{file_structure}}
+          **文件结构方法**：{{file_structure}}
-          **Naming Conventions**: {{naming_conventions}}
+          **命名约定**：{{naming_conventions}}
-          **Coding Standards**: {{coding_standards}}
+          **编码标准**：{{coding_standards}}
-          **Documentation Standards**: {{documentation_standards}}
+          **文档标准**：{{documentation_standards}}
       - id: deployment-operations
-        title: Deployment and Operations
+        title: 部署和运营
-        instruction: How the enhancement fits existing deployment pipeline
+        instruction: 增强功能如何适应现有的部署管道
         template: |
-          **Build Process Integration**: {{build_integration}}
+          **构建过程集成**：{{build_integration}}
-          **Deployment Strategy**: {{deployment_strategy}}
+          **部署策略**：{{deployment_strategy}}
-          **Monitoring and Logging**: {{monitoring_logging}}
+          **监控和日志记录**：{{monitoring_logging}}
-          **Configuration Management**: {{config_management}}
+          **配置管理**：{{config_management}}
       - id: risk-assessment
-        title: Risk Assessment and Mitigation
+        title: 风险评估和缓解
         instruction: |
-          If document-project output available:
+          如果document-project输出可用：
-          - Reference "Technical Debt and Known Issues" section
+          - 引用“技术债务和已知问题”部分
-          - Include "Workarounds and Gotchas" that might impact enhancement
+          - 包括可能影响增强功能的“变通方法和陷阱”
-          - Note any identified constraints from "Critical Technical Debt"
+          - 注意从“关键技术债务”中识别出的任何约束
 
-          Build risk assessment incorporating existing known issues:
+          结合现有的已知问题进行风险评估：
         template: |
-          **Technical Risks**: {{technical_risks}}
+          **技术风险**：{{technical_risks}}
-          **Integration Risks**: {{integration_risks}}
+          **集成风险**：{{integration_risks}}
-          **Deployment Risks**: {{deployment_risks}}
+          **部署风险**：{{deployment_risks}}
-          **Mitigation Strategies**: {{mitigation_strategies}}
+          **缓解策略**：{{mitigation_strategies}}
 
   - id: epic-structure
-    title: Epic and Story Structure
+    title: 史诗和故事结构
     instruction: |
-      For brownfield projects, favor a single comprehensive epic unless the user is clearly requesting multiple unrelated enhancements. Before presenting the epic structure, confirm: "Based on my analysis of your existing project, I believe this enhancement should be structured as [single epic/multiple epics] because [rationale based on actual project analysis]. Does this align with your understanding of the work required?"
+      对于棕地项目，除非用户明确要求多个不相关的增强功能，否则倾向于使用单个综合史诗。在提出史诗结构之前，请确认：“根据我对您现有项目的分析，我认为此增强功能应构建为[单个史诗/多个史诗]，因为[基于实际项目分析的理由]。这是否符合您对所需工作的理解？”
     elicit: true
     sections:
       - id: epic-approach
-        title: Epic Approach
+        title: 史诗方法
-        instruction: Explain the rationale for epic structure - typically single epic for brownfield unless multiple unrelated features
+        instruction: 解释史诗结构的理由 - 通常对于棕地项目是单个史诗，除非有多个不相关的功能
-        template: "**Epic Structure Decision**: {{epic_decision}} with rationale"
+        template: "**史诗结构决策**：{{epic_decision}}，并附上理由"
 
   - id: epic-details
-    title: "Epic 1: {{enhancement_title}}"
+    title: "史诗1：{{enhancement_title}}"
     instruction: |
-      Comprehensive epic that delivers the brownfield enhancement while maintaining existing functionality
+      提供棕地增强功能的综合史诗，同时保持现有功能
 
-      CRITICAL STORY SEQUENCING FOR BROWNFIELD:
+      棕地项目的关键故事排序：
-      - Stories must ensure existing functionality remains intact
+      - 故事必须确保现有功能保持不变
-      - Each story should include verification that existing features still work
+      - 每个故事都应包括对现有功能仍然有效的验证
-      - Stories should be sequenced to minimize risk to existing system
+      - 故事应按顺序排列，以最小化对现有系统的风险
-      - Include rollback considerations for each story
+      - 为每个故事包括回滚考虑
-      - Focus on incremental integration rather than big-bang changes
+      - 专注于增量集成而不是一次性集成
-      - Size stories for AI agent execution in existing codebase context
+      - 在现有代码库上下文中为AI代理执行确定故事的大小
-      - MANDATORY: Present the complete story sequence and ask: "This story sequence is designed to minimize risk to your existing system. Does this order make sense given your project's architecture and constraints?"
+      - 强制性：提出完整的故事序列，并询问：“这个故事序列旨在最小化对您现有系统的风险。鉴于您项目的架构和约束，这个顺序是否合理？”
-      - Stories must be logically sequential with clear dependencies identified
+      - 故事必须在逻辑上是连续的，并明确识别出依赖关系
-      - Each story must deliver value while maintaining system integrity
+      - 每个故事都必须在保持系统完整性的同时交付价值
     template: |
-      **Epic Goal**: {{epic_goal}}
+      **史诗目标**：{{epic_goal}}
 
-      **Integration Requirements**: {{integration_requirements}}
+      **集成要求**：{{integration_requirements}}
     sections:
       - id: story
-        title: "Story 1.{{story_number}} {{story_title}}"
+        title: "故事1.{{story_number}} {{story_title}}"
         repeatable: true
         template: |
-          As a {{user_type}},
+          作为一个{{user_type}}，
-          I want {{action}},
+          我想要{{action}}，
-          so that {{benefit}}.
+          以便{{benefit}}。
         sections:
           - id: acceptance-criteria
-            title: Acceptance Criteria
+            title: 验收标准
             type: numbered-list
-            instruction: Define criteria that include both new functionality and existing system integrity
+            instruction: 定义既包括新功能又包括现有系统完整性的标准
             item_template: "{{criterion_number}}: {{criteria}}"
           - id: integration-verification
-            title: Integration Verification
+            title: 集成验证
-            instruction: Specific verification steps to ensure existing functionality remains intact
+            instruction: 确保现有功能保持不变的具体验证步骤
             type: numbered-list
             prefix: IV
             items:

bmad-core/templates/competitor-analysis-tmpl.yaml

@@ -1,307 +1,307 @@
-# <!-- Powered by BMAD™ Core -->
+# <!-- 由 BMAD™ Core 驱动 -->
 template:
   id: competitor-analysis-template-v2
-  name: Competitive Analysis Report
+  name: 竞争分析报告
   version: 2.0
   output:
     format: markdown
     filename: docs/competitor-analysis.md
-    title: "Competitive Analysis Report: {{project_product_name}}"
+    title: "竞争分析报告：{{project_product_name}}"
 
 workflow:
   mode: interactive
   elicitation: advanced-elicitation
   custom_elicitation:
-    title: "Competitive Analysis Elicitation Actions"
+    title: "竞争分析启发行动"
     options:
-      - "Deep dive on a specific competitor's strategy"
+      - "深入探讨特定竞争对手的策略"
-      - "Analyze competitive dynamics in a specific segment"
+      - "分析特定细分市场的竞争动态"
-      - "War game competitive responses to your moves"
+      - "推演您行动的竞争反应"
-      - "Explore partnership vs. competition scenarios"
+      - "探索合作与竞争的情景"
-      - "Stress test differentiation claims"
+      - "压力测试差异化主张"
-      - "Analyze disruption potential (yours or theirs)"
+      - "分析颠覆潜力（您的或他们的）"
-      - "Compare to competition in adjacent markets"
+      - "与邻近市场的竞争进行比较"
-      - "Generate win/loss analysis insights"
+      - "生成赢/输分析见解"
-      - "If only we had known about [competitor X's plan]..."
+      - "如果我们当初知道[竞争对手X的计划]就好了..."
-      - "Proceed to next section"
+      - "进入下一节"
 
 sections:
   - id: executive-summary
-    title: Executive Summary
+    title: 执行摘要
-    instruction: Provide high-level competitive insights, main threats and opportunities, and recommended strategic actions. Write this section LAST after completing all analysis.
+    instruction: 提供高层次的竞争见解、主要威胁和机遇，以及推荐的战略行动。在完成所有分析后最后撰写此部分。
 
   - id: analysis-scope
-    title: Analysis Scope & Methodology
+    title: 分析范围与方法论
-    instruction: This template guides comprehensive competitor analysis. Start by understanding the user's competitive intelligence needs and strategic objectives. Help them identify and prioritize competitors before diving into detailed analysis.
+    instruction: 此模板指导全面的竞争对手分析。首先了解用户的竞争情报需求和战略目标。在深入进行详细分析之前，帮助他们识别和优先排序竞争对手。
     sections:
       - id: analysis-purpose
-        title: Analysis Purpose
+        title: 分析目的
         instruction: |
-          Define the primary purpose:
+          定义主要目的：
-          - New market entry assessment
+          - 新市场进入评估
-          - Product positioning strategy
+          - 产品定位策略
-          - Feature gap analysis
+          - 功能差距分析
-          - Pricing strategy development
+          - 定价策略制定
-          - Partnership/acquisition targets
+          - 合作/收购目标
-          - Competitive threat assessment
+          - 竞争威胁评估
       - id: competitor-categories
-        title: Competitor Categories Analyzed
+        title: 分析的竞争对手类别
         instruction: |
-          List categories included:
+          列出包含的类别：
-          - Direct Competitors: Same product/service, same target market
+          - 直接竞争对手：相同的产品/服务，相同的目标市场
-          - Indirect Competitors: Different product, same need/problem
+          - 间接竞争对手：不同的产品，相同的需求/问题
-          - Potential Competitors: Could enter market easily
+          - 潜在竞争对手：可以轻松进入市场
-          - Substitute Products: Alternative solutions
+          - 替代产品：替代解决方案
-          - Aspirational Competitors: Best-in-class examples
+          - 理想竞争对手：同类最佳示例
       - id: research-methodology
-        title: Research Methodology
+        title: 研究方法论
         instruction: |
-          Describe approach:
+          描述方法：
-          - Information sources used
+          - 使用的信息来源
-          - Analysis timeframe
+          - 分析时间范围
-          - Confidence levels
+          - 置信水平
-          - Limitations
+          - 局限性
 
   - id: competitive-landscape
-    title: Competitive Landscape Overview
+    title: 竞争格局概述
     sections:
       - id: market-structure
-        title: Market Structure
+        title: 市场结构
         instruction: |
-          Describe the competitive environment:
+          描述竞争环境：
-          - Number of active competitors
+          - 活跃竞争对手数量
-          - Market concentration (fragmented/consolidated)
+          - 市场集中度（分散/集中）
-          - Competitive dynamics
+          - 竞争动态
-          - Recent market entries/exits
+          - 近期市场进入/退出情况
       - id: prioritization-matrix
-        title: Competitor Prioritization Matrix
+        title: 竞争对手优先级矩阵
         instruction: |
-          Help categorize competitors by market share and strategic threat level
+          帮助按市场份额和战略威胁级别对竞争对手进行分类
 
-          Create a 2x2 matrix:
+          创建一个2x2矩阵：
-          - Priority 1 (Core Competitors): High Market Share + High Threat
+          - 优先级1（核心竞争对手）：高市场份额 + 高威胁
-          - Priority 2 (Emerging Threats): Low Market Share + High Threat
+          - 优先级2（新兴威胁）：低市场份额 + 高威胁
-          - Priority 3 (Established Players): High Market Share + Low Threat
+          - 优先级3（老牌玩家）：高市场份额 + 低威胁
-          - Priority 4 (Monitor Only): Low Market Share + Low Threat
+          - 优先级4（仅监控）：低市场份额 + 低威胁
 
   - id: competitor-profiles
-    title: Individual Competitor Profiles
+    title: 单个竞争对手简介
-    instruction: Create detailed profiles for each Priority 1 and Priority 2 competitor. For Priority 3 and 4, create condensed profiles.
+    instruction: 为每个优先级1和优先级2的竞争对手创建详细简介。对于优先级3和4，创建简要简介。
     repeatable: true
     sections:
       - id: competitor
-        title: "{{competitor_name}} - Priority {{priority_level}}"
+        title: "{{competitor_name}} - 优先级 {{priority_level}}"
         sections:
           - id: company-overview
-            title: Company Overview
+            title: 公司概况
             template: |
-              - **Founded:** {{year_founders}}
+              - **成立时间：** {{year_founders}}
-              - **Headquarters:** {{location}}
+              - **总部：** {{location}}
-              - **Company Size:** {{employees_revenue}}
+              - **公司规模：** {{employees_revenue}}
-              - **Funding:** {{total_raised_investors}}
+              - **融资情况：** {{total_raised_investors}}
-              - **Leadership:** {{key_executives}}
+              - **领导层：** {{key_executives}}
           - id: business-model
-            title: Business Model & Strategy
+            title: 商业模式与策略
             template: |
-              - **Revenue Model:** {{revenue_model}}
+              - **收入模式：** {{revenue_model}}
-              - **Target Market:** {{customer_segments}}
+              - **目标市场：** {{customer_segments}}
-              - **Value Proposition:** {{value_promise}}
+              - **价值主张：** {{value_promise}}
-              - **Go-to-Market Strategy:** {{gtm_approach}}
+              - **市场进入策略：** {{gtm_approach}}
-              - **Strategic Focus:** {{current_priorities}}
+              - **战略重点：** {{current_priorities}}
           - id: product-analysis
-            title: Product/Service Analysis
+            title: 产品/服务分析
             template: |
-              - **Core Offerings:** {{main_products}}
+              - **核心产品：** {{main_products}}
-              - **Key Features:** {{standout_capabilities}}
+              - **关键功能：** {{standout_capabilities}}
-              - **User Experience:** {{ux_assessment}}
+              - **用户体验：** {{ux_assessment}}
-              - **Technology Stack:** {{tech_stack}}
+              - **技术栈：** {{tech_stack}}
-              - **Pricing:** {{pricing_model}}
+              - **定价：** {{pricing_model}}
           - id: strengths-weaknesses
-            title: Strengths & Weaknesses
+            title: 优势与劣势
             sections:
               - id: strengths
-                title: Strengths
+                title: 优势
                 type: bullet-list
                 template: "- {{strength}}"
               - id: weaknesses
-                title: Weaknesses
+                title: 劣势
                 type: bullet-list
                 template: "- {{weakness}}"
           - id: market-position
-            title: Market Position & Performance
+            title: 市场地位与表现
             template: |
-              - **Market Share:** {{market_share_estimate}}
+              - **市场份额：** {{market_share_estimate}}
-              - **Customer Base:** {{customer_size_notables}}
+              - **客户群：** {{customer_size_notables}}
-              - **Growth Trajectory:** {{growth_trend}}
+              - **增长轨迹：** {{growth_trend}}
-              - **Recent Developments:** {{key_news}}
+              - **近期发展：** {{key_news}}
 
   - id: comparative-analysis
-    title: Comparative Analysis
+    title: 比较分析
     sections:
       - id: feature-comparison
-        title: Feature Comparison Matrix
+        title: 功能比较矩阵
-        instruction: Create a detailed comparison table of key features across competitors
+        instruction: 创建一个详细的跨竞争对手关键功能比较表
         type: table
         columns:
           [
-            "Feature Category",
+            "功能类别",
             "{{your_company}}",
             "{{competitor_1}}",
             "{{competitor_2}}",
             "{{competitor_3}}",
           ]
         rows:
-          - category: "Core Functionality"
+          - category: "核心功能"
             items:
-              - ["Feature A", "{{status}}", "{{status}}", "{{status}}", "{{status}}"]
+              - ["功能A", "{{status}}", "{{status}}", "{{status}}", "{{status}}"]
-              - ["Feature B", "{{status}}", "{{status}}", "{{status}}", "{{status}}"]
+              - ["功能B", "{{status}}", "{{status}}", "{{status}}", "{{status}}"]
-          - category: "User Experience"
+          - category: "用户体验"
             items:
-              - ["Mobile App", "{{rating}}", "{{rating}}", "{{rating}}", "{{rating}}"]
+              - ["移动应用", "{{rating}}", "{{rating}}", "{{rating}}", "{{rating}}"]
-              - ["Onboarding Time", "{{time}}", "{{time}}", "{{time}}", "{{time}}"]
+              - ["上手时间", "{{time}}", "{{time}}", "{{time}}", "{{time}}"]
-          - category: "Integration & Ecosystem"
+          - category: "集成与生态系统"
             items:
               - [
-                  "API Availability",
+                  "API可用性",
                   "{{availability}}",
                   "{{availability}}",
                   "{{availability}}",
                   "{{availability}}",
                 ]
-              - ["Third-party Integrations", "{{number}}", "{{number}}", "{{number}}", "{{number}}"]
+              - ["第三方集成", "{{number}}", "{{number}}", "{{number}}", "{{number}}"]
-          - category: "Pricing & Plans"
+          - category: "定价与计划"
             items:
-              - ["Starting Price", "{{price}}", "{{price}}", "{{price}}", "{{price}}"]
+              - ["起步价", "{{price}}", "{{price}}", "{{price}}", "{{price}}"]
-              - ["Free Tier", "{{yes_no}}", "{{yes_no}}", "{{yes_no}}", "{{yes_no}}"]
+              - ["免费套餐", "{{yes_no}}", "{{yes_no}}", "{{yes_no}}", "{{yes_no}}"]
       - id: swot-comparison
-        title: SWOT Comparison
+        title: SWOT比较
-        instruction: Create SWOT analysis for your solution vs. top competitors
+        instruction: 为您的解决方案与主要竞争对手创建SWOT分析
         sections:
           - id: your-solution
-            title: Your Solution
+            title: 您的解决方案
             template: |
-              - **Strengths:** {{strengths}}
+              - **优势：** {{strengths}}
-              - **Weaknesses:** {{weaknesses}}
+              - **劣势：** {{weaknesses}}
-              - **Opportunities:** {{opportunities}}
+              - **机会：** {{opportunities}}
-              - **Threats:** {{threats}}
+              - **威胁：** {{threats}}
           - id: vs-competitor
             title: "vs. {{main_competitor}}"
             template: |
-              - **Competitive Advantages:** {{your_advantages}}
+              - **竞争优势：** {{your_advantages}}
-              - **Competitive Disadvantages:** {{their_advantages}}
+              - **竞争劣势：** {{their_advantages}}
-              - **Differentiation Opportunities:** {{differentiation}}
+              - **差异化机会：** {{differentiation}}
       - id: positioning-map
-        title: Positioning Map
+        title: 定位图
         instruction: |
-          Describe competitor positions on key dimensions
+          描述竞争对手在关键维度上的位置
 
-          Create a positioning description using 2 key dimensions relevant to the market, such as:
+          使用与市场相关的2个关键维度创建定位描述，例如：
-          - Price vs. Features
+          - 价格 vs. 功能
-          - Ease of Use vs. Power
+          - 易用性 vs. 强大功能
-          - Specialization vs. Breadth
+          - 专业化 vs. 广度
-          - Self-Serve vs. High-Touch
+          - 自助服务 vs. 高接触度
 
   - id: strategic-analysis
-    title: Strategic Analysis
+    title: 战略分析
     sections:
       - id: competitive-advantages
-        title: Competitive Advantages Assessment
+        title: 竞争优势评估
         sections:
           - id: sustainable-advantages
-            title: Sustainable Advantages
+            title: 可持续优势
             instruction: |
-              Identify moats and defensible positions:
+              识别护城河和可防御的阵地：
-              - Network effects
+              - 网络效应
-              - Switching costs
+              - 转换成本
-              - Brand strength
+              - 品牌实力
-              - Technology barriers
+              - 技术壁垒
-              - Regulatory advantages
+              - 监管优势
           - id: vulnerable-points
-            title: Vulnerable Points
+            title: 薄弱环节
             instruction: |
-              Where competitors could be challenged:
+              可以挑战竞争对手的地方：
-              - Weak customer segments
+              - 薄弱的客户细分
-              - Missing features
+              - 缺失的功能
-              - Poor user experience
+              - 糟糕的用户体验
-              - High prices
+              - 高昂的价格
-              - Limited geographic presence
+              - 有限的地理覆盖范围
       - id: blue-ocean
-        title: Blue Ocean Opportunities
+        title: 蓝海机会
         instruction: |
-          Identify uncontested market spaces
+          识别无竞争的市场空间
 
-          List opportunities to create new market space:
+          列出创造新市场空间的机会：
-          - Underserved segments
+          - 服务不足的细分市场
-          - Unaddressed use cases
+          - 未解决的用例
-          - New business models
+          - 新的商业模式
-          - Geographic expansion
+          - 地域扩张
-          - Different value propositions
+          - 不同的价值主张
 
   - id: strategic-recommendations
-    title: Strategic Recommendations
+    title: 战略建议
     sections:
       - id: differentiation-strategy
-        title: Differentiation Strategy
+        title: 差异化策略
         instruction: |
-          How to position against competitors:
+          如何针对竞争对手进行定位：
-          - Unique value propositions to emphasize
+          - 强调独特的价值主张
-          - Features to prioritize
+          - 优先考虑的功能
-          - Segments to target
+          - 目标细分市场
-          - Messaging and positioning
+          - 消息传递和定位
       - id: competitive-response
-        title: Competitive Response Planning
+        title: 竞争反应规划
         sections:
           - id: offensive-strategies
-            title: Offensive Strategies
+            title: 进攻策略
             instruction: |
-              How to gain market share:
+              如何获得市场份额：
-              - Target competitor weaknesses
+              - 针对竞争对手的弱点
-              - Win competitive deals
+              - 赢得竞争性交易
-              - Capture their customers
+              - 争取他们的客户
           - id: defensive-strategies
-            title: Defensive Strategies
+            title: 防御策略
             instruction: |
-              How to protect your position:
+              如何保护您的地位：
-              - Strengthen vulnerable areas
+              - 加强薄弱环节
-              - Build switching costs
+              - 建立转换成本
-              - Deepen customer relationships
+              - 深化客户关系
       - id: partnership-ecosystem
-        title: Partnership & Ecosystem Strategy
+        title: 合作与生态系统策略
         instruction: |
-          Potential collaboration opportunities:
+          潜在的合作机会：
-          - Complementary players
+          - 互补的参与者
-          - Channel partners
+          - 渠道合作伙伴
-          - Technology integrations
+          - 技术集成
-          - Strategic alliances
+          - 战略联盟
 
   - id: monitoring-plan
-    title: Monitoring & Intelligence Plan
+    title: 监控与情报计划
     sections:
       - id: key-competitors
-        title: Key Competitors to Track
+        title: 要跟踪的关键竞争对手
-        instruction: Priority list with rationale
+        instruction: 带有理由的优先级列表
       - id: monitoring-metrics
-        title: Monitoring Metrics
+        title: 监控指标
         instruction: |
-          What to track:
+          要跟踪的内容：
-          - Product updates
+          - 产品更新
-          - Pricing changes
+          - 定价变化
-          - Customer wins/losses
+          - 客户赢/输情况
-          - Funding/M&A activity
+          - 融资/并购活动
-          - Market messaging
+          - 市场消息
       - id: intelligence-sources
-        title: Intelligence Sources
+        title: 情报来源
         instruction: |
-          Where to gather ongoing intelligence:
+          在哪里收集持续的情报：
-          - Company websites/blogs
+          - 公司网站/博客
-          - Customer reviews
+          - 客户评论
-          - Industry reports
+          - 行业报告
-          - Social media
+          - 社交媒体
-          - Patent filings
+          - 专利申请
       - id: update-cadence
-        title: Update Cadence
+        title: 更新频率
         instruction: |
-          Recommended review schedule:
+          推荐的审查时间表：
-          - Weekly: {{weekly_items}}
+          - 每周：{{weekly_items}}
-          - Monthly: {{monthly_items}}
+          - 每月：{{monthly_items}}
-          - Quarterly: {{quarterly_analysis}}
+          - 每季度：{{quarterly_analysis}}

bmad-core/templates/front-end-architecture-tmpl.yaml

@@ -1,12 +1,12 @@
-# <!-- Powered by BMAD™ Core -->
+# <!-- 由 BMAD™ Core 驱动 -->
 template:
   id: frontend-architecture-template-v2
-  name: Frontend Architecture Document
+  name: 前端架构文档
   version: 2.0
   output:
     format: markdown
     filename: docs/ui-architecture.md
-    title: "{{project_name}} Frontend Architecture Document"
+    title: "{{project_name}} 前端架构文档"
 
 workflow:
   mode: interactive
@@ -14,206 +14,206 @@ workflow:
 
 sections:
   - id: template-framework-selection
-    title: Template and Framework Selection
+    title: 模板和框架选择
     instruction: |
-      Review provided documents including PRD, UX-UI Specification, and main Architecture Document. Focus on extracting technical implementation details needed for AI frontend tools and developer agents. Ask the user for any of these documents if you are unable to locate and were not provided.
+      审查提供的文档，包括PRD、UX-UI规范和主架构文档。重点提取AI前端工具和开发代理所需的技术实现细节。如果您无法找到或未提供任何这些文档，请向用户索取。
 
-      Before proceeding with frontend architecture design, check if the project is using a frontend starter template or existing codebase:
+      在继续进行前端架构设计之前，请检查项目是否使用前端入门模板或现有代码库：
 
-      1. Review the PRD, main architecture document, and brainstorming brief for mentions of:
+      1. 审查PRD、主架构文档和头脑风暴简报中是否提及：
-         - Frontend starter templates (e.g., Create React App, Next.js, Vite, Vue CLI, Angular CLI, etc.)
+         - 前端入门模板（例如，Create React App、Next.js、Vite、Vue CLI、Angular CLI等）
-         - UI kit or component library starters
+         - UI工具包或组件库入门模板
-         - Existing frontend projects being used as a foundation
+         - 用作基础的现有前端项目
-         - Admin dashboard templates or other specialized starters
+         - 管理仪表板模板或其他专业入门模板
-         - Design system implementations
+         - 设计系统实现
 
-      2. If a frontend starter template or existing project is mentioned:
+      2. 如果提及了前端入门模板或现有项目：
-         - Ask the user to provide access via one of these methods:
+         - 要求用户通过以下方法之一提供访问权限：
-           - Link to the starter template documentation
+           - 指向入门模板文档的链接
-           - Upload/attach the project files (for small projects)
+           - 上传/附加项目文件（对于小项目）
-           - Share a link to the project repository
+           - 共享项目存储库的链接
-         - Analyze the starter/existing project to understand:
+         - 分析入门/现有项目以了解：
-           - Pre-installed dependencies and versions
+           - 预安装的依赖项和版本
-           - Folder structure and file organization
+           - 文件夹结构和文件组织
-           - Built-in components and utilities
+           - 内置组件和实用程序
-           - Styling approach (CSS modules, styled-components, Tailwind, etc.)
+           - 样式方法（CSS模块、styled-components、Tailwind等）
-           - State management setup (if any)
+           - 状态管理设置（如果有）
-           - Routing configuration
+           - 路由配置
-           - Testing setup and patterns
+           - 测试设置和模式
-           - Build and development scripts
+           - 构建和开发脚本
-         - Use this analysis to ensure your frontend architecture aligns with the starter's patterns
+         - 使用此分析来确保您的前端架构与入门模板的模式保持一致
 
-      3. If no frontend starter is mentioned but this is a new UI, ensure we know what the ui language and framework is:
+      3. 如果未提及前端入门模板但这是一个新的UI，请确保我们知道UI语言和框架是什么：
-         - Based on the framework choice, suggest appropriate starters:
+         - 根据框架选择，建议合适的入门模板：
            - React: Create React App, Next.js, Vite + React
            - Vue: Vue CLI, Nuxt.js, Vite + Vue
            - Angular: Angular CLI
-           - Or suggest popular UI templates if applicable
+           - 或者如果适用，建议流行的UI模板
-         - Explain benefits specific to frontend development
+         - 解释特定于前端开发的好处
 
-      4. If the user confirms no starter template will be used:
+      4. 如果用户确认不使用入门模板：
-         - Note that all tooling, bundling, and configuration will need manual setup
+         - 注意所有工具、打包和配置都需要手动设置
-         - Proceed with frontend architecture from scratch
+         - 从头开始进行前端架构设计
 
-      Document the starter template decision and any constraints it imposes before proceeding.
+      在继续之前，记录入门模板的决定及其施加的任何约束。
     sections:
       - id: changelog
-        title: Change Log
+        title: 变更日志
         type: table
-        columns: [Date, Version, Description, Author]
+        columns: [日期, 版本, 描述, 作者]
-        instruction: Track document versions and changes
+        instruction: 跟踪文档版本和变更
 
   - id: frontend-tech-stack
-    title: Frontend Tech Stack
+    title: 前端技术栈
-    instruction: Extract from main architecture's Technology Stack Table. This section MUST remain synchronized with the main architecture document.
+    instruction: 从主架构的技术栈表中提取。此部分必须与主架构文档保持同步。
     elicit: true
     sections:
       - id: tech-stack-table
-        title: Technology Stack Table
+        title: 技术栈表
         type: table
-        columns: [Category, Technology, Version, Purpose, Rationale]
+        columns: [类别, 技术, 版本, 目的, 理由]
-        instruction: Fill in appropriate technology choices based on the selected framework and project requirements.
+        instruction: 根据所选框架和项目要求，填写适当的技术选择。
         rows:
-          - ["Framework", "{{framework}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
+          - ["框架", "{{framework}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
-          - ["UI Library", "{{ui_library}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
+          - ["UI库", "{{ui_library}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
           - [
-              "State Management",
+              "状态管理",
               "{{state_management}}",
               "{{version}}",
               "{{purpose}}",
               "{{why_chosen}}",
             ]
-          - ["Routing", "{{routing_library}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
+          - ["路由", "{{routing_library}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
-          - ["Build Tool", "{{build_tool}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
+          - ["构建工具", "{{build_tool}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
-          - ["Styling", "{{styling_solution}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
+          - ["样式", "{{styling_solution}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
-          - ["Testing", "{{test_framework}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
+          - ["测试", "{{test_framework}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
           - [
-              "Component Library",
+              "组件库",
               "{{component_lib}}",
               "{{version}}",
               "{{purpose}}",
               "{{why_chosen}}",
             ]
-          - ["Form Handling", "{{form_library}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
+          - ["表单处理", "{{form_library}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
-          - ["Animation", "{{animation_lib}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
+          - ["动画", "{{animation_lib}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
-          - ["Dev Tools", "{{dev_tools}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
+          - ["开发工具", "{{dev_tools}}", "{{version}}", "{{purpose}}", "{{why_chosen}}"]
 
   - id: project-structure
-    title: Project Structure
+    title: 项目结构
-    instruction: Define exact directory structure for AI tools based on the chosen framework. Be specific about where each type of file goes. Generate a structure that follows the framework's best practices and conventions.
+    instruction: 根据所选框架为AI工具定义确切的目录结构。具体说明每种类型的文件放在哪里。生成一个遵循框架最佳实践和约定的结构。
     elicit: true
     type: code
     language: plaintext
 
   - id: component-standards
-    title: Component Standards
+    title: 组件标准
-    instruction: Define exact patterns for component creation based on the chosen framework.
+    instruction: 根据所选框架定义组件创建的确切模式。
     elicit: true
     sections:
       - id: component-template
-        title: Component Template
+        title: 组件模板
-        instruction: Generate a minimal but complete component template following the framework's best practices. Include TypeScript types, proper imports, and basic structure.
+        instruction: 生成一个遵循框架最佳实践的最小但完整的组件模板。包括TypeScript类型、正确的导入和基本结构。
         type: code
         language: typescript
       - id: naming-conventions
-        title: Naming Conventions
+        title: 命名约定
-        instruction: Provide naming conventions specific to the chosen framework for components, files, services, state management, and other architectural elements.
+        instruction: 为组件、文件、服务、状态管理和其他架构元素提供特定于所选框架的命名约定。
 
   - id: state-management
-    title: State Management
+    title: 状态管理
-    instruction: Define state management patterns based on the chosen framework.
+    instruction: 根据所选框架定义状态管理模式。
     elicit: true
     sections:
       - id: store-structure
-        title: Store Structure
+        title: 存储结构
-        instruction: Generate the state management directory structure appropriate for the chosen framework and selected state management solution.
+        instruction: 生成适合所选框架和状态管理解决方案的状态管理目录结构。
         type: code
         language: plaintext
       - id: state-template
-        title: State Management Template
+        title: 状态管理模板
-        instruction: Provide a basic state management template/example following the framework's recommended patterns. Include TypeScript types and common operations like setting, updating, and clearing state.
+        instruction: 提供一个遵循框架推荐模式的基本状态管理模板/示例。包括TypeScript类型和常见的操作，如设置、更新和清除状态。
         type: code
         language: typescript
 
   - id: api-integration
-    title: API Integration
+    title: API集成
-    instruction: Define API service patterns based on the chosen framework.
+    instruction: 根据所选框架定义API服务模式。
     elicit: true
     sections:
       - id: service-template
-        title: Service Template
+        title: 服务模板
-        instruction: Provide an API service template that follows the framework's conventions. Include proper TypeScript types, error handling, and async patterns.
+        instruction: 提供一个遵循框架约定的API服务模板。包括正确的TypeScript类型、错误处理和异步模式。
         type: code
         language: typescript
       - id: api-client-config
-        title: API Client Configuration
+        title: API客户端配置
-        instruction: Show how to configure the HTTP client for the chosen framework, including authentication interceptors/middleware and error handling.
+        instruction: 展示如何为所选框架配置HTTP客户端，包括身份验证拦截器/中间件和错误处理。
         type: code
         language: typescript
 
   - id: routing
-    title: Routing
+    title: 路由
-    instruction: Define routing structure and patterns based on the chosen framework.
+    instruction: 根据所选框架定义路由结构和模式。
     elicit: true
     sections:
       - id: route-configuration
-        title: Route Configuration
+        title: 路由配置
-        instruction: Provide routing configuration appropriate for the chosen framework. Include protected route patterns, lazy loading where applicable, and authentication guards/middleware.
+        instruction: 提供适合所选框架的路由配置。包括受保护的路由模式、适用时的延迟加载以及身份验证守卫/中间件。
         type: code
         language: typescript
 
   - id: styling-guidelines
-    title: Styling Guidelines
+    title: 样式指南
-    instruction: Define styling approach based on the chosen framework.
+    instruction: 根据所选框架定义样式方法。
     elicit: true
     sections:
       - id: styling-approach
-        title: Styling Approach
+        title: 样式方法
-        instruction: Describe the styling methodology appropriate for the chosen framework (CSS Modules, Styled Components, Tailwind, etc.) and provide basic patterns.
+        instruction: 描述适合所选框架的样式方法（CSS模块、Styled Components、Tailwind等）并提供基本模式。
       - id: global-theme
-        title: Global Theme Variables
+        title: 全局主题变量
-        instruction: Provide a CSS custom properties (CSS variables) theme system that works across all frameworks. Include colors, spacing, typography, shadows, and dark mode support.
+        instruction: 提供一个适用于所有框架的CSS自定义属性（CSS变量）主题系统。包括颜色、间距、排版、阴影和暗黑模式支持。
         type: code
         language: css
 
   - id: testing-requirements
-    title: Testing Requirements
+    title: 测试要求
-    instruction: Define minimal testing requirements based on the chosen framework.
+    instruction: 根据所选框架定义最低测试要求。
     elicit: true
     sections:
       - id: component-test-template
-        title: Component Test Template
+        title: 组件测试模板
-        instruction: Provide a basic component test template using the framework's recommended testing library. Include examples of rendering tests, user interaction tests, and mocking.
+        instruction: 提供一个使用框架推荐的测试库的基本组件测试模板。包括渲染测试、用户交互测试和模拟的示例。
         type: code
         language: typescript
       - id: testing-best-practices
-        title: Testing Best Practices
+        title: 测试最佳实践
         type: numbered-list
         items:
-          - "**Unit Tests**: Test individual components in isolation"
+          - "**单元测试**：独立测试单个组件"
-          - "**Integration Tests**: Test component interactions"
+          - "**集成测试**：测试组件交互"
-          - "**E2E Tests**: Test critical user flows (using Cypress/Playwright)"
+          - "**端到端测试**：测试关键用户流程（使用Cypress/Playwright）"
-          - "**Coverage Goals**: Aim for 80% code coverage"
+          - "**覆盖目标**：目标是80%的代码覆盖率"
-          - "**Test Structure**: Arrange-Act-Assert pattern"
+          - "**测试结构**：Arrange-Act-Assert模式"
-          - "**Mock External Dependencies**: API calls, routing, state management"
+          - "**模拟外部依赖**：API调用、路由、状态管理"
 
   - id: environment-configuration
-    title: Environment Configuration
+    title: 环境配置
-    instruction: List required environment variables based on the chosen framework. Show the appropriate format and naming conventions for the framework.
+    instruction: 根据所选框架列出所需的环境变量。显示框架的适当格式和命名约定。
     elicit: true
 
   - id: frontend-developer-standards
-    title: Frontend Developer Standards
+    title: 前端开发者标准
     sections:
       - id: critical-coding-rules
-        title: Critical Coding Rules
+        title: 关键编码规则
-        instruction: List essential rules that prevent common AI mistakes, including both universal rules and framework-specific ones.
+        instruction: 列出防止常见AI错误的基本规则，包括通用规则和特定于框架的规则。
         elicit: true
       - id: quick-reference
-        title: Quick Reference
+        title: 快速参考
         instruction: |
-          Create a framework-specific cheat sheet with:
+          创建一个特定于框架的备忘单，包含：
-          - Common commands (dev server, build, test)
+          - 常用命令（开发服务器、构建、测试）
-          - Key import patterns
+          - 关键导入模式
-          - File naming conventions
+          - 文件命名约定
-          - Project-specific patterns and utilities
+          - 特定于项目的模式和实用程序

bmad-core/templates/front-end-spec-tmpl.yaml

@@ -1,12 +1,12 @@
-# <!-- Powered by BMAD™ Core -->
+# <!-- 由 BMAD™ Core 驱动 -->
 template:
   id: frontend-spec-template-v2
-  name: UI/UX Specification
+  name: UI/UX规范
   version: 2.0
   output:
     format: markdown
     filename: docs/front-end-spec.md
-    title: "{{project_name}} UI/UX Specification"
+    title: "{{project_name}} UI/UX规范"
 
 workflow:
   mode: interactive
@@ -14,337 +14,337 @@ workflow:
 
 sections:
   - id: introduction
-    title: Introduction
+    title: 引言
     instruction: |
-      Review provided documents including Project Brief, PRD, and any user research to gather context. Focus on understanding user needs, pain points, and desired outcomes before beginning the specification.
+      在开始规范之前，请审查提供的文档，包括项目简报、PRD和任何用户研究，以收集背景信息。重点是了解用户的需求、痛点和期望的结果。
 
-      Establish the document's purpose and scope. Keep the content below but ensure project name is properly substituted.
+      建立文档的目的和范围。保留以下内容，但确保正确替换项目名称。
     content: |
-      This document defines the user experience goals, information architecture, user flows, and visual design specifications for {{project_name}}'s user interface. It serves as the foundation for visual design and frontend development, ensuring a cohesive and user-centered experience.
+      本文档定义了{{project_name}}用户界面的用户体验目标、信息架构、用户流程和视觉设计规范。它作为视觉设计和前端开发的基础，确保提供一个有凝聚力的、以用户为中心的体验。
     sections:
       - id: ux-goals-principles
-        title: Overall UX Goals & Principles
+        title: 整体UX目标与原则
         instruction: |
-          Work with the user to establish and document the following. If not already defined, facilitate a discussion to determine:
+          与用户一起建立和记录以下内容。如果尚未定义，请促成一次讨论以确定：
 
-          1. Target User Personas - elicit details or confirm existing ones from PRD
+          1. 目标用户画像 - 启发细节或确认PRD中已有的画像
-          2. Key Usability Goals - understand what success looks like for users
+          2. 关键可用性目标 - 了解用户成功的样子
-          3. Core Design Principles - establish 3-5 guiding principles
+          3. 核心设计原则 - 建立3-5个指导原则
         elicit: true
         sections:
           - id: user-personas
-            title: Target User Personas
+            title: 目标用户画像
             template: "{{persona_descriptions}}"
             examples:
-              - "**Power User:** Technical professionals who need advanced features and efficiency"
+              - "**高级用户：** 需要高级功能和效率的技术专业人员"
-              - "**Casual User:** Occasional users who prioritize ease of use and clear guidance"
+              - "**普通用户：** 偶尔使用，优先考虑易用性和清晰指导的用户"
-              - "**Administrator:** System managers who need control and oversight capabilities"
+              - "**管理员：** 需要控制和监督能力的系统管理员"
           - id: usability-goals
-            title: Usability Goals
+            title: 可用性目标
             template: "{{usability_goals}}"
             examples:
-              - "Ease of learning: New users can complete core tasks within 5 minutes"
+              - "易学性：新用户可以在5分钟内完成核心任务"
-              - "Efficiency of use: Power users can complete frequent tasks with minimal clicks"
+              - "使用效率：高级用户可以以最少的点击次数完成频繁的任务"
-              - "Error prevention: Clear validation and confirmation for destructive actions"
+              - "防错性：为破坏性操作提供清晰的验证和确认"
-              - "Memorability: Infrequent users can return without relearning"
+              - "易记性：不常使用的用户可以无需重新学习即可返回"
           - id: design-principles
-            title: Design Principles
+            title: 设计原则
             template: "{{design_principles}}"
             type: numbered-list
             examples:
-              - "**Clarity over cleverness** - Prioritize clear communication over aesthetic innovation"
+              - "**清晰优于巧妙** - 优先考虑清晰的沟通，而不是美学创新"
-              - "**Progressive disclosure** - Show only what's needed, when it's needed"
+              - "**渐进式披露** - 只在需要时显示所需内容"
-              - "**Consistent patterns** - Use familiar UI patterns throughout the application"
+              - "**一致的模式** - 在整个应用程序中使用熟悉的UI模式"
-              - "**Immediate feedback** - Every action should have a clear, immediate response"
+              - "**即时反馈** - 每个操作都应有清晰、即时的响应"
-              - "**Accessible by default** - Design for all users from the start"
+              - "**默认可访问** - 从一开始就为所有用户设计"
       - id: changelog
-        title: Change Log
+        title: 变更日志
         type: table
-        columns: [Date, Version, Description, Author]
+        columns: [日期, 版本, 描述, 作者]
-        instruction: Track document versions and changes
+        instruction: 跟踪文档版本和变更
 
   - id: information-architecture
-    title: Information Architecture (IA)
+    title: 信息架构 (IA)
     instruction: |
-      Collaborate with the user to create a comprehensive information architecture:
+      与用户协作创建全面的信息架构：
 
-      1. Build a Site Map or Screen Inventory showing all major areas
+      1. 构建一个显示所有主要区域的站点地图或屏幕清单
-      2. Define the Navigation Structure (primary, secondary, breadcrumbs)
+      2. 定义导航结构（主导航、次导航、面包屑）
-      3. Use Mermaid diagrams for visual representation
+      3. 使用Mermaid图进行可视化表示
-      4. Consider user mental models and expected groupings
+      4. 考虑用户的心理模型和预期的分组
     elicit: true
     sections:
       - id: sitemap
-        title: Site Map / Screen Inventory
+        title: 站点地图/屏幕清单
         type: mermaid
         mermaid_type: graph
         template: "{{sitemap_diagram}}"
         examples:
           - |
             graph TD
-                A[Homepage] --> B[Dashboard]
+                A[主页] --> B[仪表板]
-                A --> C[Products]
+                A --> C[产品]
-                A --> D[Account]
+                A --> D[账户]
-                B --> B1[Analytics]
+                B --> B1[分析]
-                B --> B2[Recent Activity]
+                B --> B2[最近活动]
-                C --> C1[Browse]
+                C --> C1[浏览]
-                C --> C2[Search]
+                C --> C2[搜索]
-                C --> C3[Product Details]
+                C --> C3[产品详情]
-                D --> D1[Profile]
+                D --> D1[个人资料]
-                D --> D2[Settings]
+                D --> D2[设置]
-                D --> D3[Billing]
+                D --> D3[账单]
       - id: navigation-structure
-        title: Navigation Structure
+        title: 导航结构
         template: |
-          **Primary Navigation:** {{primary_nav_description}}
+          **主导航：** {{primary_nav_description}}
 
-          **Secondary Navigation:** {{secondary_nav_description}}
+          **次导航：** {{secondary_nav_description}}
 
-          **Breadcrumb Strategy:** {{breadcrumb_strategy}}
+          **面包屑策略：** {{breadcrumb_strategy}}
 
   - id: user-flows
-    title: User Flows
+    title: 用户流程
     instruction: |
-      For each critical user task identified in the PRD:
+      对于PRD中确定的每个关键用户任务：
 
-      1. Define the user's goal clearly
+      1. 明确定义用户的目标
-      2. Map out all steps including decision points
+      2. 规划出所有步骤，包括决策点
-      3. Consider edge cases and error states
+      3. 考虑边缘情况和错误状态
-      4. Use Mermaid flow diagrams for clarity
+      4. 使用Mermaid流程图以求清晰
-      5. Link to external tools (Figma/Miro) if detailed flows exist there
+      5. 如果有详细的流程图，则链接到外部工具（Figma/Miro）
 
-      Create subsections for each major flow.
+      为每个主要流程创建子部分。
     elicit: true
     repeatable: true
     sections:
       - id: flow
         title: "{{flow_name}}"
         template: |
-          **User Goal:** {{flow_goal}}
+          **用户目标：** {{flow_goal}}
 
-          **Entry Points:** {{entry_points}}
+          **入口点：** {{entry_points}}
 
-          **Success Criteria:** {{success_criteria}}
+          **成功标准：** {{success_criteria}}
         sections:
           - id: flow-diagram
-            title: Flow Diagram
+            title: 流程图
             type: mermaid
             mermaid_type: graph
             template: "{{flow_diagram}}"
           - id: edge-cases
-            title: "Edge Cases & Error Handling:"
+            title: "边缘情况与错误处理："
             type: bullet-list
             template: "- {{edge_case}}"
           - id: notes
-            template: "**Notes:** {{flow_notes}}"
+            template: "**说明：** {{flow_notes}}"
 
   - id: wireframes-mockups
-    title: Wireframes & Mockups
+    title: 线框图与模型
     instruction: |
-      Clarify where detailed visual designs will be created (Figma, Sketch, etc.) and how to reference them. If low-fidelity wireframes are needed, offer to help conceptualize layouts for key screens.
+      澄清将在何处创建详细的视觉设计（Figma、Sketch等），以及如何引用它们。如果需要低保真线框图，请提议帮助为关键屏幕构思布局。
     elicit: true
     sections:
       - id: design-files
-        template: "**Primary Design Files:** {{design_tool_link}}"
+        template: "**主要设计文件：** {{design_tool_link}}"
       - id: key-screen-layouts
-        title: Key Screen Layouts
+        title: 关键屏幕布局
         repeatable: true
         sections:
           - id: screen
             title: "{{screen_name}}"
             template: |
-              **Purpose:** {{screen_purpose}}
+              **目的：** {{screen_purpose}}
 
-              **Key Elements:**
+              **关键元素：**
               - {{element_1}}
               - {{element_2}}
               - {{element_3}}
 
-              **Interaction Notes:** {{interaction_notes}}
+              **交互说明：** {{interaction_notes}}
 
-              **Design File Reference:** {{specific_frame_link}}
+              **设计文件参考：** {{specific_frame_link}}
 
   - id: component-library
-    title: Component Library / Design System
+    title: 组件库/设计系统
     instruction: |
-      Discuss whether to use an existing design system or create a new one. If creating new, identify foundational components and their key states. Note that detailed technical specs belong in front-end-architecture.
+      讨论是使用现有的设计系统还是创建一个新的。如果创建新的，请确定基础组件及其关键状态。注意，详细的技术规范属于前端架构。
     elicit: true
     sections:
       - id: design-system-approach
-        template: "**Design System Approach:** {{design_system_approach}}"
+        template: "**设计系统方法：** {{design_system_approach}}"
       - id: core-components
-        title: Core Components
+        title: 核心组件
         repeatable: true
         sections:
           - id: component
             title: "{{component_name}}"
             template: |
-              **Purpose:** {{component_purpose}}
+              **目的：** {{component_purpose}}
 
-              **Variants:** {{component_variants}}
+              **变体：** {{component_variants}}
 
-              **States:** {{component_states}}
+              **状态：** {{component_states}}
 
-              **Usage Guidelines:** {{usage_guidelines}}
+              **使用指南：** {{usage_guidelines}}
 
   - id: branding-style
-    title: Branding & Style Guide
+    title: 品牌与风格指南
-    instruction: Link to existing style guide or define key brand elements. Ensure consistency with company brand guidelines if they exist.
+    instruction: 链接到现有的风格指南或定义关键品牌元素。如果存在公司品牌指南，请确保与其保持一致。
     elicit: true
     sections:
       - id: visual-identity
-        title: Visual Identity
+        title: 视觉识别
-        template: "**Brand Guidelines:** {{brand_guidelines_link}}"
+        template: "**品牌指南：** {{brand_guidelines_link}}"
       - id: color-palette
-        title: Color Palette
+        title: 调色板
         type: table
-        columns: ["Color Type", "Hex Code", "Usage"]
+        columns: ["颜色类型", "十六进制代码", "用途"]
         rows:
-          - ["Primary", "{{primary_color}}", "{{primary_usage}}"]
+          - ["主色", "{{primary_color}}", "{{primary_usage}}"]
-          - ["Secondary", "{{secondary_color}}", "{{secondary_usage}}"]
+          - ["次色", "{{secondary_color}}", "{{secondary_usage}}"]
-          - ["Accent", "{{accent_color}}", "{{accent_usage}}"]
+          - ["强调色", "{{accent_color}}", "{{accent_usage}}"]
-          - ["Success", "{{success_color}}", "Positive feedback, confirmations"]
+          - ["成功色", "{{success_color}}", "积极反馈、确认"]
-          - ["Warning", "{{warning_color}}", "Cautions, important notices"]
+          - ["警告色", "{{warning_color}}", "警告、重要通知"]
-          - ["Error", "{{error_color}}", "Errors, destructive actions"]
+          - ["错误色", "{{error_color}}", "错误、破坏性操作"]
-          - ["Neutral", "{{neutral_colors}}", "Text, borders, backgrounds"]
+          - ["中性色", "{{neutral_colors}}", "文本、边框、背景"]
       - id: typography
-        title: Typography
+        title: 排版
         sections:
           - id: font-families
-            title: Font Families
+            title: 字体家族
             template: |
-              - **Primary:** {{primary_font}}
+              - **主要字体：** {{primary_font}}
-              - **Secondary:** {{secondary_font}}
+              - **次要字体：** {{secondary_font}}
-              - **Monospace:** {{mono_font}}
+              - **等宽字体：** {{mono_font}}
           - id: type-scale
-            title: Type Scale
+            title: 字号比例
             type: table
-            columns: ["Element", "Size", "Weight", "Line Height"]
+            columns: ["元素", "大小", "字重", "行高"]
             rows:
               - ["H1", "{{h1_size}}", "{{h1_weight}}", "{{h1_line}}"]
               - ["H2", "{{h2_size}}", "{{h2_weight}}", "{{h2_line}}"]
               - ["H3", "{{h3_size}}", "{{h3_weight}}", "{{h3_line}}"]
-              - ["Body", "{{body_size}}", "{{body_weight}}", "{{body_line}}"]
+              - ["正文", "{{body_size}}", "{{body_weight}}", "{{body_line}}"]
-              - ["Small", "{{small_size}}", "{{small_weight}}", "{{small_line}}"]
+              - ["小号", "{{small_size}}", "{{small_weight}}", "{{small_line}}"]
       - id: iconography
-        title: Iconography
+        title: 图标
         template: |
-          **Icon Library:** {{icon_library}}
+          **图标库：** {{icon_library}}
 
-          **Usage Guidelines:** {{icon_guidelines}}
+          **使用指南：** {{icon_guidelines}}
       - id: spacing-layout
-        title: Spacing & Layout
+        title: 间距与布局
         template: |
-          **Grid System:** {{grid_system}}
+          **网格系统：** {{grid_system}}
 
-          **Spacing Scale:** {{spacing_scale}}
+          **间距比例：** {{spacing_scale}}
 
   - id: accessibility
-    title: Accessibility Requirements
+    title: 可访问性要求
-    instruction: Define specific accessibility requirements based on target compliance level and user needs. Be comprehensive but practical.
+    instruction: 根据目标合规级别和用户需求定义具体的可访问性要求。要全面但实用。
     elicit: true
     sections:
       - id: compliance-target
-        title: Compliance Target
+        title: 合规目标
-        template: "**Standard:** {{compliance_standard}}"
+        template: "**标准：** {{compliance_standard}}"
       - id: key-requirements
-        title: Key Requirements
+        title: 关键要求
         template: |
-          **Visual:**
+          **视觉：**
-          - Color contrast ratios: {{contrast_requirements}}
+          - 颜色对比度：{{contrast_requirements}}
-          - Focus indicators: {{focus_requirements}}
+          - 焦点指示器：{{focus_requirements}}
-          - Text sizing: {{text_requirements}}
+          - 文本大小：{{text_requirements}}
 
-          **Interaction:**
+          **交互：**
-          - Keyboard navigation: {{keyboard_requirements}}
+          - 键盘导航：{{keyboard_requirements}}
-          - Screen reader support: {{screen_reader_requirements}}
+          - 屏幕阅读器支持：{{screen_reader_requirements}}
-          - Touch targets: {{touch_requirements}}
+          - 触摸目标：{{touch_requirements}}
 
-          **Content:**
+          **内容：**
-          - Alternative text: {{alt_text_requirements}}
+          - 替代文本：{{alt_text_requirements}}
-          - Heading structure: {{heading_requirements}}
+          - 标题结构：{{heading_requirements}}
-          - Form labels: {{form_requirements}}
+          - 表单标签：{{form_requirements}}
       - id: testing-strategy
-        title: Testing Strategy
+        title: 测试策略
         template: "{{accessibility_testing}}"
 
   - id: responsiveness
-    title: Responsiveness Strategy
+    title: 响应式策略
-    instruction: Define breakpoints and adaptation strategies for different device sizes. Consider both technical constraints and user contexts.
+    instruction: 定义不同设备尺寸的断点和适应策略。同时考虑技术约束和用户上下文。
     elicit: true
     sections:
       - id: breakpoints
-        title: Breakpoints
+        title: 断点
         type: table
-        columns: ["Breakpoint", "Min Width", "Max Width", "Target Devices"]
+        columns: ["断点", "最小宽度", "最大宽度", "目标设备"]
         rows:
-          - ["Mobile", "{{mobile_min}}", "{{mobile_max}}", "{{mobile_devices}}"]
+          - ["手机", "{{mobile_min}}", "{{mobile_max}}", "{{mobile_devices}}"]
-          - ["Tablet", "{{tablet_min}}", "{{tablet_max}}", "{{tablet_devices}}"]
+          - ["平板", "{{tablet_min}}", "{{tablet_max}}", "{{tablet_devices}}"]
-          - ["Desktop", "{{desktop_min}}", "{{desktop_max}}", "{{desktop_devices}}"]
+          - ["桌面", "{{desktop_min}}", "{{desktop_max}}", "{{desktop_devices}}"]
-          - ["Wide", "{{wide_min}}", "-", "{{wide_devices}}"]
+          - ["宽屏", "{{wide_min}}", "-", "{{wide_devices}}"]
       - id: adaptation-patterns
-        title: Adaptation Patterns
+        title: 适应模式
         template: |
-          **Layout Changes:** {{layout_adaptations}}
+          **布局变更：** {{layout_adaptations}}
 
-          **Navigation Changes:** {{nav_adaptations}}
+          **导航变更：** {{nav_adaptations}}
 
-          **Content Priority:** {{content_adaptations}}
+          **内容优先级：** {{content_adaptations}}
 
-          **Interaction Changes:** {{interaction_adaptations}}
+          **交互变更：** {{interaction_adaptations}}
 
   - id: animation
-    title: Animation & Micro-interactions
+    title: 动画与微交互
-    instruction: Define motion design principles and key interactions. Keep performance and accessibility in mind.
+    instruction: 定义动效设计原则和关键交互。牢记性能和可访问性。
     elicit: true
     sections:
       - id: motion-principles
-        title: Motion Principles
+        title: 动效原则
         template: "{{motion_principles}}"
       - id: key-animations
-        title: Key Animations
+        title: 关键动画
         repeatable: true
-        template: "- **{{animation_name}}:** {{animation_description}} (Duration: {{duration}}, Easing: {{easing}})"
+        template: "- **{{animation_name}}:** {{animation_description}} (持续时间: {{duration}}, 缓动: {{easing}})"
 
   - id: performance
-    title: Performance Considerations
+    title: 性能考虑
-    instruction: Define performance goals and strategies that impact UX design decisions.
+    instruction: 定义影响UX设计决策的性能目标和策略。
     sections:
       - id: performance-goals
-        title: Performance Goals
+        title: 性能目标
         template: |
-          - **Page Load:** {{load_time_goal}}
+          - **页面加载：** {{load_time_goal}}
-          - **Interaction Response:** {{interaction_goal}}
+          - **交互响应：** {{interaction_goal}}
-          - **Animation FPS:** {{animation_goal}}
+          - **动画FPS：** {{animation_goal}}
       - id: design-strategies
-        title: Design Strategies
+        title: 设计策略
         template: "{{performance_strategies}}"
 
   - id: next-steps
-    title: Next Steps
+    title: 下一步
     instruction: |
-      After completing the UI/UX specification:
+      完成UI/UX规范后：
 
-      1. Recommend review with stakeholders
+      1. 建议与利益相关者审查
-      2. Suggest creating/updating visual designs in design tool
+      2. 建议在设计工具中创建/更新视觉设计
-      3. Prepare for handoff to Design Architect for frontend architecture
+      3. 准备交接给设计架构师进行前端架构设计
-      4. Note any open questions or decisions needed
+      4. 注意任何悬而未决的问题或需要做出的决定
     sections:
       - id: immediate-actions
-        title: Immediate Actions
+        title: 立即行动
         type: numbered-list
         template: "{{action}}"
       - id: design-handoff-checklist
-        title: Design Handoff Checklist
+        title: 设计交接清单
         type: checklist
         items:
-          - "All user flows documented"
+          - "所有用户流程已记录"
-          - "Component inventory complete"
+          - "组件清单已完成"
-          - "Accessibility requirements defined"
+          - "可访问性要求已定义"
-          - "Responsive strategy clear"
+          - "响应式策略清晰"
-          - "Brand guidelines incorporated"
+          - "品牌指南已纳入"
-          - "Performance goals established"
+          - "性能目标已建立"
 
   - id: checklist-results
-    title: Checklist Results
+    title: 清单结果
-    instruction: If a UI/UX checklist exists, run it against this document and report results here.
+    instruction: 如果存在UI/UX清单，请根据此文档运行并在此处报告结果。

bmad-core/templates/market-research-tmpl.yaml

@@ -1,253 +1,253 @@
-# <!-- Powered by BMAD™ Core -->
+# <!-- 由 BMAD™ Core 驱动 -->
 template:
   id: market-research-template-v2
-  name: Market Research Report
+  name: 市场研究报告
   version: 2.0
   output:
     format: markdown
     filename: docs/market-research.md
-    title: "Market Research Report: {{project_product_name}}"
+    title: "市场研究报告：{{project_product_name}}"
 
 workflow:
   mode: interactive
   elicitation: advanced-elicitation
   custom_elicitation:
-    title: "Market Research Elicitation Actions"
+    title: "市场研究启发行动"
     options:
-      - "Expand market sizing calculations with sensitivity analysis"
+      - "通过敏感性分析扩展市场规模计算"
-      - "Deep dive into a specific customer segment"
+      - "深入研究特定客户细分"
-      - "Analyze an emerging market trend in detail"
+      - "详细分析新兴市场趋势"
-      - "Compare this market to an analogous market"
+      - "将此市场与类似市场进行比较"
-      - "Stress test market assumptions"
+      - "压力测试市场假设"
-      - "Explore adjacent market opportunities"
+      - "探索邻近市场机会"
-      - "Challenge market definition and boundaries"
+      - "挑战市场定义和边界"
-      - "Generate strategic scenarios (best/base/worst case)"
+      - "生成战略情景（最佳/基本/最差情况）"
-      - "If only we had considered [X market factor]..."
+      - "如果我们当初考虑了[X市场因素]..."
-      - "Proceed to next section"
+      - "进入下一节"
 
 sections:
   - id: executive-summary
-    title: Executive Summary
+    title: 执行摘要
-    instruction: Provide a high-level overview of key findings, market opportunity assessment, and strategic recommendations. Write this section LAST after completing all other sections.
+    instruction: 提供关键发现、市场机会评估和战略建议的高层概述。在完成所有其他部分后最后撰写此部分。
 
   - id: research-objectives
-    title: Research Objectives & Methodology
+    title: 研究目标与方法论
-    instruction: This template guides the creation of a comprehensive market research report. Begin by understanding what market insights the user needs and why. Work through each section systematically, using the appropriate analytical frameworks based on the research objectives.
+    instruction: 此模板指导创建全面的市场研究报告。首先了解用户需要哪些市场见解以及原因。系统地完成每个部分，根据研究目标使用适当的分析框架。
     sections:
       - id: objectives
-        title: Research Objectives
+        title: 研究目标
         instruction: |
-          List the primary objectives of this market research:
+          列出此市场研究的主要目标：
-          - What decisions will this research inform?
+          - 此研究将为哪些决策提供信息？
-          - What specific questions need to be answered?
+          - 需要回答哪些具体问题？
-          - What are the success criteria for this research?
+          - 此研究的成功标准是什么？
       - id: methodology
-        title: Research Methodology
+        title: 研究方法论
         instruction: |
-          Describe the research approach:
+          描述研究方法：
-          - Data sources used (primary/secondary)
+          - 使用的数据来源（一手/二手）
-          - Analysis frameworks applied
+          - 应用的分析框架
-          - Data collection timeframe
+          - 数据收集时间范围
-          - Limitations and assumptions
+          - 局限性和假设
 
   - id: market-overview
-    title: Market Overview
+    title: 市场概述
     sections:
       - id: market-definition
-        title: Market Definition
+        title: 市场定义
         instruction: |
-          Define the market being analyzed:
+          定义正在分析的市场：
-          - Product/service category
+          - 产品/服务类别
-          - Geographic scope
+          - 地理范围
-          - Customer segments included
+          - 包括的客户细分
-          - Value chain position
+          - 价值链位置
       - id: market-size-growth
-        title: Market Size & Growth
+        title: 市场规模与增长
         instruction: |
-          Guide through TAM, SAM, SOM calculations with clear assumptions. Use one or more approaches:
+          通过明确的假设指导TAM、SAM、SOM的计算。使用一种或多种方法：
-          - Top-down: Start with industry data, narrow down
+          - 自上而下：从行业数据开始，逐步缩小范围
-          - Bottom-up: Build from customer/unit economics
+          - 自下而上：从客户/单位经济学构建
-          - Value theory: Based on value provided vs. alternatives
+          - 价值理论：基于提供的价值与替代方案
         sections:
           - id: tam
-            title: Total Addressable Market (TAM)
+            title: 总可寻址市场 (TAM)
-            instruction: Calculate and explain the total market opportunity
+            instruction: 计算并解释总市场机会
           - id: sam
-            title: Serviceable Addressable Market (SAM)
+            title: 可服务可寻址市场 (SAM)
-            instruction: Define the portion of TAM you can realistically reach
+            instruction: 定义您可以实际接触到的TAM部分
           - id: som
-            title: Serviceable Obtainable Market (SOM)
+            title: 可服务可获得市场 (SOM)
-            instruction: Estimate the portion you can realistically capture
+            instruction: 估计您可以实际捕获的部分
       - id: market-trends
-        title: Market Trends & Drivers
+        title: 市场趋势与驱动因素
-        instruction: Analyze key trends shaping the market using appropriate frameworks like PESTEL
+        instruction: 使用PESTEL等适当框架分析塑造市场的关键趋势
         sections:
           - id: key-trends
-            title: Key Market Trends
+            title: 关键市场趋势
             instruction: |
-              List and explain 3-5 major trends:
+              列出并解释3-5个主要趋势：
-              - Trend 1: Description and impact
+              - 趋势1：描述和影响
-              - Trend 2: Description and impact
+              - 趋势2：描述和影响
-              - etc.
+              - 等等。
           - id: growth-drivers
-            title: Growth Drivers
+            title: 增长驱动因素
-            instruction: Identify primary factors driving market growth
+            instruction: 识别推动市场增长的主要因素
           - id: market-inhibitors
-            title: Market Inhibitors
+            title: 市场抑制因素
-            instruction: Identify factors constraining market growth
+            instruction: 识别限制市场增长的因素
 
   - id: customer-analysis
-    title: Customer Analysis
+    title: 客户分析
     sections:
       - id: segment-profiles
-        title: Target Segment Profiles
+        title: 目标细分市场简介
-        instruction: For each segment, create detailed profiles including demographics/firmographics, psychographics, behaviors, needs, and willingness to pay
+        instruction: 为每个细分市场创建详细的简介，包括人口统计/公司统计、心理统计、行为、需求和支付意愿
         repeatable: true
         sections:
           - id: segment
-            title: "Segment {{segment_number}}: {{segment_name}}"
+            title: "细分市场 {{segment_number}}: {{segment_name}}"
             template: |
-              - **Description:** {{brief_overview}}
+              - **描述：** {{brief_overview}}
-              - **Size:** {{number_of_customers_market_value}}
+              - **规模：** {{number_of_customers_market_value}}
-              - **Characteristics:** {{key_demographics_firmographics}}
+              - **特征：** {{key_demographics_firmographics}}
-              - **Needs & Pain Points:** {{primary_problems}}
+              - **需求与痛点：** {{primary_problems}}
-              - **Buying Process:** {{purchasing_decisions}}
+              - **购买过程：** {{purchasing_decisions}}
-              - **Willingness to Pay:** {{price_sensitivity}}
+              - **支付意愿：** {{price_sensitivity}}
       - id: jobs-to-be-done
-        title: Jobs-to-be-Done Analysis
+        title: 待办任务分析
-        instruction: Uncover what customers are really trying to accomplish
+        instruction: 揭示客户真正想要完成的事情
         sections:
           - id: functional-jobs
-            title: Functional Jobs
+            title: 功能性任务
-            instruction: List practical tasks and objectives customers need to complete
+            instruction: 列出客户需要完成的实际任务和目标
           - id: emotional-jobs
-            title: Emotional Jobs
+            title: 情感性任务
-            instruction: Describe feelings and perceptions customers seek
+            instruction: 描述客户寻求的感觉和看法
           - id: social-jobs
-            title: Social Jobs
+            title: 社交性任务
-            instruction: Explain how customers want to be perceived by others
+            instruction: 解释客户希望如何被他人看待
       - id: customer-journey
-        title: Customer Journey Mapping
+        title: 客户旅程图
-        instruction: Map the end-to-end customer experience for primary segments
+        instruction: 为主要细分市场绘制端到端的客户体验图
         template: |
-          For primary customer segment:
+          对于主要客户细分市场：
 
-          1. **Awareness:** {{discovery_process}}
+          1. **认知：** {{discovery_process}}
-          2. **Consideration:** {{evaluation_criteria}}
+          2. **考虑：** {{evaluation_criteria}}
-          3. **Purchase:** {{decision_triggers}}
+          3. **购买：** {{decision_triggers}}
-          4. **Onboarding:** {{initial_expectations}}
+          4. **上手：** {{initial_expectations}}
-          5. **Usage:** {{interaction_patterns}}
+          5. **使用：** {{interaction_patterns}}
-          6. **Advocacy:** {{referral_behaviors}}
+          6. **拥护：** {{referral_behaviors}}
 
   - id: competitive-landscape
-    title: Competitive Landscape
+    title: 竞争格局
     sections:
       - id: market-structure
-        title: Market Structure
+        title: 市场结构
         instruction: |
-          Describe the overall competitive environment:
+          描述整体竞争环境：
-          - Number of competitors
+          - 竞争对手数量
-          - Market concentration
+          - 市场集中度
-          - Competitive intensity
+          - 竞争激烈程度
       - id: major-players
-        title: Major Players Analysis
+        title: 主要参与者分析
         instruction: |
-          For top 3-5 competitors:
+          对于前3-5名竞争对手：
-          - Company name and brief description
+          - 公司名称和简要描述
-          - Market share estimate
+          - 市场份额估计
-          - Key strengths and weaknesses
+          - 关键优势和劣势
-          - Target customer focus
+          - 目标客户重点
-          - Pricing strategy
+          - 定价策略
       - id: competitive-positioning
-        title: Competitive Positioning
+        title: 竞争定位
         instruction: |
-          Analyze how competitors are positioned:
+          分析竞争对手的定位：
-          - Value propositions
+          - 价值主张
-          - Differentiation strategies
+          - 差异化策略
-          - Market gaps and opportunities
+          - 市场差距和机会
 
   - id: industry-analysis
-    title: Industry Analysis
+    title: 行业分析
     sections:
       - id: porters-five-forces
-        title: Porter's Five Forces Assessment
+        title: 波特五力评估
-        instruction: Analyze each force with specific evidence and implications
+        instruction: 用具体证据和影响分析每一种力量
         sections:
           - id: supplier-power
-            title: "Supplier Power: {{power_level}}"
+            title: "供应商议价能力：{{power_level}}"
             template: "{{analysis_and_implications}}"
           - id: buyer-power
-            title: "Buyer Power: {{power_level}}"
+            title: "购买者议价能力：{{power_level}}"
             template: "{{analysis_and_implications}}"
           - id: competitive-rivalry
-            title: "Competitive Rivalry: {{intensity_level}}"
+            title: "竞争激烈程度：{{intensity_level}}"
             template: "{{analysis_and_implications}}"
           - id: threat-new-entry
-            title: "Threat of New Entry: {{threat_level}}"
+            title: "新进入者的威胁：{{threat_level}}"
             template: "{{analysis_and_implications}}"
           - id: threat-substitutes
-            title: "Threat of Substitutes: {{threat_level}}"
+            title: "替代品的威胁：{{threat_level}}"
             template: "{{analysis_and_implications}}"
       - id: adoption-lifecycle
-        title: Technology Adoption Lifecycle Stage
+        title: 技术采纳生命周期阶段
         instruction: |
-          Identify where the market is in the adoption curve:
+          识别市场处于采纳曲线的哪个阶段：
-          - Current stage and evidence
+          - 当前阶段和证据
-          - Implications for strategy
+          - 对策略的影响
-          - Expected progression timeline
+          - 预期的进展时间线
 
   - id: opportunity-assessment
-    title: Opportunity Assessment
+    title: 机会评估
     sections:
       - id: market-opportunities
-        title: Market Opportunities
+        title: 市场机会
-        instruction: Identify specific opportunities based on the analysis
+        instruction: 根据分析识别具体机会
         repeatable: true
         sections:
           - id: opportunity
-            title: "Opportunity {{opportunity_number}}: {{name}}"
+            title: "机会 {{opportunity_number}}: {{name}}"
             template: |
-              - **Description:** {{what_is_the_opportunity}}
+              - **描述：** {{what_is_the_opportunity}}
-              - **Size/Potential:** {{quantified_potential}}
+              - **规模/潜力：** {{quantified_potential}}
-              - **Requirements:** {{needed_to_capture}}
+              - **要求：** {{needed_to_capture}}
-              - **Risks:** {{key_challenges}}
+              - **风险：** {{key_challenges}}
       - id: strategic-recommendations
-        title: Strategic Recommendations
+        title: 战略建议
         sections:
           - id: go-to-market
-            title: Go-to-Market Strategy
+            title: 市场进入策略
             instruction: |
-              Recommend approach for market entry/expansion:
+              推荐市场进入/扩张的方法：
-              - Target segment prioritization
+              - 目标细分市场优先级
-              - Positioning strategy
+              - 定位策略
-              - Channel strategy
+              - 渠道策略
-              - Partnership opportunities
+              - 合作机会
           - id: pricing-strategy
-            title: Pricing Strategy
+            title: 定价策略
             instruction: |
-              Based on willingness to pay analysis and competitive landscape:
+              基于支付意愿分析和竞争格局：
-              - Recommended pricing model
+              - 推荐的定价模型
-              - Price points/ranges
+              - 价格点/范围
-              - Value metric
+              - 价值指标
-              - Competitive positioning
+              - 竞争定位
           - id: risk-mitigation
-            title: Risk Mitigation
+            title: 风险缓解
             instruction: |
-              Key risks and mitigation strategies:
+              关键风险和缓解策略：
-              - Market risks
+              - 市场风险
-              - Competitive risks
+              - 竞争风险
-              - Execution risks
+              - 执行风险
-              - Regulatory/compliance risks
+              - 法规/合规风险
 
   - id: appendices
-    title: Appendices
+    title: 附录
     sections:
       - id: data-sources
-        title: A. Data Sources
+        title: A. 数据来源
-        instruction: List all sources used in the research
+        instruction: 列出研究中使用的所有来源
       - id: calculations
-        title: B. Detailed Calculations
+        title: B. 详细计算
-        instruction: Include any complex calculations or models
+        instruction: 包括任何复杂的计算或模型
       - id: additional-analysis
-        title: C. Additional Analysis
+        title: C. 附加分析
-        instruction: Any supplementary analysis not included in main body
+        instruction: 未包含在正文中的任何补充分析

bmad-core/templates/prd-tmpl.yaml

@@ -1,12 +1,12 @@
-# <!-- Powered by BMAD™ Core -->
+# <!-- 由 BMAD™ Core 驱动 -->
 template:
   id: prd-template-v2
-  name: Product Requirements Document
+  name: 产品需求文档
   version: 2.0
   output:
     format: markdown
     filename: docs/prd.md
-    title: "{{project_name}} Product Requirements Document (PRD)"
+    title: "{{project_name}} 产品需求文档 (PRD)"
 
 workflow:
   mode: interactive
@@ -14,190 +14,190 @@ workflow:
 
 sections:
   - id: goals-context
-    title: Goals and Background Context
+    title: 目标和背景
     instruction: |
-      Ask if Project Brief document is available. If NO Project Brief exists, STRONGLY recommend creating one first using project-brief-tmpl (it provides essential foundation: problem statement, target users, success metrics, MVP scope, constraints). If user insists on PRD without brief, gather this information during Goals section. If Project Brief exists, review and use it to populate Goals (bullet list of desired outcomes) and Background Context (1-2 paragraphs on what this solves and why) so we can determine what is and is not in scope for PRD mvp. Either way this is critical to determine the requirements. Include Change Log table.
+      询问项目简报是否可用。如果不存在项目简报，强烈建议首先使用project-brief-tmpl创建一个（它提供了基本的基础：问题陈述、目标用户、成功指标、MVP范围、约束）。如果用户坚持在没有简报的情况下制定PRD，则在“目标”部分收集此信息。如果存在项目简报，请审查并使用它来填充“目标”（所需结果的要点列表）和“背景”（关于此解决方案解决什么问题以及为什么的1-2段），以便我们确定PRD mvp的范围。无论哪种方式，这对于确定需求都至关重要。包括变更日志表。
     sections:
       - id: goals
-        title: Goals
+        title: 目标
         type: bullet-list
-        instruction: Bullet list of 1 line desired outcomes the PRD will deliver if successful - user and project desires
+        instruction: 如果成功，PRD将交付的一行所需结果的要点列表 - 用户和项目的愿望
       - id: background
-        title: Background Context
+        title: 背景
         type: paragraphs
-        instruction: 1-2 short paragraphs summarizing the background context, such as what we learned in the brief without being redundant with the goals, what and why this solves a problem, what the current landscape or need is
+        instruction: 1-2个简短段落，总结背景，例如我们在简报中学到的内容，而不会与目标重复，这解决了什么问题以及为什么，当前的格局或需求是什么
       - id: changelog
-        title: Change Log
+        title: 变更日志
         type: table
-        columns: [Date, Version, Description, Author]
+        columns: [日期, 版本, 描述, 作者]
-        instruction: Track document versions and changes
+        instruction: 跟踪文档版本和变更
 
   - id: requirements
-    title: Requirements
+    title: 需求
-    instruction: Draft the list of functional and non functional requirements under the two child sections
+    instruction: 在两个子部分下起草功能性和非功能性需求的列表
     elicit: true
     sections:
       - id: functional
-        title: Functional
+        title: 功能性
         type: numbered-list
         prefix: FR
-        instruction: Each Requirement will be a bullet markdown and an identifier sequence starting with FR
+        instruction: 每个需求都将是一个markdown项目符号，并带有一个以FR开头的标识符序列
         examples:
-          - "FR6: The Todo List uses AI to detect and warn against potentially duplicate todo items that are worded differently."
+          - "FR6：待办事项列表使用AI检测并警告可能措辞不同但内容重复的待办事项。"
       - id: non-functional
-        title: Non Functional
+        title: 非功能性
         type: numbered-list
         prefix: NFR
-        instruction: Each Requirement will be a bullet markdown and an identifier sequence starting with NFR
+        instruction: 每个需求都将是一个markdown项目符号，并带有一个以NFR开头的标识符序列
         examples:
-          - "NFR1: AWS service usage must aim to stay within free-tier limits where feasible."
+          - "NFR1：在可行的情况下，AWS服务的使用必须旨在保持在免费套餐限制内。"
 
   - id: ui-goals
-    title: User Interface Design Goals
+    title: 用户界面设计目标
-    condition: PRD has UX/UI requirements
+    condition: PRD有UX/UI要求
     instruction: |
-      Capture high-level UI/UX vision to guide Design Architect and to inform story creation. Steps:
+      捕获高层UI/UX愿景，以指导设计架构师并为故事创建提供信息。步骤：
 
-      1. Pre-fill all subsections with educated guesses based on project context
+      1. 根据项目背景，用有根据的猜测预先填充所有小节
-      2. Present the complete rendered section to user
+      2. 向用户呈现完整的渲染部分
-      3. Clearly let the user know where assumptions were made
+      3. 明确告知用户在何处做出了假设
-      4. Ask targeted questions for unclear/missing elements or areas needing more specification
+      4. 针对不清楚/缺失的元素或需要更具体说明的领域提出有针对性的问题
-      5. This is NOT detailed UI spec - focus on product vision and user goals
+      5. 这不是详细的UI规范 - 专注于产品愿景和用户目标
     elicit: true
     choices:
-      accessibility: [None, WCAG AA, WCAG AAA]
+      accessibility: [无, WCAG AA, WCAG AAA]
-      platforms: [Web Responsive, Mobile Only, Desktop Only, Cross-Platform]
+      platforms: [Web响应式, 仅移动端, 仅桌面端, 跨平台]
     sections:
       - id: ux-vision
-        title: Overall UX Vision
+        title: 整体UX愿景
       - id: interaction-paradigms
-        title: Key Interaction Paradigms
+        title: 关键交互范式
       - id: core-screens
-        title: Core Screens and Views
+        title: 核心屏幕和视图
-        instruction: From a product perspective, what are the most critical screens or views necessary to deliver the the PRD values and goals? This is meant to be Conceptual High Level to Drive Rough Epic or User Stories
+        instruction: 从产品角度看，交付PRD价值和目标所需的最关键的屏幕或视图是什么？这是为了驱动粗略的史诗或用户故事的概念性高层设计
         examples:
-          - "Login Screen"
+          - "登录屏幕"
-          - "Main Dashboard"
+          - "主仪表板"
-          - "Item Detail Page"
+          - "项目详情页"
-          - "Settings Page"
+          - "设置页面"
       - id: accessibility
-        title: "Accessibility: {None|WCAG AA|WCAG AAA|Custom Requirements}"
+        title: "可访问性：{无|WCAG AA|WCAG AAA|自定义要求}"
       - id: branding
-        title: Branding
+        title: 品牌
-        instruction: Any known branding elements or style guides that must be incorporated?
+        instruction: 是否有任何已知的品牌元素或必须纳入的风格指南？
         examples:
-          - "Replicate the look and feel of early 1900s black and white cinema, including animated effects replicating film damage or projector glitches during page or state transitions."
+          - "复制20世纪初黑白电影的外观和感觉，包括在页面或状态转换期间复制胶片损坏或投影仪故障的动画效果。"
-          - "Attached is the full color pallet and tokens for our corporate branding."
+          - "附件是我们公司品牌的完整调色板和令牌。"
       - id: target-platforms
-        title: "Target Device and Platforms: {Web Responsive|Mobile Only|Desktop Only|Cross-Platform}"
+        title: "目标设备和平台：{Web响应式|仅移动端|仅桌面端|跨平台}"
         examples:
-          - "Web Responsive, and all mobile platforms"
+          - "Web响应式，以及所有移动平台"
-          - "iPhone Only"
+          - "仅限iPhone"
-          - "ASCII Windows Desktop"
+          - "ASCII Windows桌面"
 
   - id: technical-assumptions
-    title: Technical Assumptions
+    title: 技术假设
     instruction: |
-      Gather technical decisions that will guide the Architect. Steps:
+      收集将指导架构师的技术决策。步骤：
 
-      1. Check if {root}/data/technical-preferences.yaml or an attached technical-preferences file exists - use it to pre-populate choices
+      1. 检查{root}/data/technical-preferences.yaml或附加的technical-preferences文件是否存在 - 用它来预填充选项
-      2. Ask user about: languages, frameworks, starter templates, libraries, APIs, deployment targets
+      2. 询问用户关于：语言、框架、入门模板、库、API、部署目标
-      3. For unknowns, offer guidance based on project goals and MVP scope
+      3. 对于未知数，根据项目目标和MVP范围提供指导
-      4. Document ALL technical choices with rationale (why this choice fits the project)
+      4. 记录所有技术选择及其理由（为什么这个选择适合项目）
-      5. These become constraints for the Architect - be specific and complete
+      5. 这些成为架构师的约束 - 要具体和完整
     elicit: true
     choices:
-      repository: [Monorepo, Polyrepo]
+      repository: [单体仓库, 多仓库]
-      architecture: [Monolith, Microservices, Serverless]
+      architecture: [单体, 微服务, 无服务器]
-      testing: [Unit Only, Unit + Integration, Full Testing Pyramid]
+      testing: [仅单元测试, 单元+集成, 完整测试金字塔]
     sections:
       - id: repository-structure
-        title: "Repository Structure: {Monorepo|Polyrepo|Multi-repo}"
+        title: "存储库结构：{单体仓库|多仓库|多仓库}"
       - id: service-architecture
-        title: Service Architecture
+        title: 服务架构
-        instruction: "CRITICAL DECISION - Document the high-level service architecture (e.g., Monolith, Microservices, Serverless functions within a Monorepo)."
+        instruction: "关键决策 - 记录高层服务架构（例如，单体、微服务、Monorepo中的无服务器函数）。"
       - id: testing-requirements
-        title: Testing Requirements
+        title: 测试要求
-        instruction: "CRITICAL DECISION - Document the testing requirements, unit only, integration, e2e, manual, need for manual testing convenience methods)."
+        instruction: "关键决策 - 记录测试要求，仅单元测试、集成、端到端、手动、是否需要手动测试的便利方法）。"
       - id: additional-assumptions
-        title: Additional Technical Assumptions and Requests
+        title: 附加技术假设和请求
-        instruction: Throughout the entire process of drafting this document, if any other technical assumptions are raised or discovered appropriate for the architect, add them here as additional bulleted items
+        instruction: 在起草本文件的整个过程中，如果提出或发现任何其他适合架构师的技术假设，请在此处作为附加项目符号添加
 
   - id: epic-list
-    title: Epic List
+    title: 史诗列表
     instruction: |
-      Present a high-level list of all epics for user approval. Each epic should have a title and a short (1 sentence) goal statement. This allows the user to review the overall structure before diving into details.
+      向用户提交一份高层史诗列表以供批准。每个史诗都应有一个标题和一个简短的（1句话）目标陈述。这允许用户在深入了解细节之前审查整体结构。
 
-      CRITICAL: Epics MUST be logically sequential following agile best practices:
+      关键：史诗必须遵循敏捷最佳实践，按逻辑顺序排列：
 
-      - Each epic should deliver a significant, end-to-end, fully deployable increment of testable functionality
+      - 每个史诗都应交付一个重要的、端到端的、完全可部署的可测试功能增量
-      - Epic 1 must establish foundational project infrastructure (app setup, Git, CI/CD, core services) unless we are adding new functionality to an existing app, while also delivering an initial piece of functionality, even as simple as a health-check route or display of a simple canary page - remember this when we produce the stories for the first epic!
+      - 史诗1必须建立基础项目基础设施（应用程序设置、Git、CI/CD、核心服务），除非我们正在向现有应用程序添加新功能，同时还要交付一个初始功能，即使只是一个健康检查路由或显示一个简单的金丝雀页面 - 在我们为第一个史诗制作故事时请记住这一点！
-      - Each subsequent epic builds upon previous epics' functionality delivering major blocks of functionality that provide tangible value to users or business when deployed
+      - 每个后续史诗都在先前史诗功能的基础上构建，交付在部署时为用户或业务提供切实价值的主要功能块
-      - Not every project needs multiple epics, an epic needs to deliver value. For example, an API completed can deliver value even if a UI is not complete and planned for a separate epic.
+      - 并非每个项目都需要多个史诗，史诗需要交付价值。例如，一个已完成的API即使UI未完成并计划在单独的史诗中，也可以交付价值。
-      - Err on the side of less epics, but let the user know your rationale and offer options for splitting them if it seems some are too large or focused on disparate things.
+      - 倾向于较少的史诗，但要让用户知道您的理由，并提供拆分它们的选项，如果有些史诗看起来太大或专注于不同的事情。
-      - Cross Cutting Concerns should flow through epics and stories and not be final stories. For example, adding a logging framework as a last story of an epic, or at the end of a project as a final epic or story would be terrible as we would not have logging from the beginning.
+      - 跨领域关注点应贯穿史诗和故事，而不是最终的故事。例如，将日志框架作为史诗的最后一个故事，或在项目结束时作为最终的史诗或故事添加，将是糟糕的，因为我们从一开始就没有日志记录。
     elicit: true
     examples:
-      - "Epic 1: Foundation & Core Infrastructure: Establish project setup, authentication, and basic user management"
+      - "史诗1：基础与核心基础设施：建立项目设置、身份验证和基本用户管理"
-      - "Epic 2: Core Business Entities: Create and manage primary domain objects with CRUD operations"
+      - "史诗2：核心业务实体：通过CRUD操作创建和管理主要领域对象"
-      - "Epic 3: User Workflows & Interactions: Enable key user journeys and business processes"
+      - "史诗3：用户工作流与交互：启用关键用户旅程和业务流程"
-      - "Epic 4: Reporting & Analytics: Provide insights and data visualization for users"
+      - "史诗4：报告与分析：为用户提供见解和数据可视化"
 
   - id: epic-details
-    title: Epic {{epic_number}} {{epic_title}}
+    title: 史诗 {{epic_number}} {{epic_title}}
     repeatable: true
     instruction: |
-      After the epic list is approved, present each epic with all its stories and acceptance criteria as a complete review unit.
+      史诗列表获得批准后，将每个史诗及其所有故事和验收标准作为一个完整的审查单元呈现。
 
-      For each epic provide expanded goal (2-3 sentences describing the objective and value all the stories will achieve).
+      为每个史诗提供扩展的目标（2-3句话描述所有故事将实现的目标和价值）。
 
-      CRITICAL STORY SEQUENCING REQUIREMENTS:
+      关键故事排序要求：
 
-      - Stories within each epic MUST be logically sequential
+      - 每个史诗中的故事必须按逻辑顺序排列
-      - Each story should be a "vertical slice" delivering complete functionality aside from early enabler stories for project foundation
+      - 除了项目基础的早期促成者故事外，每个故事都应是一个“垂直切片”，交付完整的功能
-      - No story should depend on work from a later story or epic
+      - 任何故事都不应依赖于后续故事或史诗的工作
-      - Identify and note any direct prerequisite stories
+      - 识别并注明任何直接的先决条件故事
-      - Focus on "what" and "why" not "how" (leave technical implementation to Architect) yet be precise enough to support a logical sequential order of operations from story to story.
+      - 专注于“什么”和“为什么”，而不是“如何”（将技术实现留给架构师），但要足够精确以支持从一个故事到另一个故事的逻辑顺序操作。
-      - Ensure each story delivers clear user or business value, try to avoid enablers and build them into stories that deliver value.
+      - 确保每个故事都交付明确的用户或业务价值，尽量避免促成者，并将其构建到交付价值的故事中。
-      - Size stories for AI agent execution: Each story must be completable by a single AI agent in one focused session without context overflow
+      - 为AI代理执行确定故事的大小：每个故事必须可以由单个AI代理在一个专注的会话中完成，而不会出现上下文溢出
-      - Think "junior developer working for 2-4 hours" - stories must be small, focused, and self-contained
+      - 想象“初级开发人员工作2-4小时” - 故事必须小、专注且自包含
-      - If a story seems complex, break it down further as long as it can deliver a vertical slice
+      - 如果一个故事看起来很复杂，只要它能交付一个垂直切片，就进一步分解它
     elicit: true
     template: "{{epic_goal}}"
     sections:
       - id: story
-        title: Story {{epic_number}}.{{story_number}} {{story_title}}
+        title: 故事 {{epic_number}}.{{story_number}} {{story_title}}
         repeatable: true
         template: |
-          As a {{user_type}},
+          作为一个{{user_type}}，
-          I want {{action}},
+          我想要{{action}}，
-          so that {{benefit}}.
+          以便{{benefit}}。
         sections:
           - id: acceptance-criteria
-            title: Acceptance Criteria
+            title: 验收标准
             type: numbered-list
             item_template: "{{criterion_number}}: {{criteria}}"
             repeatable: true
             instruction: |
-              Define clear, comprehensive, and testable acceptance criteria that:
+              定义清晰、全面且可测试的验收标准，以便：
 
-              - Precisely define what "done" means from a functional perspective
+              - 从功能角度精确定义“完成”的含义
-              - Are unambiguous and serve as basis for verification
+              - 明确无误，并作为验证的基础
-              - Include any critical non-functional requirements from the PRD
+              - 包括PRD中任何关键的非功能性需求
-              - Consider local testability for backend/data components
+              - 考虑后端/数据组件的本地可测试性
-              - Specify UI/UX requirements and framework adherence where applicable
+              - 在适用时指定UI/UX要求和框架遵守情况
-              - Avoid cross-cutting concerns that should be in other stories or PRD sections
+              - 避免应在其他故事或PRD部分中的跨领域关注点
 
   - id: checklist-results
-    title: Checklist Results Report
+    title: 清单结果报告
-    instruction: Before running the checklist and drafting the prompts, offer to output the full updated PRD. If outputting it, confirm with the user that you will be proceeding to run the checklist and produce the report. Once the user confirms, execute the pm-checklist and populate the results in this section.
+    instruction: 在运行清单和起草提示之前，提议输出完整的更新后PRD。如果输出，请与用户确认您将继续运行清单并生成报告。一旦用户确认，执行pm-checklist并在此部分填充结果。
 
   - id: next-steps
-    title: Next Steps
+    title: 下一步
     sections:
       - id: ux-expert-prompt
-        title: UX Expert Prompt
+        title: UX专家提示
-        instruction: This section will contain the prompt for the UX Expert, keep it short and to the point to initiate create architecture mode using this document as input.
+        instruction: 本节将包含给UX专家的提示，保持简短扼要，以启动使用本文档作为输入的创建架构模式。
       - id: architect-prompt
-        title: Architect Prompt
+        title: 架构师提示
-        instruction: This section will contain the prompt for the Architect, keep it short and to the point to initiate create architecture mode using this document as input.
+        instruction: 本节将包含给架构师的提示，保持简短扼要，以启动使用本文档作为输入的创建架构模式。

bmad-core/templates/project-brief-tmpl.yaml

@@ -1,222 +1,222 @@
-# <!-- Powered by BMAD™ Core -->
+# <!-- 由 BMAD™ Core 驱动 -->
 template:
   id: project-brief-template-v2
-  name: Project Brief
+  name: 项目简报
   version: 2.0
   output:
     format: markdown
     filename: docs/brief.md
-    title: "Project Brief: {{project_name}}"
+    title: "项目简报: {{project_name}}"
 
 workflow:
   mode: interactive
   elicitation: advanced-elicitation
   custom_elicitation:
-    title: "Project Brief Elicitation Actions"
+    title: "项目简报启发行动"
     options:
-      - "Expand section with more specific details"
+      - "用更具体的细节扩展章节"
-      - "Validate against similar successful products"
+      - "与类似的成功产品进行验证"
-      - "Stress test assumptions with edge cases"
+      - "用边缘案例对假设进行压力测试"
-      - "Explore alternative solution approaches"
+      - "探索替代解决方案"
-      - "Analyze resource/constraint trade-offs"
+      - "分析资源/约束的权衡"
-      - "Generate risk mitigation strategies"
+      - "生成风险缓解策略"
-      - "Challenge scope from MVP minimalist view"
+      - "从MVP极简主义视角挑战范围"
-      - "Brainstorm creative feature possibilities"
+      - "头脑风暴创意功能可能性"
-      - "If only we had [resource/capability/time]..."
+      - "如果我们有[资源/能力/时间]就好了..."
-      - "Proceed to next section"
+      - "进入下一节"
 
 sections:
   - id: introduction
     instruction: |
-      This template guides creation of a comprehensive Project Brief that serves as the foundational input for product development.
+      此模板指导创建全面的项目简报，作为产品开发的基础输入。
 
-      Start by asking the user which mode they prefer:
+      首先询问用户他们偏好哪种模式：
 
-      1. **Interactive Mode** - Work through each section collaboratively
+      1. **互动模式** - 协作完成每个章节
-      2. **YOLO Mode** - Generate complete draft for review and refinement
+      2. **YOLO模式** - 生成完整的草稿供审查和完善
 
-      Before beginning, understand what inputs are available (brainstorming results, market research, competitive analysis, initial ideas) and gather project context.
+      在开始之前，了解有哪些可用的输入（头脑风暴结果、市场研究、竞争分析、初步想法）并收集项目背景。
 
   - id: executive-summary
-    title: Executive Summary
+    title: 执行摘要
     instruction: |
-      Create a concise overview that captures the essence of the project. Include:
+      创建一个简洁的概述，抓住项目的精髓。包括：
-      - Product concept in 1-2 sentences
+      - 1-2句话的产品概念
-      - Primary problem being solved
+      - 正在解决的主要问题
-      - Target market identification
+      - 目标市场识别
-      - Key value proposition
+      - 关键价值主张
     template: "{{executive_summary_content}}"
 
   - id: problem-statement
-    title: Problem Statement
+    title: 问题陈述
     instruction: |
-      Articulate the problem with clarity and evidence. Address:
+      清晰并有证据地阐述问题。解决：
-      - Current state and pain points
+      - 当前状态和痛点
-      - Impact of the problem (quantify if possible)
+      - 问题的影响（如果可能，量化）
-      - Why existing solutions fall short
+      - 为什么现有解决方案不足
-      - Urgency and importance of solving this now
+      - 现在解决这个问题的紧迫性和重要性
     template: "{{detailed_problem_description}}"
 
   - id: proposed-solution
-    title: Proposed Solution
+    title: 提议的解决方案
     instruction: |
-      Describe the solution approach at a high level. Include:
+      高层次地描述解决方案。包括：
-      - Core concept and approach
+      - 核心概念和方法
-      - Key differentiators from existing solutions
+      - 与现有解决方案的关键差异化
-      - Why this solution will succeed where others haven't
+      - 为什么这个解决方案能在其他方案失败的地方成功
-      - High-level vision for the product
+      - 产品的高层愿景
     template: "{{solution_description}}"
 
   - id: target-users
-    title: Target Users
+    title: 目标用户
     instruction: |
-      Define and characterize the intended users with specificity. For each user segment include:
+      具体地定义和描述目标用户。对于每个用户细分，包括：
-      - Demographic/firmographic profile
+      - 人口统计/公司统计概况
-      - Current behaviors and workflows
+      - 当前行为和工作流程
-      - Specific needs and pain points
+      - 具体需求和痛点
-      - Goals they're trying to achieve
+      - 他们试图实现的目标
     sections:
       - id: primary-segment
-        title: "Primary User Segment: {{segment_name}}"
+        title: "主要用户细分：{{segment_name}}"
         template: "{{primary_user_description}}"
       - id: secondary-segment
-        title: "Secondary User Segment: {{segment_name}}"
+        title: "次要用户细分：{{segment_name}}"
-        condition: Has secondary user segment
+        condition: 有次要用户细分
         template: "{{secondary_user_description}}"
 
   - id: goals-metrics
-    title: Goals & Success Metrics
+    title: 目标与成功指标
-    instruction: Establish clear objectives and how to measure success. Make goals SMART (Specific, Measurable, Achievable, Relevant, Time-bound)
+    instruction: 建立明确的目标以及如何衡量成功。使目标SMART（具体的、可衡量的、可实现的、相关的、有时限的）
     sections:
       - id: business-objectives
-        title: Business Objectives
+        title: 业务目标
         type: bullet-list
         template: "- {{objective_with_metric}}"
       - id: user-success-metrics
-        title: User Success Metrics
+        title: 用户成功指标
         type: bullet-list
         template: "- {{user_metric}}"
       - id: kpis
-        title: Key Performance Indicators (KPIs)
+        title: 关键绩效指标 (KPIs)
         type: bullet-list
         template: "- {{kpi}}: {{definition_and_target}}"
 
   - id: mvp-scope
-    title: MVP Scope
+    title: MVP范围
-    instruction: Define the minimum viable product clearly. Be specific about what's in and what's out. Help user distinguish must-haves from nice-to-haves.
+    instruction: 明确定义最小可行产品。具体说明哪些在范围内，哪些不在。帮助用户区分必须有的和最好有的。
     sections:
       - id: core-features
-        title: Core Features (Must Have)
+        title: 核心功能（必须有）
         type: bullet-list
         template: "- **{{feature}}:** {{description_and_rationale}}"
       - id: out-of-scope
-        title: Out of Scope for MVP
+        title: MVP范围之外
         type: bullet-list
         template: "- {{feature_or_capability}}"
       - id: mvp-success-criteria
-        title: MVP Success Criteria
+        title: MVP成功标准
         template: "{{mvp_success_definition}}"
 
   - id: post-mvp-vision
-    title: Post-MVP Vision
+    title: MVP后愿景
-    instruction: Outline the longer-term product direction without overcommitting to specifics
+    instruction: 概述长期的产品方向，而不过多承诺具体细节
     sections:
       - id: phase-2-features
-        title: Phase 2 Features
+        title: 第二阶段功能
         template: "{{next_priority_features}}"
       - id: long-term-vision
-        title: Long-term Vision
+        title: 长期愿景
         template: "{{one_two_year_vision}}"
       - id: expansion-opportunities
-        title: Expansion Opportunities
+        title: 扩张机会
         template: "{{potential_expansions}}"
 
   - id: technical-considerations
-    title: Technical Considerations
+    title: 技术考虑
-    instruction: Document known technical constraints and preferences. Note these are initial thoughts, not final decisions.
+    instruction: 记录已知的技术约束和偏好。注意这些是初步想法，不是最终决定。
     sections:
       - id: platform-requirements
-        title: Platform Requirements
+        title: 平台要求
         template: |
-          - **Target Platforms:** {{platforms}}
+          - **目标平台：** {{platforms}}
-          - **Browser/OS Support:** {{specific_requirements}}
+          - **浏览器/操作系统支持：** {{specific_requirements}}
-          - **Performance Requirements:** {{performance_specs}}
+          - **性能要求：** {{performance_specs}}
       - id: technology-preferences
-        title: Technology Preferences
+        title: 技术偏好
         template: |
-          - **Frontend:** {{frontend_preferences}}
+          - **前端：** {{frontend_preferences}}
-          - **Backend:** {{backend_preferences}}
+          - **后端：** {{backend_preferences}}
-          - **Database:** {{database_preferences}}
+          - **数据库：** {{database_preferences}}
-          - **Hosting/Infrastructure:** {{infrastructure_preferences}}
+          - **托管/基础设施：** {{infrastructure_preferences}}
       - id: architecture-considerations
-        title: Architecture Considerations
+        title: 架构考虑
         template: |
-          - **Repository Structure:** {{repo_thoughts}}
+          - **存储库结构：** {{repo_thoughts}}
-          - **Service Architecture:** {{service_thoughts}}
+          - **服务架构：** {{service_thoughts}}
-          - **Integration Requirements:** {{integration_needs}}
+          - **集成要求：** {{integration_needs}}
-          - **Security/Compliance:** {{security_requirements}}
+          - **安全/合规：** {{security_requirements}}
 
   - id: constraints-assumptions
-    title: Constraints & Assumptions
+    title: 约束与假设
-    instruction: Clearly state limitations and assumptions to set realistic expectations
+    instruction: 明确陈述限制和假设，以设定切合实际的期望
     sections:
       - id: constraints
-        title: Constraints
+        title: 约束
         template: |
-          - **Budget:** {{budget_info}}
+          - **预算：** {{budget_info}}
-          - **Timeline:** {{timeline_info}}
+          - **时间线：** {{timeline_info}}
-          - **Resources:** {{resource_info}}
+          - **资源：** {{resource_info}}
-          - **Technical:** {{technical_constraints}}
+          - **技术：** {{technical_constraints}}
       - id: key-assumptions
-        title: Key Assumptions
+        title: 关键假设
         type: bullet-list
         template: "- {{assumption}}"
 
   - id: risks-questions
-    title: Risks & Open Questions
+    title: 风险与开放性问题
-    instruction: Identify unknowns and potential challenges proactively
+    instruction: 主动识别未知数和潜在挑战
     sections:
       - id: key-risks
-        title: Key Risks
+        title: 关键风险
         type: bullet-list
         template: "- **{{risk}}:** {{description_and_impact}}"
       - id: open-questions
-        title: Open Questions
+        title: 开放性问题
         type: bullet-list
         template: "- {{question}}"
       - id: research-areas
-        title: Areas Needing Further Research
+        title: 需要进一步研究的领域
         type: bullet-list
         template: "- {{research_topic}}"
 
   - id: appendices
-    title: Appendices
+    title: 附录
     sections:
       - id: research-summary
-        title: A. Research Summary
+        title: A. 研究摘要
-        condition: Has research findings
+        condition: 有研究发现
         instruction: |
-          If applicable, summarize key findings from:
+          如果适用，总结以下方面的关键发现：
-          - Market research
+          - 市场研究
-          - Competitive analysis
+          - 竞争分析
-          - User interviews
+          - 用户访谈
-          - Technical feasibility studies
+          - 技术可行性研究
       - id: stakeholder-input
-        title: B. Stakeholder Input
+        title: B. 利益相关者输入
-        condition: Has stakeholder feedback
+        condition: 有利益相关者反馈
         template: "{{stakeholder_feedback}}"
       - id: references
-        title: C. References
+        title: C. 参考资料
         template: "{{relevant_links_and_docs}}"
 
   - id: next-steps
-    title: Next Steps
+    title: 下一步
     sections:
       - id: immediate-actions
-        title: Immediate Actions
+        title: 立即行动
         type: numbered-list
         template: "{{action_item}}"
       - id: pm-handoff
-        title: PM Handoff
+        title: PM交接
         content: |
-          This Project Brief provides the full context for {{project_name}}. Please start in 'PRD Generation Mode', review the brief thoroughly to work with the user to create the PRD section by section as the template indicates, asking for any necessary clarification or suggesting improvements.
+          本项目简报为{{project_name}}提供了完整的背景。请以“PRD生成模式”开始，彻底审查简报，与用户合作，按照模板指示逐节创建PRD，要求任何必要的澄清或提出改进建议。

bmad-core/templates/qa-gate-tmpl.yaml

@@ -1,103 +1,103 @@
-# <!-- Powered by BMAD™ Core -->
+# <!-- 由 BMAD™ Core 驱动 -->
 template:
   id: qa-gate-template-v1
-  name: Quality Gate Decision
+  name: 质量门禁决策
   version: 1.0
   output:
     format: yaml
     filename: qa.qaLocation/gates/{{epic_num}}.{{story_num}}-{{story_slug}}.yml
-    title: "Quality Gate: {{epic_num}}.{{story_num}}"
+    title: "质量门禁：{{epic_num}}.{{story_num}}"
 
-# Required fields (keep these first)
+# 必填字段（保持这些在最前面）
 schema: 1
 story: "{{epic_num}}.{{story_num}}"
 story_title: "{{story_title}}"
 gate: "{{gate_status}}" # PASS|CONCERNS|FAIL|WAIVED
-status_reason: "{{status_reason}}" # 1-2 sentence summary of why this gate decision
+status_reason: "{{status_reason}}" # 1-2句话总结此门禁决策的原因
-reviewer: "Quinn (Test Architect)"
+reviewer: "Quinn (测试架构师)"
 updated: "{{iso_timestamp}}"
 
-# Always present but only active when WAIVED
+# 始终存在，但仅在WAIVED时激活
 waiver: { active: false }
 
-# Issues (if any) - Use fixed severity: low | medium | high
+# 问题（如果有） - 使用固定的严重性：low | medium | high
-top_issues: []
+top_issues: [] # 如果没有问题，则为空数组
 
-# Risk summary (from risk-profile task if run)
+# 风险摘要（如果运行了risk-profile任务）
 risk_summary:
   totals: { critical: 0, high: 0, medium: 0, low: 0 }
   recommendations:
     must_fix: []
     monitor: []
 
-# Examples section using block scalars for clarity
+# 使用块标量以求清晰的示例部分
 examples:
   with_issues: |
     top_issues:
       - id: "SEC-001"
-        severity: high  # ONLY: low|medium|high
+        severity: high  # 仅限：low|medium|high
-        finding: "No rate limiting on login endpoint"
+        finding: "登录端点上没有速率限制"
-        suggested_action: "Add rate limiting middleware before production"
+        suggested_action: "在生产前添加速率限制中间件"
       - id: "TEST-001"  
         severity: medium
-        finding: "Missing integration tests for auth flow"
+        finding: "认证流程缺少集成测试"
-        suggested_action: "Add test coverage for critical paths"
+        suggested_action: "为关键路径添加测试覆盖"
 
   when_waived: |
     waiver:
       active: true
-      reason: "Accepted for MVP release - will address in next sprint"
+      reason: "为MVP版本接受 - 将在下一个冲刺中解决"
-      approved_by: "Product Owner"
+      approved_by: "产品负责人"
 
-# ============ Optional Extended Fields ============
+# ============ 可选的扩展字段 ============
-# Uncomment and use if your team wants more detail
+# 如果您的团队需要更多细节，请取消注释并使用
 
 optional_fields_examples:
   quality_and_expiry: |
-    quality_score: 75  # 0-100 (optional scoring)
+    quality_score: 75  # 0-100（可选评分）
-    expires: "2025-01-26T00:00:00Z"  # Optional gate freshness window
+    expires: "2025-01-26T00:00:00Z"  # 可选的门禁保鲜期
 
   evidence: |
     evidence:
       tests_reviewed: 15
       risks_identified: 3
       trace:
-        ac_covered: [1, 2, 3]  # AC numbers with test coverage
+        ac_covered: [1, 2, 3]  # 有测试覆盖的AC编号
-        ac_gaps: [4]  # AC numbers lacking coverage
+        ac_gaps: [4]  # 缺少覆盖的AC编号
 
   nfr_validation: |
     nfr_validation:
-      security: { status: CONCERNS, notes: "Rate limiting missing" }
+      security: { status: CONCERNS, notes: "缺少速率限制" }
       performance: { status: PASS, notes: "" }
       reliability: { status: PASS, notes: "" }
       maintainability: { status: PASS, notes: "" }
 
   history: |
-    history:  # Append-only audit trail
+    history:  # 仅追加的审计跟踪
       - at: "2025-01-12T10:00:00Z"
         gate: FAIL
-        note: "Initial review - missing tests"
+        note: "初步审查 - 缺少测试"
       - at: "2025-01-12T15:00:00Z"  
         gate: CONCERNS
-        note: "Tests added but rate limiting still missing"
+        note: "已添加测试，但仍缺少速率限制"
 
   risk_summary: |
-    risk_summary:  # From risk-profile task
+    risk_summary:  # 来自risk-profile任务
       totals:
         critical: 0
         high: 0
         medium: 0
         low: 0
-      # 'highest' is emitted only when risks exist
+      # 'highest'仅在存在风险时发出
       recommendations:
         must_fix: []
         monitor: []
 
   recommendations: |
     recommendations:
-      immediate:  # Must fix before production
+      immediate:  # 生产前必须修复
-        - action: "Add rate limiting to auth endpoints"
+        - action: "向认证端点添加速率限制"
           refs: ["api/auth/login.ts:42-68"]
-      future:  # Can be addressed later
+      future:  # 以后可以解决
-        - action: "Consider caching for better performance"
+        - action: "考虑缓存以提高性能"
           refs: ["services/data.service.ts"]

bmad-core/templates/story-tmpl.yaml

@@ -1,12 +1,12 @@
-# <!-- Powered by BMAD™ Core -->
+# <!-- 由 BMAD™ Core 驱动 -->
 template:
   id: story-template-v2
-  name: Story Document
+  name: 故事文档
   version: 2.0
   output:
     format: markdown
     filename: docs/stories/{{epic_num}}.{{story_num}}.{{story_title_short}}.md
-    title: "Story {{epic_num}}.{{story_num}}: {{story_title_short}}"
+    title: "故事 {{epic_num}}.{{story_num}}: {{story_title_short}}"
 
 workflow:
   mode: interactive
@@ -24,115 +24,115 @@ agent_config:
 
 sections:
   - id: status
-    title: Status
+    title: 状态
     type: choice
-    choices: [Draft, Approved, InProgress, Review, Done]
+    choices: [草稿, 已批准, 进行中, 待审查, 完成]
-    instruction: Select the current status of the story
+    instruction: 选择故事的当前状态
     owner: scrum-master
     editors: [scrum-master, dev-agent]
 
   - id: story
-    title: Story
+    title: 故事
     type: template-text
     template: |
-      **As a** {{role}},
+      **作为一个** {{role}},
-      **I want** {{action}},
+      **我想要** {{action}},
-      **so that** {{benefit}}
+      **以便** {{benefit}}
-    instruction: Define the user story using the standard format with role, action, and benefit
+    instruction: 使用包含角色、行动和收益的标准格式定义用户故事
     elicit: true
     owner: scrum-master
     editors: [scrum-master]
 
   - id: acceptance-criteria
-    title: Acceptance Criteria
+    title: 验收标准
     type: numbered-list
-    instruction: Copy the acceptance criteria numbered list from the epic file
+    instruction: 从史诗文件中复制验收标准的编号列表
     elicit: true
     owner: scrum-master
     editors: [scrum-master]
 
   - id: tasks-subtasks
-    title: Tasks / Subtasks
+    title: 任务/子任务
     type: bullet-list
     instruction: |
-      Break down the story into specific tasks and subtasks needed for implementation.
+      将故事分解为实施所需的具体任务和子任务。
-      Reference applicable acceptance criteria numbers where relevant.
+      在相关处引用适用的验收标准编号。
     template: |
-      - [ ] Task 1 (AC: # if applicable)
+      - [ ] 任务1 (AC: # 如果适用)
-        - [ ] Subtask1.1...
+        - [ ] 子任务1.1...
-      - [ ] Task 2 (AC: # if applicable)
+      - [ ] 任务2 (AC: # 如果适用)
-        - [ ] Subtask 2.1...
+        - [ ] 子任务2.1...
-      - [ ] Task 3 (AC: # if applicable)
+      - [ ] 任务3 (AC: # 如果适用)
-        - [ ] Subtask 3.1...
+        - [ ] 子任务3.1...
     elicit: true
     owner: scrum-master
     editors: [scrum-master, dev-agent]
 
   - id: dev-notes
-    title: Dev Notes
+    title: 开发说明
     instruction: |
-      Populate relevant information, only what was pulled from actual artifacts from docs folder, relevant to this story:
+      仅填充从docs文件夹中的实际工件中提取的、与此故事相关的信息：
-      - Do not invent information
+      - 不要杜撰信息
-      - If known add Relevant Source Tree info that relates to this story
+      - 如果已知，添加与此故事相关的源代码树信息
-      - If there were important notes from previous story that are relevant to this one, include them here
+      - 如果上一个故事中有与此故事相关的重要说明，请在此处包括
-      - Put enough information in this section so that the dev agent should NEVER need to read the architecture documents, these notes along with the tasks and subtasks must give the Dev Agent the complete context it needs to comprehend with the least amount of overhead the information to complete the story, meeting all AC and completing all tasks+subtasks
+      - 在此部分提供足够的信息，以便开发代理永远不需要阅读架构文档，这些说明以及任务和子任务必须为开发代理提供完成故事所需的完整上下文，以最小的开销理解信息，满足所有AC并完成所有任务+子任务
     elicit: true
     owner: scrum-master
     editors: [scrum-master]
     sections:
       - id: testing-standards
-        title: Testing
+        title: 测试
         instruction: |
-          List Relevant Testing Standards from Architecture the Developer needs to conform to:
+          列出开发人员需要遵守的来自架构的相关测试标准：
-          - Test file location
+          - 测试文件位置
-          - Test standards
+          - 测试标准
-          - Testing frameworks and patterns to use
+          - 要使用的测试框架和模式
-          - Any specific testing requirements for this story
+          - 此故事的任何特定测试要求
         elicit: true
         owner: scrum-master
         editors: [scrum-master]
 
   - id: change-log
-    title: Change Log
+    title: 变更日志
     type: table
-    columns: [Date, Version, Description, Author]
+    columns: [日期, 版本, 描述, 作者]
-    instruction: Track changes made to this story document
+    instruction: 跟踪对此故事文档所做的更改
     owner: scrum-master
     editors: [scrum-master, dev-agent, qa-agent]
 
   - id: dev-agent-record
-    title: Dev Agent Record
+    title: 开发代理记录
-    instruction: This section is populated by the development agent during implementation
+    instruction: 此部分由开发代理在实施期间填充
     owner: dev-agent
     editors: [dev-agent]
     sections:
       - id: agent-model
-        title: Agent Model Used
+        title: 使用的代理模型
         template: "{{agent_model_name_version}}"
-        instruction: Record the specific AI agent model and version used for development
+        instruction: 记录用于开发的特定AI代理模型和版本
         owner: dev-agent
         editors: [dev-agent]
 
       - id: debug-log-references
-        title: Debug Log References
+        title: 调试日志参考
-        instruction: Reference any debug logs or traces generated during development
+        instruction: 引用开发过程中生成的任何调试日志或跟踪
         owner: dev-agent
         editors: [dev-agent]
 
       - id: completion-notes
-        title: Completion Notes List
+        title: 完成说明列表
-        instruction: Notes about the completion of tasks and any issues encountered
+        instruction: 关于任务完成情况和遇到的任何问题的说明
         owner: dev-agent
         editors: [dev-agent]
 
       - id: file-list
-        title: File List
+        title: 文件列表
-        instruction: List all files created, modified, or affected during story implementation
+        instruction: 列出在故事实施期间创建、修改或影响的所有文件
         owner: dev-agent
         editors: [dev-agent]
 
   - id: qa-results
-    title: QA Results
+    title: QA结果
-    instruction: Results from QA Agent QA review of the completed story implementation
+    instruction: QA代理对已完成故事实施的QA审查结果
     owner: qa-agent
     editors: [qa-agent]

docs/GUIDING-PRINCIPLES.md

@@ -1,91 +1,91 @@
-# BMad Method Guiding Principles
+# BMad方法指导原则
 
-The BMad Method is a natural language framework for AI-assisted software development. These principles ensure contributions maintain the method's effectiveness.
+BMad方法是一个用于AI辅助软件开发的自然语言框架。这些原则确保贡献能保持该方法的有效性。
 
-## Core Principles
+## 核心原则
 
-### 1. Dev Agents Must Be Lean
+### 1. 开发代理必须精简
 
-- **Minimize dev agent dependencies**: Development agents that work in IDEs must have minimal context overhead
+-   **最小化开发代理的依赖**: 在IDE中工作的开发代理必须有最小的上下文开销
-- **Save context for code**: Every line counts - dev agents should focus on coding, not documentation
+-   **为代码节省上下文**: 每一行都很重要 - 开发代理应专注于编码，而不是文档
-- **Web agents can be larger**: Planning agents (PRD Writer, Architect) used in web UI can have more complex tasks and dependencies
+-   **Web代理可以更大**: 在Web UI中使用的规划代理（PRD编写者、架构师）可以有更复杂的任务和依赖
-- **Small files, loaded on demand**: Multiple small, focused files are better than large files with many branches
+-   **小文件，按需加载**: 多个小的、专注的文件比包含许多分支的大文件更好
 
-### 2. Natural Language First
+### 2. 自然语言优先
 
-- **Everything is markdown**: Agents, tasks, templates - all written in plain English
+-   **一切都是markdown**: 代理、任务、模板 - 都用纯英文编写
-- **No code in core**: The framework itself contains no programming code, only natural language instructions
+-   **核心中没有代码**: 框架本身不包含编程代码，只有自然语言指令
-- **Self-contained templates**: Templates are defined as YAML files with structured sections that include metadata, workflow configuration, and detailed instructions for content generation
+-   **自包含的模板**: 模板被定义为YAML文件，具有结构化的部分，包括元数据、工作流配置和内容生成的详细说明
 
-### 3. Agent and Task Design
+### 3. 代理和任务设计
 
-- **Agents define roles**: Each agent is a persona with specific expertise (e.g., Frontend Developer, API Developer)
+-   **代理定义角色**: 每个代理都是一个具有特定专业知识的角色（例如，前端开发人员、API开发人员）
-- **Tasks are procedures**: Step-by-step instructions an agent follows to complete work
+-   **任务是程序**: 代理为完成工作而遵循的逐步说明
-- **Templates are outputs**: Structured documents with embedded instructions for generation
+-   **模板是输出**: 带有生成说明的结构化文档
-- **Dependencies matter**: Explicitly declare only what's needed
+-   **依赖关系很重要**: 明确声明只需要什么
 
-## Practical Guidelines
+## 实践指南
 
-### When to Add to Core
+### 何时添加到核心
 
-- Universal software development needs only
+-   仅限通用的软件开发需求
-- Doesn't bloat dev agent contexts
+-   不增加开发代理的上下文负担
-- Follows existing agent/task/template patterns
+-   遵循现有的代理/任务/模板模式
 
-### When to Create Expansion Packs
+### 何时创建扩展包
 
-- Domain-specific needs beyond software development
+-   软件开发之外的特定领域需求
-- Non-technical domains (business, wellness, education, creative)
+-   非技术领域（商业、健康、教育、创意）
-- Specialized technical domains (games, infrastructure, mobile)
+-   专业技术领域（游戏、基础设施、移动）
-- Heavy documentation or knowledge bases
+-   大量的文档或知识库
-- Anything that would bloat core agents
+-   任何会使核心代理膨胀的东西
 
-See [Expansion Packs Guide](../docs/expansion-packs.md) for detailed examples and ideas.
+有关详细示例和想法，请参阅[扩展包指南](../docs/expansion-packs.md)。
 
-### Agent Design Rules
+### 代理设计规则
 
-1. **Web/Planning Agents**: Can have richer context, multiple tasks, extensive templates
+1.  **Web/规划代理**: 可以有更丰富的上下文、多个任务、广泛的模板
-2. **Dev Agents**: Minimal dependencies, focused on code generation, lean task sets
+2.  **开发代理**: 最小的依赖、专注于代码生成、精简的任务集
-3. **All Agents**: Clear persona, specific expertise, well-defined capabilities
+3.  **所有代理**: 清晰的角色、特定的专业知识、明确定义的能力
 
-### Task Writing Rules
+### 任务编写规则
 
-1. Write clear step-by-step procedures
+1.  编写清晰的逐步程序
-2. Use markdown formatting for readability
+2.  使用markdown格式以提高可读性
-3. Keep dev agent tasks focused and concise
+3.  保持开发代理任务的专注和简洁
-4. Planning tasks can be more elaborate
+4.  规划任务可以更详尽
-5. **Prefer multiple small tasks over one large branching task**
+5.  **倾向于多个小任务，而不是一个大的分支任务**
-   - Instead of one task with many conditional paths
+    -   而不是一个有许多条件路径的任务
-   - Create multiple focused tasks the agent can choose from
+    -   创建多个专注的任务供代理选择
-   - This keeps context overhead minimal
+    -   这使上下文开销保持最小
-6. **Reuse common tasks** - Don't create new document creation tasks
+6.  **重用通用任务** - 不要创建新的文档创建任务
-   - Use the existing `create-doc` task
+    -   使用现有的`create-doc`任务
-   - Pass the appropriate YAML template with structured sections
+    -   传递带有结构化部分的适当YAML模板
-   - This maintains consistency and reduces duplication
+    -   这保持了一致性并减少了重复
 
-### Template Rules
+### 模板规则
 
-Templates follow the [BMad Document Template](../common/utils/bmad-doc-template.md) specification using YAML format:
+模板遵循使用YAML格式的[BMad文档模板](../common/utils/bmad-doc-template.md)规范：
 
-1. **Structure**: Templates are defined in YAML with clear metadata, workflow configuration, and section hierarchy
+1.  **结构**: 模板在YAML中定义，具有清晰的元数据、工作流配置和章节层次结构
-2. **Separation of Concerns**: Instructions for LLMs are in `instruction` fields, separate from content
+2.  **关注点分离**: LLM的指令在`instruction`字段中，与内容分开
-3. **Reusability**: Templates are agent-agnostic and can be used across different agents
+3.  **可重用性**: 模板与代理无关，可以在不同的代理之间使用
-4. **Key Components**:
+4.  **关键组件**:
-   - `template` block for metadata (id, name, version, output settings)
+    -   用于元数据的`template`块（id、name、version、output设置）
-   - `workflow` block for interaction mode configuration
+    -   用于交互模式配置的`workflow`块
-   - `sections` array defining document structure with nested subsections
+    -   定义文档结构的`sections`数组，带有嵌套的子部分
-   - Each section has `id`, `title`, and `instruction` fields
+    -   每个部分都有`id`、`title`和`instruction`字段
-5. **Advanced Features**:
+5.  **高级功能**:
-   - Variable substitution using `{{variable_name}}` syntax
+    -   使用`{{variable_name}}`语法进行变量替换
-   - Conditional sections with `condition` field
+    -   带有`condition`字段的条件部分
-   - Repeatable sections with `repeatable: true`
+    -   带有`repeatable: true`的可重复部分
-   - Agent permissions with `owner` and `editors` fields
+    -   带有`owner`和`editors`字段的代理权限
-   - Examples arrays for guidance (never included in output)
+    -   用于指导的示例数组（从不包含在输出中）
-6. **Clean Output**: YAML structure ensures all processing logic stays separate from generated content
+6.  **干净的输出**: YAML结构确保所有处理逻辑与生成的内容分开
 
-## Remember
+## 请记住
 
-- The power is in natural language orchestration, not code
+-   力量在于自然语言的编排，而不是代码
-- Dev agents code, planning agents plan
+-   开发代理编码，规划代理规划
-- Keep dev agents lean for maximum coding efficiency
+-   保持开发代理精简以实现最大的编码效率
-- Expansion packs handle specialized domains
+-   扩展包处理专业领域

docs/core-architecture.md

@@ -1,53 +1,53 @@
-# BMad Method: Core Architecture
+# BMad方法：核心架构
 
-## 1. Overview
+## 1. 概述
 
-The BMad Method is designed to provide agentic modes, tasks and templates to allow repeatable helpful workflows be it for agile agentic development, or expansion into vastly different domains. The core purpose of the project is to provide a structured yet flexible set of prompts, templates, and workflows that users can employ to guide AI agents (like Gemini, Claude, or ChatGPT) to perform complex tasks, guided discussions, or other meaningful domain specific flows in a predictable, high-quality manner.
+BMad方法旨在提供代理模式、任务和模板，以实现可重复的、有帮助的工作流程，无论是用于敏捷的代理开发，还是扩展到截然不同的领域。该项目的核心目的是提供一套结构化但灵活的提示、模板和工作流程，用户可以使用它们来指导AI代理（如Gemini、Claude或ChatGPT）以可预测、高质量的方式执行复杂任务、进行引导式讨论或其他有意义的领域特定流程。
 
-The systems core module facilitates a full development lifecycle tailored to the challenges of current modern AI Agentic tooling:
+系统的核心模块促进了针对当前现代AI代理工具挑战的完整开发生命周期：
 
-1. **Ideation & Planning**: Brainstorming, market research, and creating project briefs.
+1.  **构思与规划**：头脑风暴、市场研究以及创建项目简报。
-2. **Architecture & Design**: Defining system architecture and UI/UX specifications.
+2.  **架构与设计**：定义系统架构和UI/UX规范。
-3. **Development Execution**: A cyclical workflow where a Scrum Master (SM) agent drafts stories with extremely specific context and a Developer (Dev) agent implements them one at a time. This process works for both new (Greenfield) and existing (Brownfield) projects.
+3.  **开发执行**：一个循环工作流程，其中Scrum Master (SM)代理起草具有极其具体上下文的故事，而开发人员(Dev)代理一次实现一个。此过程适用于新项目（绿地）和现有项目（棕地）。
 
-## 2. System Architecture Diagram
+## 2. 系统架构图
 
-The entire BMad-Method ecosystem is designed around the installed `bmad-core` directory, which acts as the brain of the operation. The `tools` directory provides the means to process and package this brain for different environments.
+整个BMad-Method生态系统围绕已安装的`bmad-core`目录设计，该目录充当操作的大脑。`tools`目录提供了为不同环境处理和打包此大脑的方法。
 
 ```mermaid
 graph TD
-    subgraph BMad Method Project
+    subgraph BMad方法项目
-        subgraph Core Framework
+        subgraph 核心框架
             A["bmad-core"]
-            A --> B["agents"]
+            A --> B["代理"]
-            A --> C["agent-teams"]
+            A --> C["代理团队"]
-            A --> D["workflows"]
+            A --> D["工作流"]
-            A --> E["templates"]
+            A --> E["模板"]
-            A --> F["tasks"]
+            A --> F["任务"]
-            A --> G["checklists"]
+            A --> G["清单"]
-            A --> H["data (KB)"]
+            A --> H["数据(KB)"]
         end
 
-        subgraph Tooling
+        subgraph 工具
             I["tools/builders/web-builder.js"]
         end
 
-        subgraph Outputs
+        subgraph 输出
             J["dist"]
         end
 
-        B -- defines dependencies for --> E
+        B -- 定义依赖 --> E
-        B -- defines dependencies for --> F
+        B -- 定义依赖 --> F
-        B -- defines dependencies for --> G
+        B -- 定义依赖 --> G
-        B -- defines dependencies for --> H
+        B -- 定义依赖 --> H
 
-        C -- bundles --> B
+        C -- 打包 --> B
-        I -- reads from --> A
+        I -- 读取自 --> A
-        I -- creates --> J
+        I -- 创建 --> J
     end
 
-    subgraph Target Environments
+    subgraph 目标环境
-        K["IDE (Cursor, VS Code, etc.)"]
+        K["IDE (Cursor, VS Code等)"]
         L["Web UI (Gemini, ChatGPT)"]
     end
 
@@ -59,115 +59,115 @@ graph TD
     style J fill:#34a853,color:#fff
 ```
 
-## 3. Core Components
+## 3. 核心组件
 
-The `bmad-core` directory contains all the definitions and resources that give the agents their capabilities.
+`bmad-core`目录包含赋予代理能力的所有定义和资源。
 
-### 3.1. Agents (`bmad-core/agents/`)
+### 3.1. 代理 (`bmad-core/agents/`)
 
-- **Purpose**: These are the foundational building blocks of the system. Each markdown file (e.g., `bmad-master.md`, `pm.md`, `dev.md`) defines the persona, capabilities, and dependencies of a single AI agent.
+-   **目的**：这些是系统的基础构建块。每个markdown文件（例如，`bmad-master.md`、`pm.md`、`dev.md`）定义了单个AI代理的角色、能力和依赖关系。
-- **Structure**: An agent file contains a YAML header that specifies its role, persona, dependencies, and startup instructions. These dependencies are lists of tasks, templates, checklists, and data files that the agent is allowed to use.
+-   **结构**：代理文件包含一个YAML头，指定其角色、角色、依赖项和启动说明。这些依赖项是代理被允许使用的任务、模板、清单和数据文件的列表。
-- **Startup Instructions**: Agents can include startup sequences that load project-specific documentation from the `docs/` folder, such as coding standards, API specifications, or project structure documents. This provides immediate project context upon activation.
+-   **启动说明**：代理可以包括从`docs/`文件夹加载特定于项目的文档的启动序列，例如编码标准、API规范或项目结构文档。这在激活时提供了即时的项目上下文。
-- **Document Integration**: Agents can reference and load documents from the project's `docs/` folder as part of tasks, workflows, or startup sequences. Users can also drag documents directly into chat interfaces to provide additional context.
+-   **文档集成**：代理可以作为任务、工作流或启动序列的一部分引用和加载项目`docs/`文件夹中的文档。用户还可以将文档直接拖到聊天界面中以提供额外的上下文。
-- **Example**: The `bmad-master` agent lists its dependencies, which tells the build tool which files to include in a web bundle and informs the agent of its own capabilities.
+-   **示例**：`bmad-master`代理列出了其依赖项，这告诉构建工具在Web包中包含哪些文件，并告知代理其自身的能力。
 
-### 3.2. Agent Teams (`bmad-core/agent-teams/`)
+### 3.2. 代理团队 (`bmad-core/agent-teams/`)
 
-- **Purpose**: Team files (e.g., `team-all.yaml`) define collections of agents and workflows that are bundled together for a specific purpose, like "full-stack development" or "backend-only". This creates a larger, pre-packaged context for web UI environments.
+-   **目的**：团队文件（例如，`team-all.yaml`）定义了为特定目的（如“全栈开发”或“仅后端”）捆绑在一起的代理和工作流的集合。这为Web UI环境创建了一个更大的、预打包的上下文。
-- **Structure**: A team file lists the agents to include. It can use wildcards, such as `"*"` to include all agents. This allows for the creation of comprehensive bundles like `team-all`.
+-   **结构**：团队文件列出了要包含的代理。它可以使用通配符，例如`"*"`来包含所有代理。这允许创建像`team-all`这样的综合包。
 
-### 3.3. Workflows (`bmad-core/workflows/`)
+### 3.3. 工作流 (`bmad-core/workflows/`)
 
-- **Purpose**: Workflows are YAML files (e.g., `greenfield-fullstack.yaml`) that define a prescribed sequence of steps and agent interactions for a specific project type. They act as a strategic guide for the user and the `bmad-orchestrator` agent.
+-   **目的**：工作流是YAML文件（例如，`greenfield-fullstack.yaml`），它们为特定项目类型定义了规定的步骤序列和代理交互。它们作为用户和`bmad-orchestrator`代理的战略指南。
-- **Structure**: A workflow defines sequences for both complex and simple projects, lists the agents involved at each step, the artifacts they create, and the conditions for moving from one step to the next. It often includes a Mermaid diagram for visualization.
+-   **结构**：工作流为复杂和简单的项目定义了序列，列出了每个步骤中涉及的代理、它们创建的工件以及从一个步骤移动到下一个步骤的条件。它通常包括一个用于可视化的Mermaid图。
 
-### 3.4. Reusable Resources (`templates`, `tasks`, `checklists`, `data`)
+### 3.4. 可重用资源 (`templates`, `tasks`, `checklists`, `data`)
 
-- **Purpose**: These folders house the modular components that are dynamically loaded by agents based on their dependencies.
+-   **目的**：这些文件夹存放由代理根据其依赖关系动态加载的模块化组件。
-  - **`templates/`**: Contains markdown templates for common documents like PRDs, architecture specifications, and user stories.
+    -   **`templates/`**：包含常见文档的markdown模板，如PRD、架构规范和用户故事。
-  - **`tasks/`**: Defines the instructions for carrying out specific, repeatable actions like "shard-doc" or "create-next-story".
+    -   **`tasks/`**：定义执行特定、可重复操作（如“shard-doc”或“create-next-story”）的说明。
-  - **`checklists/`**: Provides quality assurance checklists for agents like the Product Owner (`po`) or Architect.
+    -   **`checklists/`**：为产品负责人（`po`）或架构师等代理提供质量保证清单。
-  - **`data/`**: Contains the core knowledge base (`bmad-kb.md`), technical preferences (`technical-preferences.md`), and other key data files.
+    -   **`data/`**：包含核心知识库（`bmad-kb.md`）、技术偏好（`technical-preferences.md`）和其他关键数据文件。
 
-#### 3.4.1. Template Processing System
+#### 3.4.1. 模板处理系统
 
-A key architectural principle of BMad is that templates are self-contained and interactive - they embed both the desired document output and the LLM instructions needed to work with users. This means that in many cases, no separate task is needed for document creation, as the template itself contains all the processing logic.
+BMad的一个关键架构原则是模板是自包含和交互式的——它们嵌入了所需的文档输出和与用户协作所需的LLM指令。这意味着在许多情况下，不需要单独的任务来创建文档，因为模板本身包含了所有的处理逻辑。
 
-The BMad framework employs a sophisticated template processing system orchestrated by three key components:
+BMad框架采用了一个由三个关键组件协调的复杂模板处理系统：
 
-- **`template-format.md`** (`bmad-core/utils/`): Defines the foundational markup language used throughout all BMad templates. This specification establishes syntax rules for variable substitution (`{{placeholders}}`), AI-only processing directives (`[[LLM: instructions]]`), and conditional logic blocks. Templates follow this format to ensure consistent processing across the system.
+-   **`template-format.md`** (`bmad-core/utils/`)：定义了在所有BMad模板中使用的基础标记语言。该规范建立了变量替换（`{{placeholders}}`）、仅AI处理指令（`[[LLM: instructions]]`）和条件逻辑块的语法规则。模板遵循此格式以确保整个系统的一致处理。
 
-- **`create-doc.md`** (`bmad-core/tasks/`): Acts as the orchestration engine that manages the entire document generation workflow. This task coordinates template selection, manages user interaction modes (incremental vs. rapid generation), enforces template-format processing rules, and handles validation. It serves as the primary interface between users and the template system.
+-   **`create-doc.md`** (`bmad-core/tasks/`)：作为协调整个文档生成工作流的编排引擎。此任务协调模板选择，管理用户交互模式（增量与快速生成），强制执行模板格式处理规则，并处理验证。它作为用户和模板系统之间的主要接口。
 
-- **`advanced-elicitation.md`** (`bmad-core/tasks/`): Provides an interactive refinement layer that can be embedded within templates through `[[LLM: instructions]]` blocks. This component offers 10 structured brainstorming actions, section-by-section review capabilities, and iterative improvement workflows to enhance content quality.
+-   **`advanced-elicitation.md`** (`bmad-core/tasks/`)：提供一个交互式完善层，可以通过`[[LLM: instructions]]`块嵌入到模板中。该组件提供10个结构化的头脑风暴操作、逐节审查功能和迭代改进工作流，以提高内容质量。
 
-The system maintains a clean separation of concerns: template markup is processed internally by AI agents but never exposed to users, while providing sophisticated AI processing capabilities through embedded intelligence within the templates themselves.
+该系统保持了清晰的关注点分离：模板标记由AI代理在内部处理，但从不向用户公开，同时通过模板本身内嵌的智能提供复杂的AI处理能力。
 
-#### 3.4.2. Technical Preferences System
+#### 3.4.2. 技术偏好系统
 
-BMad includes a personalization layer through the `technical-preferences.md` file in `bmad-core/data/`. This file serves as a persistent technical profile that influences agent behavior across all projects.
+BMad通过`bmad-core/data/`中的`technical-preferences.md`文件包含了一个个性化层。该文件作为一个持久的技术配置文件，影响所有项目中的代理行为。
 
-**Purpose and Benefits:**
+**目的和好处：**
 
-- **Consistency**: Ensures all agents reference the same technical preferences
+-   **一致性**：确保所有代理引用相同的技术偏好
-- **Efficiency**: Eliminates the need to repeatedly specify preferred technologies
+-   **效率**：无需重复指定首选技术
-- **Personalization**: Agents provide recommendations aligned with user preferences
+-   **个性化**：代理提供符合用户偏好的建议
-- **Learning**: Captures lessons learned and preferences that evolve over time
+-   **学习**：捕获随着时间演变的经验教训和偏好
 
-**Content Structure:**
+**内容结构：**
-The file typically includes preferred technology stacks, design patterns, external services, coding standards, and anti-patterns to avoid. Agents automatically reference this file during planning and development to provide contextually appropriate suggestions.
+该文件通常包括首选的技术栈、设计模式、外部服务、编码标准和要避免的反模式。代理在规划和开发过程中自动引用此文件，以提供上下文适当的建议。
 
-**Integration Points:**
+**集成点：**
 
-- Templates can reference technical preferences during document generation
+-   模板可以在文档生成期间引用技术偏好
-- Agents suggest preferred technologies when appropriate for project requirements
+-   代理在适合项目需求时建议首选技术
-- When preferences don't fit project needs, agents explain alternatives
+-   当偏好不适合项目需求时，代理会解释替代方案
-- Web bundles can include preferences content for consistent behavior across platforms
+-   Web包可以包含偏好内容，以实现跨平台的一致行为
 
-**Evolution Over Time:**
+**随时间演变：**
-Users are encouraged to continuously update this file with discoveries from projects, adding both positive preferences and technologies to avoid, creating a personalized knowledge base that improves agent recommendations over time.
+鼓励用户不断用项目中的发现更新此文件，添加积极的偏好和要避免的技术，从而创建一个个性化的知识库，随着时间的推移改善代理的建议。
 
-## 4. The Build & Delivery Process
+## 4. 构建与交付过程
 
-The framework is designed for two primary environments: local IDEs and web-based AI chat interfaces. The `web-builder.js` script is the key to supporting the latter.
+该框架专为两个主要环境设计：本地IDE和基于Web的AI聊天界面。`web-builder.js`脚本是支持后者的关键。
 
-### 4.1. Web Builder (`tools/builders/web-builder.js`)
+### 4.1. Web构建器 (`tools/builders/web-builder.js`)
 
-- **Purpose**: This Node.js script is responsible for creating the `.txt` bundles found in `dist`.
+-   **目的**：这个Node.js脚本负责创建在`dist`中找到的`.txt`包。
-- **Process**:
+-   **过程**：
-  1. **Resolves Dependencies**: For a given agent or team, the script reads its definition file.
+    1.  **解析依赖**：对于给定的代理或团队，脚本读取其定义文件。
-  2. It recursively finds all dependent resources (tasks, templates, etc.) that the agent/team needs.
+    2.  它递归地查找代理/团队所需的所有依赖资源（任务、模板等）。
-  3. **Bundles Content**: It reads the content of all these files and concatenates them into a single, large text file, with clear separators indicating the original file path of each section.
+    3.  **打包内容**：它读取所有这些文件的内容，并将它们连接成一个大的文本文件，用清晰的分隔符指示每个部分的原始文件路径。
-  4. **Outputs Bundle**: The final `.txt` file is saved in the `dist` directory, ready to be uploaded to a web UI.
+    4.  **输出包**：最终的`.txt`文件保存在`dist`目录中，准备好上传到Web UI。
 
-### 4.2. Environment-Specific Usage
+### 4.2. 特定环境的使用
 
-- **For IDEs**: Users interact with the agents directly via their markdown files in `bmad-core/agents/`. The IDE integration (for Cursor, Claude Code, etc.) knows how to call these agents.
+-   **对于IDE**：用户通过`bmad-core/agents/`中的markdown文件直接与代理交互。IDE集成（对于Cursor、Claude Code等）知道如何调用这些代理。
-- **For Web UIs**: Users upload a pre-built bundle from `dist`. This single file provides the AI with the context of the entire team and all their required tools and knowledge.
+-   **对于Web UI**：用户从`dist`上传一个预构建的包。这个单一文件为AI提供了整个团队及其所有所需工具和知识的上下文。
 
-## 5. BMad Workflows
+## 5. BMad工作流
 
-### 5.1. The Planning Workflow
+### 5.1. 规划工作流
 
-Before development begins, BMad follows a structured planning workflow that establishes the foundation for successful project execution:
+在开发开始之前，BMad遵循一个结构化的规划工作流，为成功的项目执行奠定基础：
 
 ```mermaid
 graph TD
-    A["Start: Project Idea"] --> B{"Optional: Analyst Brainstorming"}
+    A["开始：项目构思"] --> B{"可选：分析师头脑风暴"}
-    B -->|Yes| C["Analyst: Market Research & Analysis"]
+    B -->|是| C["分析师：市场研究与分析"]
-    B -->|No| D["Create Project Brief"]
+    B -->|否| D["创建项目简报"]
-    C --> D["Analyst: Create Project Brief"]
+    C --> D["分析师：创建项目简报"]
-    D --> E["PM: Create PRD from Brief"]
+    D --> E["产品经理：从简报创建PRD"]
-    E --> F["Architect: Create Architecture from PRD"]
+    E --> F["架构师：从PRD创建架构"]
-    F --> G["PO: Run Master Checklist"]
+    F --> G["产品负责人：运行主清单"]
-    G --> H{"Documents Aligned?"}
+    G --> H{"文档是否对齐？"}
-    H -->|Yes| I["Planning Complete"]
+    H -->|是| I["规划完成"]
-    H -->|No| J["PO: Update Epics & Stories"]
+    H -->|否| J["产品负责人：更新史诗和故事"]
-    J --> K["Update PRD/Architecture as needed"]
+    J --> K["根据需要更新PRD/架构"]
     K --> G
-    I --> L["📁 Switch to IDE"]
+    I --> L["📁 切换到IDE"]
-    L --> M["PO: Shard Documents"]
+    L --> M["产品负责人：分片文档"]
-    M --> N["Ready for SM/Dev Cycle"]
+    M --> N["准备好进行SM/Dev循环"]
 
     style I fill:#34a853,color:#fff
     style G fill:#f9ab00,color:#fff
@@ -175,45 +175,45 @@ graph TD
     style N fill:#34a853,color:#fff
 ```
 
-**Key Planning Phases:**
+**关键规划阶段：**
 
-1. **Optional Analysis**: Analyst conducts market research and competitive analysis
+1.  **可选分析**：分析师进行市场研究和竞争分析
-2. **Project Brief**: Foundation document created by Analyst or user
+2.  **项目简报**：由分析师或用户创建的基础文档
-3. **PRD Creation**: PM transforms brief into comprehensive product requirements
+3.  **PRD创建**：产品经理将简报转化为全面的产品需求
-4. **Architecture Design**: Architect creates technical foundation based on PRD
+4.  **架构设计**：架构师根据PRD创建技术基础
-5. **Validation & Alignment**: PO ensures all documents are consistent and complete
+5.  **验证与对齐**：产品负责人确保所有文档一致且完整
-6. **Refinement**: Updates to epics, stories, and documents as needed
+6.  **完善**：根据需要更新史诗、故事和文档
-7. **Environment Transition**: Critical switch from web UI to IDE for development workflow
+7.  **环境转换**：从Web UI到IDE的关键转换，用于开发工作流
-8. **Document Preparation**: PO shards large documents for development consumption
+8.  **文档准备**：产品负责人为开发消费分片大型文档
 
-**Workflow Orchestration**: The `bmad-orchestrator` agent uses these workflow definitions to guide users through the complete process, ensuring proper transitions between planning (web UI) and development (IDE) phases.
+**工作流编排**：`bmad-orchestrator`代理使用这些工作流定义来指导用户完成整个过程，确保在规划（Web UI）和开发（IDE）阶段之间进行适当的转换。
 
-### 5.2. The Core Development Cycle
+### 5.2. 核心开发周期
 
-Once the initial planning and architecture phases are complete, the project moves into a cyclical development workflow, as detailed in the `bmad-kb.md`. This ensures a steady, sequential, and quality-controlled implementation process.
+一旦初始规划和架构阶段完成，项目就进入一个循环的开发工作流，如`bmad-kb.md`中所述。这确保了一个稳定、顺序和质量受控的实施过程。
 
 ```mermaid
 graph TD
-    A["Start: Planning Artifacts Complete"] --> B["PO: Shard Epics"]
+    A["开始：规划工件完成"] --> B["产品负责人：分片史诗"]
-    B --> C["PO: Shard Arch"]
+    B --> C["产品负责人：分片架构"]
-    C --> D["Development Phase"]
+    C --> D["开发阶段"]
-    D --> E["Scrum Master: Drafts next story from sharded epic"]
+    D --> E["Scrum Master：从分片史诗中起草下一个故事"]
-    E --> F{"User Approval"}
+    E --> F{"用户批准"}
-    F -->|Approved| G["Dev: Implement Story"]
+    F -->|已批准| G["开发：实施故事"]
-    F -->|Needs Changes| E
+    F -->|需要更改| E
-    G --> H["Dev: Complete story Tasks"]
+    G --> H["开发：完成故事任务"]
-    H --> I["Dev: Mark Ready for Review"]
+    H --> I["开发：标记为待审查"]
-    I --> J{"User Verification"}
+    I --> J{"用户验证"}
-    J -->|Request QA Review| K["QA: Run review-story task"]
+    J -->|请求QA审查| K["QA：运行review-story任务"]
-    J -->|Approve Without QA| M["Mark Story as Done"]
+    J -->|未经QA批准| M["将故事标记为完成"]
-    K --> L{"QA Review Results"}
+    K --> L{"QA审查结果"}
-    L -->|Needs Work| G
+    L -->|需要修改| G
-    L -->|Approved| M["Mark Story as Done"]
+    L -->|已批准| M["将故事标记为完成"]
-    J -->|Needs Fixes| G
+    J -->|需要修复| G
     M --> E
 
     style M fill:#34a853,color:#fff
     style K fill:#f9ab00,color:#fff
 ```
 
-This cycle continues, with the Scrum Master, Developer, and optionally QA agents working together. The QA agent provides senior developer review capabilities through the `review-story` task, offering code refactoring, quality improvements, and knowledge transfer. This ensures high code quality while maintaining development velocity.
+这个周期持续进行，Scrum Master、开发人员和可选的QA代理协同工作。QA代理通过`review-story`任务提供高级开发人员审查能力，提供代码重构、质量改进和知识转移。这在保持开发速度的同时确保了高代码质量。

docs/enhanced-ide-development-workflow.md

@@ -1,248 +1,248 @@
-# Enhanced IDE Development Workflow
+# 增强的IDE开发工作流
 
-This is a simple step-by-step guide to help you efficiently manage your development workflow using the BMad Method. The workflow integrates the Test Architect (QA agent) throughout the development lifecycle to ensure quality, prevent regressions, and maintain high standards. Refer to the **[<ins>User Guide</ins>](user-guide.md)** for any scenario that is not covered here.
+这是一个简单的分步指南，可帮助您使用BMad方法高效地管理开发工作流。该工作流在整个开发生命周期中集成了测试架构师（QA代理），以确保质量、防止回归并保持高标准。有关此处未涵盖的任何场景，请参阅**[<ins>用户指南</ins>](user-guide.md)**。
 
-## Create New Branch
+## 创建新分支
 
-1. **Start new branch**
+1.  **启动新分支**
 
-## Story Creation (Scrum Master)
+## 故事创建（Scrum Master）
 
-1. **Start new chat/conversation**
+1.  **开始新的聊天/对话**
-2. **Load SM agent**
+2.  **加载SM代理**
-3. **Execute**: `*draft` (runs create-next-story task)
+3.  **执行**：`*draft`（运行create-next-story任务）
-4. **Review generated story** in `docs/stories/`
+4.  **审查生成的故事**，位于`docs/stories/`
-5. **Update status**: Change from "Draft" to "Approved"
+5.  **更新状态**：将状态从“草稿”更改为“已批准”
 
-## Story Implementation (Developer)
+## 故事实施（开发人员）
 
-1. **Start new chat/conversation**
+1.  **开始新的聊天/对话**
-2. **Load Dev agent**
+2.  **加载开发代理**
-3. **Execute**: `*develop-story {selected-story}` (runs execute-checklist task)
+3.  **执行**：`*develop-story {selected-story}`（运行execute-checklist任务）
-4. **Review generated report** in `{selected-story}`
+4.  **审查生成的报告**，位于`{selected-story}`
 
-## Test Architect Integration Throughout Workflow
+## 在整个工作流中集成测试架构师
 
-The Test Architect (Quinn) provides comprehensive quality assurance throughout the development lifecycle. Here's how to leverage each capability at the right time.
+测试架构师（Quinn）在整个开发生命周期中提供全面的质量保证。以下是如何在适当的时候利用每项功能。
 
-**Command Aliases:** Documentation uses short forms (`*risk`, `*design`, `*nfr`, `*trace`) for the full commands (`*risk-profile`, `*test-design`, `*nfr-assess`, `*trace-requirements`).
+**命令别名：** 文档使用简写形式（`*risk`, `*design`, `*nfr`, `*trace`）来表示完整命令（`*risk-profile`, `*test-design`, `*nfr-assess`, `*trace-requirements`）。
 
-### Quick Command Reference
+### 快速命令参考
 
-| **Stage**                | **Command** | **Purpose**                             | **Output**                                                      | **Priority**                |
+| **阶段** | **命令** | **目的** | **输出** | **优先级** |
-| ------------------------ | ----------- | --------------------------------------- | --------------------------------------------------------------- | --------------------------- |
+| --- | --- | --- | --- | --- |
-| **After Story Approval** | `*risk`     | Identify integration & regression risks | `docs/qa/assessments/{epic}.{story}-risk-{YYYYMMDD}.md`         | High for complex/brownfield |
+| **故事批准后** | `*risk` | 识别集成和回归风险 | `docs/qa/assessments/{epic}.{story}-risk-{YYYYMMDD}.md` | 对于复杂/棕地项目为高 |
-|                          | `*design`   | Create test strategy for dev            | `docs/qa/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md`  | High for new features       |
+| | `*design` | 为开发创建测试策略 | `docs/qa/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md` | 对于新功能为高 |
-| **During Development**   | `*trace`    | Verify test coverage                    | `docs/qa/assessments/{epic}.{story}-trace-{YYYYMMDD}.md`        | Medium                      |
+| **开发期间** | `*trace` | 验证测试覆盖率 | `docs/qa/assessments/{epic}.{story}-trace-{YYYYMMDD}.md` | 中 |
-|                          | `*nfr`      | Validate quality attributes             | `docs/qa/assessments/{epic}.{story}-nfr-{YYYYMMDD}.md`          | High for critical features  |
+| | `*nfr` | 验证质量属性 | `docs/qa/assessments/{epic}.{story}-nfr-{YYYYMMDD}.md` | 对于关键功能为高 |
-| **After Development**    | `*review`   | Comprehensive assessment                | QA Results in story + `docs/qa/gates/{epic}.{story}-{slug}.yml` | **Required**                |
+| **开发后** | `*review` | 全面评估 | 故事中的QA结果 + `docs/qa/gates/{epic}.{story}-{slug}.yml` | **必需** |
-| **Post-Review**          | `*gate`     | Update quality decision                 | Updated `docs/qa/gates/{epic}.{story}-{slug}.yml`               | As needed                   |
+| **审查后** | `*gate` | 更新质量决策 | 更新的 `docs/qa/gates/{epic}.{story}-{slug}.yml` | 根据需要 |
 
-### Stage 1: After Story Creation (Before Dev Starts)
+### 阶段1：故事创建后（开发开始前）
 
-**RECOMMENDED - Set Developer Up for Success:**
+**推荐 - 为开发人员的成功做好准备：**
 
 ```bash
-# 1. RISK ASSESSMENT (Run FIRST for complex stories)
+# 1. 风险评估（对于复杂的故事首先运行）
 @qa *risk {approved-story}
-# Identifies:
+# 识别：
-#   - Technical debt impact
+#   - 技术债务影响
-#   - Integration complexity
+#   - 集成复杂性
-#   - Regression potential (1-9 scoring)
+#   - 回归可能性（1-9评分）
-#   - Mitigation strategies
+#   - 缓解策略
-# Critical for: Brownfield, API changes, data migrations
+# 对于以下情况至关重要：棕地、API更改、数据迁移
 
-# 2. TEST DESIGN (Run SECOND to guide implementation)
+# 2. 测试设计（其次运行以指导实施）
 @qa *design {approved-story}
-# Provides:
+# 提供：
-#   - Test scenarios per acceptance criterion
+#   - 每个验收标准的测试场景
-#   - Test level recommendations (unit/integration/E2E)
+#   - 测试级别建议（单元/集成/E2E）
-#   - Risk-based priorities (P0/P1/P2)
+#   - 基于风险的优先级（P0/P1/P2）
-#   - Test data requirements
+#   - 测试数据要求
-# Share with Dev: Include in story comments or attach to ticket
+# 与开发人员共享：包含在故事评论中或附加到工单
 ```
 
-### Stage 2: During Development (Mid-Implementation Checkpoints)
+### 阶段2：开发期间（实施中期检查点）
 
-**Developer Self-Service Quality Checks:**
+**开发人员自助质量检查：**
 
 ```bash
-# 3. REQUIREMENTS TRACING (Verify coverage mid-development)
+# 3. 需求跟踪（在开发中期验证覆盖率）
 @qa *trace {story-in-progress}
-# Validates:
+# 验证：
-#   - All acceptance criteria have tests
+#   - 所有验收标准都有测试
-#   - No missing test scenarios
+#   - 没有遗漏的测试场景
-#   - Appropriate test levels
+#   - 适当的测试级别
-#   - Given-When-Then documentation clarity
+#   - Given-When-Then文档的清晰度
-# Run when: After writing initial tests
+# 运行时机：编写初始测试后
 
-# 4. NFR VALIDATION (Check quality attributes)
+# 4. NFR验证（检查质量属性）
 @qa *nfr {story-in-progress}
-# Assesses:
+# 评估：
-#   - Security: Authentication, authorization, data protection
+#   - 安全性：身份验证、授权、数据保护
-#   - Performance: Response times, resource usage
+#   - 性能：响应时间、资源使用
-#   - Reliability: Error handling, recovery
+#   - 可靠性：错误处理、恢复
-#   - Maintainability: Code quality, documentation
+#   - 可维护性：代码质量、文档
-# Run when: Before marking "Ready for Review"
+# 运行时机：标记“准备审查”之前
 ```
 
-### Stage 3: Story Review (Quality Gate Assessment)
+### 阶段3：故事审查（质量门评估）
 
-**REQUIRED - Comprehensive Test Architecture Review:**
+**必需 - 全面的测试架构审查：**
 
-**Prerequisite:** All tests green locally; lint & type checks pass.
+**先决条件：** 所有测试在本地通过；lint和类型检查通过。
 
 ```bash
-# 5. FULL REVIEW (Standard review process)
+# 5. 全面审查（标准审查流程）
 @qa *review {completed-story}
 ```
 
-**What Happens During Review:**
+**审查期间会发生什么：**
 
-1. **Deep Code Analysis**
+1.  **深度代码分析**
-   - Architecture pattern compliance
+    -   架构模式合规性
-   - Code quality and maintainability
+    -   代码质量和可维护性
-   - Security vulnerability scanning
+    -   安全漏洞扫描
-   - Performance bottleneck detection
+    -   性能瓶颈检测
 
-2. **Active Refactoring**
+2.  **主动重构**
-   - Improves code directly when safe
+    -   在安全的情况下直接改进代码
-   - Fixes obvious issues immediately
+    -   立即修复明显的问题
-   - Suggests complex refactoring for dev
+    -   为开发人员建议复杂的重构
 
-3. **Test Validation**
+3.  **测试验证**
-   - Coverage at all levels (unit/integration/E2E)
+    -   所有级别的覆盖率（单元/集成/E2E）
-   - Test quality (no flaky tests, proper assertions)
+    -   测试质量（无不稳定测试、正确的断言）
-   - Regression test adequacy
+    -   回归测试的充分性
 
-4. **Gate Decision**
+4.  **门禁决策**
-   - Creates: `docs/qa/gates/{epic}.{story}-{slug}.yml`
+    -   创建：`docs/qa/gates/{epic}.{story}-{slug}.yml`
-   - Adds: QA Results section to story file
+    -   添加：QA结果部分到故事文件
-   - Status: PASS/CONCERNS/FAIL/WAIVED
+    -   状态：PASS/CONCERNS/FAIL/WAIVED
 
-### Stage 4: Post-Review (After Addressing Issues)
+### 阶段4：审查后（解决问题后）
 
-**Update Gate Status After Fixes:**
+**修复后更新门禁状态：**
 
 ```bash
-# 6. GATE UPDATE (Document final decision)
+# 6. 门禁更新（记录最终决策）
 @qa *gate {reviewed-story}
-# Updates: Quality gate with new status
+# 更新：带有新状态的质量门禁
-# Use when: After addressing review feedback
+# 使用时机：解决审查反馈后
-# Documents: What was fixed, what was waived
+# 记录：修复了什么，豁免了什么
 ```
 
-### Understanding Gate Decisions
+### 理解门禁决策
 
-| **Status**   | **Meaning**                                  | **Action Required**     | **Can Proceed?** |
+| **状态** | **含义** | **所需操作** | **可以继续吗？** |
-| ------------ | -------------------------------------------- | ----------------------- | ---------------- |
+| --- | --- | --- | --- |
-| **PASS**     | All critical requirements met                | None                    | ✅ Yes           |
+| **PASS** | 所有关键要求均已满足 | 无 | ✅ 是 |
-| **CONCERNS** | Non-critical issues found                    | Team review recommended | ⚠️ With caution  |
+| **CONCERNS** | 发现非关键问题 | 建议团队审查 | ⚠️ 谨慎 |
-| **FAIL**     | Critical issues (security, missing P0 tests) | Must fix                | ❌ No            |
+| **FAIL** | 关键问题（安全、缺少P0测试） | 必须修复 | ❌ 否 |
-| **WAIVED**   | Issues acknowledged and accepted             | Document reasoning      | ✅ With approval |
+| **WAIVED** | 问题已确认并接受 | 记录理由 | ✅ 经批准 |
 
-### Risk-Based Testing Strategy
+### 基于风险的测试策略
 
-The Test Architect uses risk scoring to prioritize testing:
+测试架构师使用风险评分来确定测试的优先级：
 
-| **Risk Score** | **Calculation**                | **Testing Priority**      | **Gate Impact**          |
+| **风险评分** | **计算** | **测试优先级** | **门禁影响** |
-| -------------- | ------------------------------ | ------------------------- | ------------------------ |
+| --- | --- | --- | --- |
-| **9**          | High probability × High impact | P0 - Must test thoroughly | FAIL if untested         |
+| **9** | 高概率 × 高影响 | P0 - 必须彻底测试 | 如果未测试则FAIL |
-| **6**          | Medium-high combinations       | P1 - Should test well     | CONCERNS if gaps         |
+| **6** | 中高组合 | P1 - 应充分测试 | 如果有差距则CONCERNS |
-| **4**          | Medium combinations            | P1 - Should test          | CONCERNS if notable gaps |
+| **4** | 中等组合 | P1 - 应测试 | 如果有显著差距则CONCERNS |
-| **2-3**        | Low-medium combinations        | P2 - Nice to have         | Note in review           |
+| **2-3** | 中低组合 | P2 - 最好有 | 在审查中注明 |
-| **1**          | Minimal risk                   | P2 - Minimal              | Note in review           |
+| **1** | 风险极小 | P2 - 最低限度 | 在审查中注明 |
 
-### Special Situations & Best Practices
+### 特殊情况与最佳实践
 
-#### High-Risk or Brownfield Stories
+#### 高风险或棕地故事
 
 ```bash
-# ALWAYS run this sequence:
+# 始终运行此序列：
-@qa *risk {story}    # First - identify dangers
+@qa *risk {story}    # 首先 - 识别危险
-@qa *design {story}  # Second - plan defense
+@qa *design {story}  # 其次 - 规划防御
-# Then during dev:
+# 然后在开发期间：
-@qa *trace {story}   # Verify regression coverage
+@qa *trace {story}   # 验证回归覆盖率
-@qa *nfr {story}     # Check performance impact
+@qa *nfr {story}     # 检查性能影响
-# Finally:
+# 最后：
-@qa *review {story}  # Deep integration analysis
+@qa *review {story}  # 深度集成分析
 ```
 
-#### Complex Integrations
+#### 复杂集成
 
-- Run `*trace` multiple times during development
+-   在开发期间多次运行`*trace`
-- Focus on integration test coverage
+-   关注集成测试覆盖率
-- Use `*nfr` to validate cross-system performance
+-   使用`*nfr`验证跨系统性能
-- Review with extra attention to API contracts
+-   在审查时特别关注API合约
 
-#### Performance-Critical Features
+#### 性能关键功能
 
-- Run `*nfr` early and often (not just at review)
+-   尽早并经常运行`*nfr`（不仅仅是在审查时）
-- Establish performance baselines before changes
+-   在更改前建立性能基线
-- Document acceptable performance degradation
+-   记录可接受的性能下降
-- Consider load testing requirements in `*design`
+-   在`*design`中考虑负载测试要求
 
-### Test Quality Standards Enforced
+### 强制执行的测试质量标准
 
-Quinn ensures all tests meet these standards:
+Quinn确保所有测试都符合这些标准：
 
-- **No Flaky Tests**: Proper async handling, explicit waits
+-   **无不稳定测试**：正确的异步处理、明确的等待
-- **No Hard Waits**: Dynamic strategies only (polling, events)
+-   **无硬等待**：仅使用动态策略（轮询、事件）
-- **Stateless**: Tests run independently and in parallel
+-   **无状态**：测试独立并行运行
-- **Self-Cleaning**: Tests manage their own test data
+-   **自清理**：测试管理自己的测试数据
-- **Appropriate Levels**: Unit for logic, integration for interactions, E2E for journeys
+-   **适当的级别**：单元测试用于逻辑，集成测试用于交互，E2E测试用于流程
-- **Clear Assertions**: Keep assertions in tests, not buried in helpers
+-   **清晰的断言**：将断言保留在测试中，而不是埋在辅助函数里
 
-### Documentation & Audit Trail
+### 文档与审计跟踪
 
-All Test Architect activities create permanent records:
+所有测试架构师的活动都会创建永久记录：
 
-- **Assessment Reports**: Timestamped analysis in `docs/qa/assessments/`
+-   **评估报告**：位于`docs/qa/assessments/`的带时间戳的分析
-- **Gate Files**: Decision records in `docs/qa/gates/`
+-   **门禁文件**：位于`docs/qa/gates/`的决策记录
-- **Story Updates**: QA Results sections in story files
+-   **故事更新**：故事文件中的QA结果部分
-- **Traceability**: Requirements to test mapping maintained
+-   **可追溯性**：保持需求到测试的映射
 
-## Commit Changes and Push
+## 提交更改并推送
 
-1. **Commit changes**
+1.  **提交更改**
-2. **Push to remote**
+2.  **推送到远程**
 
-## Complete Development Cycle Flow
+## 完整的开发周期流程
 
-### The Full Workflow with Test Architect
+### 带有测试架构师的完整工作流
 
-1. **SM**: Create next story → Review → Approve
+1.  **SM**：创建下一个故事 → 审查 → 批准
-2. **QA (Optional)**: Risk assessment (`*risk`) → Test design (`*design`)
+2.  **QA（可选）**：风险评估（`*risk`）→ 测试设计（`*design`）
-3. **Dev**: Implement story → Write tests → Complete
+3.  **开发**：实施故事 → 编写测试 → 完成
-4. **QA (Optional)**: Mid-dev checks (`*trace`, `*nfr`)
+4.  **QA（可选）**：开发中期检查（`*trace`, `*nfr`）
-5. **Dev**: Mark Ready for Review
+5.  **开发**：标记为准备审查
-6. **QA (Required)**: Review story (`*review`) → Gate decision
+6.  **QA（必需）**：审查故事（`*review`）→ 门禁决策
-7. **Dev (If needed)**: Address issues
+7.  **开发（如果需要）**：解决问题
-8. **QA (If needed)**: Update gate (`*gate`)
+8.  **QA（如果需要）**：更新门禁（`*gate`）
-9. **Commit**: All changes
+9.  **提交**：所有更改
-10. **Push**: To remote
+10. **推送**：到远程
-11. **Continue**: Until all features implemented
+11. **继续**：直到所有功能实施完毕
 
-### Quick Decision Guide
+### 快速决策指南
 
-**Should I run Test Architect commands?**
+**我应该运行测试架构师命令吗？**
 
-| **Scenario**             | **Before Dev**                  | **During Dev**               | **After Dev**                |
+| **场景** | **开发前** | **开发中** | **开发后** |
-| ------------------------ | ------------------------------- | ---------------------------- | ---------------------------- |
+| --- | --- | --- | --- |
-| **Simple bug fix**       | Optional                        | Optional                     | Required `*review`           |
+| **简单错误修复** | 可选 | 可选 | 必需 `*review` |
-| **New feature**          | Recommended `*risk`, `*design`  | Optional `*trace`            | Required `*review`           |
+| **新功能** | 推荐 `*risk`, `*design` | 可选 `*trace` | 必需 `*review` |
-| **Brownfield change**    | **Required** `*risk`, `*design` | Recommended `*trace`, `*nfr` | Required `*review`           |
+| **棕地更改** | **必需** `*risk`, `*design` | 推荐 `*trace`, `*nfr` | 必需 `*review` |
-| **API modification**     | **Required** `*risk`, `*design` | **Required** `*trace`        | Required `*review`           |
+| **API修改** | **必需** `*risk`, `*design` | **必需** `*trace` | 必需 `*review` |
-| **Performance-critical** | Recommended `*design`           | **Required** `*nfr`          | Required `*review`           |
+| **性能关键** | 推荐 `*design` | **必需** `*nfr` | 必需 `*review` |
-| **Data migration**       | **Required** `*risk`, `*design` | **Required** `*trace`        | Required `*review` + `*gate` |
+| **数据迁移** | **必需** `*risk`, `*design` | **必需** `*trace` | 必需 `*review` + `*gate` |
 
-### Success Metrics
+### 成功指标
 
-The Test Architect helps achieve:
+测试架构师有助于实现：
 
-- **Zero regression defects** in production
+-   生产中**零回归缺陷**
-- **100% requirements coverage** with tests
+-   **100%需求覆盖率**的测试
-- **Clear quality gates** for go/no-go decisions
+-   用于**go/no-go决策**的清晰质量门禁
-- **Documented risk acceptance** for technical debt
+-   **记录在案的技术债务风险接受**
-- **Consistent test quality** across the team
+-   团队中**一致的测试质量**
-- **Shift-left testing** with early risk identification
+-   通过早期风险识别实现**左移测试**

docs/expansion-packs.md

@@ -1,280 +1,280 @@
-# The Power of BMad Expansion Packs
+# BMad扩展包的力量
 
-## Overview
+## 概述
 
-BMad Method's expansion packs unlock the framework's true potential by extending its natural language AI orchestration to ANY domain. While the core framework focuses on software development, expansion packs transform BMad into a universal AI agent system.
+BMad方法的扩展包通过将其自然语言AI编排扩展到任何领域，释放了该框架的真正潜力。虽然核心框架专注于软件开发，但扩展包将BMad转变为一个通用的AI代理系统。
 
-## Why Expansion Packs?
+## 为什么需要扩展包？
 
-### Keep Core Lean
+### 保持核心精简
 
-The core BMad framework maintains its focus on software development, ensuring dev agents have maximum context for coding. Expansion packs handle everything else.
+核心BMad框架保持其对软件开发的关注，确保开发代理在编码时拥有最大的上下文。扩展包处理其他所有事情。
 
-### Domain Expertise
+### 领域专业知识
 
-Each expansion pack provides deep, specialized knowledge without bloating the core system. Install only what you need.
+每个扩展包都提供深入、专业的知识，而不会使核心系统膨胀。只安装您需要的东西。
 
-### Community Innovation
+### 社区创新
 
-Anyone can create and share expansion packs, fostering a ecosystem of AI-powered solutions across all industries and interests.
+任何人都可以创建和共享扩展包，从而在所有行业和兴趣领域中培养一个由AI驱动的解决方案生态系统。
 
-## Technical Expansion Packs
+## 技术扩展包
 
-### Game Development Pack
+### 游戏开发包
 
-Transform your AI into a complete game development studio:
+将您的AI转变为一个完整的游戏开发工作室：
 
-- **Game Designer**: Mechanics, balance, progression systems
+-   **游戏设计师**：机制、平衡、进度系统
-- **Level Designer**: Map layouts, puzzle design, difficulty curves
+-   **关卡设计师**：地图布局、谜题设计、难度曲线
-- **Narrative Designer**: Story arcs, dialog trees, lore creation
+-   **叙事设计师**：故事情节、对话树、传说创作
-- **Art Director**: Visual style guides, asset specifications
+-   **艺术总监**：视觉风格指南、资产规格
-- **Sound Designer**: Audio direction, music themes, SFX planning
+-   **音效设计师**：音频指导、音乐主题、音效规划
 
-### Mobile Development Pack
+### 移动开发包
 
-Specialized agents for mobile app creation:
+用于移动应用创建的专业代理：
 
-- **iOS Specialist**: Swift/SwiftUI patterns, Apple guidelines
+-   **iOS专家**：Swift/SwiftUI模式、苹果指南
-- **Android Expert**: Kotlin best practices, Material Design
+-   **Android专家**：Kotlin最佳实践、Material Design
-- **Mobile UX Designer**: Touch interfaces, gesture patterns
+-   **移动UX设计师**：触摸界面、手势模式
-- **App Store Optimizer**: ASO strategies, listing optimization
+-   **应用商店优化师**：ASO策略、列表优化
-- **Performance Tuner**: Battery optimization, network efficiency
+-   **性能调优师**：电池优化、网络效率
 
-### DevOps/Infrastructure Pack
+### DevOps/基础设施包
 
-Complete infrastructure automation team:
+完整的基础设施自动化团队：
 
-- **Cloud Architect**: AWS/Azure/GCP design patterns
+-   **云架构师**：AWS/Azure/GCP设计模式
-- **Security Specialist**: Zero-trust implementation, compliance
+-   **安全专家**：零信任实施、合规性
-- **SRE Expert**: Monitoring, alerting, incident response
+-   **SRE专家**：监控、警报、事件响应
-- **Container Orchestrator**: Kubernetes, Docker optimization
+-   **容器编排器**：Kubernetes、Docker优化
-- **Cost Optimizer**: Cloud spend analysis, resource right-sizing
+-   **成本优化师**：云支出分析、资源优化
 
-### Data Science Pack
+### 数据科学包
 
-AI-powered data analysis team:
+AI驱动的数据分析团队：
 
-- **Data Scientist**: Statistical analysis, ML model selection
+-   **数据科学家**：统计分析、机器学习模型选择
-- **Data Engineer**: Pipeline design, ETL processes
+-   **数据工程师**：管道设计、ETL流程
-- **ML Engineer**: Model deployment, A/B testing
+-   **机器学习工程师**：模型部署、A/B测试
-- **Visualization Expert**: Dashboard design, insight communication
+-   **可视化专家**：仪表板设计、洞察沟通
-- **Ethics Advisor**: Bias detection, fairness assessment
+-   **伦理顾问**：偏见检测、公平性评估
 
-## Non-Technical Expansion Packs
+## 非技术扩展包
 
-### Business Strategy Pack
+### 商业策略包
 
-Complete business advisory team:
+完整的商业咨询团队：
 
-- **Strategy Consultant**: Market positioning, competitive analysis
+-   **战略顾问**：市场定位、竞争分析
-- **Financial Analyst**: Projections, unit economics, funding strategies
+-   **财务分析师**：预测、单位经济学、融资策略
-- **Operations Manager**: Process optimization, efficiency improvements
+-   **运营经理**：流程优化、效率改进
-- **Marketing Strategist**: Go-to-market plans, growth hacking
+-   **营销策略师**：市场进入计划、增长黑客
-- **HR Advisor**: Talent strategies, culture building
+-   **人力资源顾问**：人才策略、文化建设
 
-### Creative Writing Pack
+### 创意写作包
 
-Your personal writing team:
+您的个人写作团队：
 
-- **Plot Architect**: Three-act structure, story beats, pacing
+-   **情节架构师**：三幕结构、故事节拍、节奏
-- **Character Psychologist**: Deep motivations, authentic dialog
+-   **角色心理学家**：深层动机、真实对话
-- **World Builder**: Consistent universes, cultural systems
+-   **世界构建者**：一致的宇宙、文化系统
-- **Editor**: Style consistency, grammar, flow
+-   **编辑**：风格一致性、语法、流畅性
-- **Beta Reader**: Feedback simulation, plot hole detection
+-   **试读者**：反馈模拟、情节漏洞检测
 
-### Health & Wellness Pack
+### 健康与保健包
 
-Personal wellness coaching system:
+个人健康指导系统：
 
-- **Fitness Trainer**: Progressive overload, form correction
+-   **健身教练**：渐进超负荷、姿势纠正
-- **Nutritionist**: Macro planning, supplement guidance
+-   **营养师**：宏量营养素规划、补充剂指导
-- **Sleep Coach**: Circadian optimization, sleep hygiene
+-   **睡眠教练**：昼夜节律优化、睡眠卫生
-- **Stress Manager**: Coping strategies, work-life balance
+-   **压力管理者**：应对策略、工作与生活平衡
-- **Habit Engineer**: Behavior change, accountability systems
+-   **习惯工程师**：行为改变、问责制系统
 
-### Education Pack
+### 教育包
 
-Complete learning design system:
+完整的学习设计系统：
 
-- **Curriculum Architect**: Learning objectives, scope & sequence
+-   **课程架构师**：学习目标、范围与顺序
-- **Instructional Designer**: Engagement strategies, multimedia learning
+-   **教学设计师**：参与策略、多媒体学习
-- **Assessment Specialist**: Rubrics, formative/summative evaluation
+-   **评估专家**：评分标准、形成性/总结性评估
-- **Differentiation Expert**: Adaptive learning, special needs
+-   **差异化专家**：适应性学习、特殊需求
-- **EdTech Integrator**: Tool selection, digital pedagogy
+-   **教育技术集成商**：工具选择、数字教学法
 
-### Mental Health Support Pack
+### 心理健康支持包
 
-Therapeutic support system:
+治疗支持系统：
 
-- **CBT Guide**: Cognitive restructuring, thought challenging
+-   **CBT指南**：认知重构、思维挑战
-- **Mindfulness Teacher**: Meditation scripts, awareness exercises
+-   **正念老师**：冥想脚本、意识练习
-- **Journal Therapist**: Reflective prompts, emotional processing
+-   **日记治疗师**：反思性提示、情绪处理
-- **Crisis Support**: Coping strategies, safety planning
+-   **危机支持**：应对策略、安全规划
-- **Habit Tracker**: Mood monitoring, trigger identification
+-   **习惯追踪器**：情绪监测、触发因素识别
 
-### Legal Assistant Pack
+### 法律助理包
 
-Legal document and research support:
+法律文件和研究支持：
 
-- **Contract Analyst**: Term review, risk assessment
+-   **合同分析师**：条款审查、风险评估
-- **Legal Researcher**: Case law, precedent analysis
+-   **法律研究员**：判例法、先例分析
-- **Document Drafter**: Template customization, clause libraries
+-   **文件起草人**：模板定制、条款库
-- **Compliance Checker**: Regulatory alignment, audit prep
+-   **合规检查员**：法规对齐、审计准备
-- **IP Advisor**: Patent strategies, trademark guidance
+-   **知识产权顾问**：专利策略、商标指导
 
-### Real Estate Pack
+### 房地产包
 
-Property investment and management:
+房地产投资和管理：
 
-- **Market Analyst**: Comparable analysis, trend prediction
+-   **市场分析师**：可比分析、趋势预测
-- **Investment Calculator**: ROI modeling, cash flow analysis
+-   **投资计算器**：ROI建模、现金流分析
-- **Property Manager**: Tenant screening, maintenance scheduling
+-   **物业经理**：租户筛选、维护调度
-- **Flip Strategist**: Renovation ROI, project planning
+-   **翻新策略师**：装修ROI、项目规划
-- **Agent Assistant**: Listing optimization, showing prep
+-   **代理助理**：房源优化、看房准备
 
-### Personal Development Pack
+### 个人发展包
 
-Complete personal growth system:
+完整的个人成长系统：
 
-- **Life Coach**: Guides personal growth and transformation
+-   **生活教练**：指导个人成长和转型
-- **Goal Strategist**: Helps achieve objectives with SMART goals
+-   **目标策略师**：帮助实现SMART目标
-- **Habit Builder**: Creates lasting habits with accountability
+-   **习惯养成者**：通过问责制建立持久的习惯
-- **Mindset Mentor**: Develops positive thinking patterns
+-   **心态导师**：培养积极的思维模式
 
-Key tasks include:
+关键任务包括：
 
-- `goal-setting`: Defines SMART goals with action plans
+-   `goal-setting`：定义带有行动计划的SMART目标
-- `habit-tracking`: Monitors habit formation progress
+-   `habit-tracking`：监控习惯养成进度
-- `reflection-exercise`: Facilitates deep self-reflection
+-   `reflection-exercise`：促进深度自我反思
 
-## Unique & Innovative Packs
+## 独特与创新包
 
-### Role-Playing Game Master Pack
+### 角色扮演游戏主持人包
 
-AI-powered tabletop RPG assistance:
+AI驱动的桌面RPG辅助：
 
-- **World Master**: Dynamic world generation, NPC creation
+-   **世界大师**：动态世界生成、NPC创建
-- **Combat Referee**: Initiative tracking, rule clarification
+-   **战斗裁判**：先攻顺序跟踪、规则澄清
-- **Story Weaver**: Plot hooks, side quests, consequences
+-   **故事编织者**：情节钩子、支线任务、后果
-- **Character Builder**: Backstory generation, stat optimization
+-   **角色构建者**：背景故事生成、属性优化
-- **Loot Master**: Treasure generation, magic item creation
+-   **战利品大师**：宝藏生成、魔法物品创建
 
-### Life Event Planning Pack
+### 生活事件规划包
 
-Major life event coordination:
+重大生活事件协调：
 
-- **Wedding Planner**: Vendor coordination, timeline creation
+-   **婚礼策划师**：供应商协调、时间线创建
-- **Event Designer**: Theme development, decoration plans
+-   **活动设计师**：主题开发、装饰计划
-- **Budget Manager**: Cost tracking, vendor negotiation
+-   **预算经理**：成本跟踪、供应商谈判
-- **Guest Coordinator**: RSVP tracking, seating arrangements
+-   **宾客协调员**：RSVP跟踪、座位安排
-- **Timeline Keeper**: Day-of scheduling, contingency planning
+-   **时间线管理员**：当日日程安排、应急计划
 
-### Hobby Mastery Pack
+### 爱好精通包
 
-Deep dive into specific hobbies:
+深入特定爱好：
 
-- **Garden Designer**: Plant selection, seasonal planning
+-   **花园设计师**：植物选择、季节性规划
-- **Brew Master**: Recipe formulation, process optimization
+-   **酿酒大师**：配方制定、流程优化
-- **Maker Assistant**: 3D printing, woodworking, crafts
+-   **创客助理**：3D打印、木工、手工艺
-- **Collection Curator**: Organization, valuation, trading
+-   **收藏策展人**：组织、估价、交易
-- **Photography Coach**: Composition, lighting, post-processing
+-   **摄影教练**：构图、照明、后期处理
 
-### Scientific Research Pack
+### 科学研究包
 
-Research acceleration tools:
+研究加速工具：
 
-- **Literature Reviewer**: Paper summarization, gap analysis
+-   **文献综述员**：论文摘要、差距分析
-- **Hypothesis Generator**: Research question formulation
+-   **假设生成器**：研究问题制定
-- **Methodology Designer**: Experiment planning, control design
+-   **方法论设计师**：实验规划、对照设计
-- **Statistical Advisor**: Test selection, power analysis
+-   **统计顾问**：测试选择、功效分析
-- **Grant Writer**: Proposal structure, impact statements
+-   **拨款申请撰写人**：提案结构、影响陈述
 
-## Creating Your Own Expansion Pack
+## 创建您自己的扩展包
 
-### Step 1: Define Your Domain
+### 步骤1：定义您的领域
 
-What expertise are you capturing? What problems will it solve?
+您要捕获什么专业知识？它将解决什么问题？
 
-### Step 2: Design Your Agents
+### 步骤2：设计您的代理
 
-Each agent should have:
+每个代理应具有：
 
-- Clear expertise area
+-   清晰的专业知识领域
-- Specific personality traits
+-   特定的个性特征
-- Defined capabilities
+-   明确定义的能力
-- Knowledge boundaries
+-   知识边界
 
-### Step 3: Create Tasks
+### 步骤3：创建任务
 
-Tasks should be:
+任务应：
 
-- Step-by-step procedures
+-   是分步程序
-- Reusable across scenarios
+-   可在不同场景中重用
-- Clear and actionable
+-   清晰且可操作
-- Domain-specific
+-   特定于领域
 
-### Step 4: Build Templates
+### 步骤4：构建模板
 
-Templates need:
+模板需要：
 
-- Structured output format
+-   结构化的输出格式
-- Embedded LLM instructions
+-   嵌入式LLM指令
-- Placeholders for customization
+-   用于定制的占位符
-- Professional formatting
+-   专业的格式
 
-### Step 5: Test & Iterate
+### 步骤5：测试与迭代
 
-- Use with real scenarios
+-   用于真实场景
-- Gather user feedback
+-   收集用户反馈
-- Refine agent responses
+-   完善代理响应
-- Improve task clarity
+-   提高任务清晰度
 
-### Step 6: Package & Share
+### 步骤6：打包与分享
 
-- Create clear documentation
+-   创建清晰的文档
-- Include usage examples
+-   包括使用示例
-- Add to expansion-packs directory
+-   添加到expansion-packs目录
-- Share with community
+-   与社区分享
 
-## The Future of Expansion Packs
+## 扩展包的未来
 
-### Marketplace Potential
+### 市场潜力
 
-Imagine a future where:
+想象一个未来：
 
-- Professional expansion packs are sold
+-   出售专业的扩展包
-- Certified packs for regulated industries
+-   受监管行业的认证包
-- Community ratings and reviews
+-   社区评级和评论
-- Automatic updates and improvements
+-   自动更新和改进
 
-### AI Agent Ecosystems
+### AI代理生态系统
 
-Expansion packs could enable:
+扩展包可以实现：
 
-- Cross-pack agent collaboration
+-   跨包代理协作
-- Industry-standard agent protocols
+-   行业标准的代理协议
-- Interoperable AI workflows
+-   可互操作的AI工作流
-- Universal agent languages
+-   通用的代理语言
 
-### Democratizing Expertise
+### 知识民主化
 
-Every expansion pack:
+每个扩展包：
 
-- Makes expert knowledge accessible
+-   使专家知识变得可访问
-- Reduces barriers to entry
+-   降低进入门槛
-- Enables solo entrepreneurs
+-   赋能个体创业者
-- Empowers small teams
+-   赋能小团队
 
-## Getting Started
+## 开始使用
 
-1. **Browse existing packs**: Check `expansion-packs/` directory
+1.  **浏览现有包**：查看`expansion-packs/`目录
-2. **Install what you need**: Use the installer's expansion pack option
+2.  **安装您需要的**：使用安装程序的扩展包选项
-3. **Create your own**: Use the expansion-creator pack
+3.  **创建您自己的**：使用expansion-creator包
-4. **Share with others**: Submit PRs with new packs
+4.  **与他人分享**：提交带有新包的PR
-5. **Build the future**: Help shape AI-assisted work
+5.  **构建未来**：帮助塑造AI辅助工作
 
-## Remember
+## 请记住
 
-The BMad Method is more than a development framework - it's a platform for structuring human expertise into AI-accessible formats. Every expansion pack you create makes specialized knowledge more accessible to everyone.
+BMad方法不仅仅是一个开发框架——它是一个将人类专业知识结构化为AI可访问格式的平台。您创建的每个扩展包都使专业知识更容易为每个人所用。
 
-**What expertise will you share with the world?**
+**您将与世界分享什么专业知识？**

docs/how-to-contribute-with-pull-requests.md

@@ -1,158 +1,158 @@
-# How to Contribute with Pull Requests
+# 如何通过Pull Request贡献
 
-**New to GitHub and pull requests?** This guide will walk you through the basics step by step.
+**刚接触GitHub和pull request？** 本指南将逐步引导您了解基础知识。
 
-## What is a Pull Request?
+## 什么是Pull Request？
 
-A pull request (PR) is how you propose changes to a project on GitHub. Think of it as saying "Here are some changes I'd like to make - please review and consider adding them to the main project."
+Pull request (PR) 是您在GitHub上向项目提议更改的方式。可以把它想象成说“这是我想要做的一些更改——请审查并考虑将它们添加到主项目中。”
 
-## Before You Start
+## 开始之前
 
-⚠️ **Important**: Please keep your contributions small and focused! We prefer many small, clear changes rather than one massive change.
+⚠️ **重要提示**：请保持您的贡献小而专注！我们更喜欢许多小的、清晰的更改，而不是一个巨大的更改。
 
-**Required before submitting PRs:**
+**提交PR前需要：**
 
-- **For bug fixes**: Create an issue using the [bug report template](https://github.com/bmadcode/bmad-method/issues/new?template=bug_report.md)
+-   **对于错误修复**：使用[错误报告模板](https://github.com/bmadcode/bmad-method/issues/new?template=bug_report.md)创建一个issue
-- **For new features**:
+-   **对于新功能**：
-  1. Discuss in Discord [#general-dev channel](https://discord.gg/gk8jAdXWmj)
+    1.  在Discord的[#general-dev频道](https://discord.gg/gk8jAdXWmj)中讨论
-  2. Create an issue using the [feature request template](https://github.com/bmadcode/bmad-method/issues/new?template=feature_request.md)
+    2.  使用[功能请求模板](https://github.com/bmadcode/bmad-method/issues/new?template=feature_request.md)创建一个issue
-- **For large changes**: Always open an issue first to discuss alignment
+-   **对于大的更改**：始终先开一个issue来讨论对齐
 
-## Step-by-Step Guide
+## 分步指南
 
-### 1. Fork the Repository
+### 1. Fork存储库
 
-1. Go to the [BMad-Method repository](https://github.com/bmadcode/bmad-method)
+1.  转到[BMad-Method存储库](https://github.com/bmadcode/bmad-method)
-2. Click the "Fork" button in the top-right corner
+2.  点击右上角的“Fork”按钮
-3. This creates your own copy of the project
+3.  这会创建您自己的项目副本
 
-### 2. Clone Your Fork
+### 2. 克隆您的Fork
 
 ```bash
-# Replace YOUR-USERNAME with your actual GitHub username
+# 将YOUR-USERNAME替换为您的实际GitHub用户名
 git clone https://github.com/YOUR-USERNAME/bmad-method.git
 cd bmad-method
 ```
 
-### 3. Create a New Branch
+### 3. 创建一个新分支
 
-**Never work directly on the `main` branch!** Always create a new branch for your changes:
+**切勿直接在`main`分支上工作！** 始终为您的更改创建一个新分支：
 
 ```bash
-# Create and switch to a new branch
+# 创建并切换到一个新分支
 git checkout -b fix/typo-in-readme
-# or
+# 或
 git checkout -b feature/add-new-agent
 ```
 
-**Branch naming tips:**
+**分支命名技巧：**
 
-- `fix/description` - for bug fixes
+-   `fix/description` - 用于错误修复
-- `feature/description` - for new features
+-   `feature/description` - 用于新功能
-- `docs/description` - for documentation changes
+-   `docs/description` - 用于文档更改
 
-### 4. Make Your Changes
+### 4. 进行更改
 
-- Edit the files you want to change
+-   编辑您想要更改的文件
-- Keep changes small and focused on one thing
+-   保持更改小而专注
-- Test your changes if possible
+-   如果可能，测试您的更改
 
-### 5. Commit Your Changes
+### 5. 提交您的更改
 
 ```bash
-# Add your changes
+# 添加您的更改
 git add .
 
-# Commit with a clear message
+# 用清晰的消息提交
 git commit -m "Fix typo in README.md"
 ```
 
-**Good commit messages:**
+**好的提交消息：**
 
-- "Fix typo in installation instructions"
+-   “修复安装说明中的拼写错误”
-- "Add example for new agent usage"
+-   “为新代理用法添加示例”
-- "Update broken link in docs"
+-   “更新文档中的损坏链接”
 
-**Bad commit messages:**
+**不好的提交消息：**
 
-- "stuff"
+-   “东西”
-- "changes"
+-   “更改”
-- "update"
+-   “更新”
 
-### 6. Push to Your Fork
+### 6. 推送到您的Fork
 
 ```bash
-# Push your branch to your fork
+# 将您的分支推送到您的fork
 git push origin fix/typo-in-readme
 ```
 
-### 7. Create the Pull Request
+### 7. 创建Pull Request
 
-1. Go to your fork on GitHub
+1.  在GitHub上转到您的fork
-2. You'll see a green "Compare & pull request" button - click it
+2.  您会看到一个绿色的“Compare & pull request”按钮 - 点击它
-3. Select the correct target branch:
+3.  选择正确的目标分支：
-   - **`next` branch** for most contributions (features, docs, enhancements)
+    -   **`next`分支**用于大多数贡献（功能、文档、增强）
-   - **`main` branch** only for critical fixes
+    -   **`main`分支**仅用于关键修复
-4. Fill out the PR description using the template in CONTRIBUTING.md:
+4.  使用CONTRIBUTING.md中的模板填写PR描述：
-   - **What**: 1-2 sentences describing what changed
+    -   **什么**：1-2句话描述更改了什么
-   - **Why**: 1-2 sentences explaining why
+    -   **为什么**：1-2句话解释原因
-   - **How**: 2-3 bullets on implementation
+    -   **如何**：2-3个要点说明实现方式
-   - **Testing**: How you tested
+    -   **测试**：您如何测试
-5. Reference the related issue number (e.g., "Fixes #123")
+5.  引用相关的issue编号（例如，“Fixes #123”）
 
-### 8. Wait for Review
+### 8. 等待审查
 
-- A maintainer will review your PR
+-   维护人员将审查您的PR
-- They might ask for changes
+-   他们可能会要求更改
-- Be patient and responsive to feedback
+-   请耐心并对反馈做出回应
 
-## What Makes a Good Pull Request?
+## 什么是好的Pull Request？
 
-✅ **Good PRs:**
+✅ **好的PR：**
 
-- Change one thing at a time
+-   一次只更改一件事
-- Have clear, descriptive titles
+-   有清晰、描述性的标题
-- Explain what and why in the description
+-   在描述中解释了什么和为什么
-- Include only the files that need to change
+-   仅包含需要更改的文件
 
-❌ **Avoid:**
+❌ **避免：**
 
-- Changing formatting of entire files
+-   更改整个文件的格式
-- Multiple unrelated changes in one PR
+-   在一个PR中进行多个不相关的更改
-- Copying your entire project/repo into the PR
+-   将您的整个项目/存储库复制到PR中
-- Changes without explanation
+-   没有解释的更改
 
-## Common Mistakes to Avoid
+## 要避免的常见错误
 
-1. **Don't reformat entire files** - only change what's necessary
+1.  **不要重新格式化整个文件** - 只更改必要的内容
-2. **Don't include unrelated changes** - stick to one fix/feature per PR
+2.  **不要包含不相关的更改** - 每个PR只专注于一个修复/功能
-3. **Don't paste code in issues** - create a proper PR instead
+3.  **不要在issue中粘贴代码** - 创建一个合适的PR
-4. **Don't submit your whole project** - contribute specific improvements
+4.  **不要提交您的整个项目** - 贡献具体的改进
 
-## Need Help?
+## 需要帮助？
 
-- 💬 Join our [Discord Community](https://discord.gg/gk8jAdXWmj) for real-time help:
+-   💬 加入我们的[Discord社区](https://discord.gg/gk8jAdXWmj)以获得实时帮助：
-  - **#general-dev** - Technical questions and feature discussions
+    -   **#general-dev** - 技术问题和功能讨论
-  - **#bugs-issues** - Get help with bugs before filing issues
+    -   **#bugs-issues** - 在提交issue前获得有关错误的帮助
-- 💬 Ask questions in [GitHub Discussions](https://github.com/bmadcode/bmad-method/discussions)
+-   💬 在[GitHub Discussions](https://github.com/bmadcode/bmad-method/discussions)中提问
-- 🐛 Report bugs using the [bug report template](https://github.com/bmadcode/bmad-method/issues/new?template=bug_report.md)
+-   🐛 使用[错误报告模板](https://github.com/bmadcode/bmad-method/issues/new?template=bug_report.md)报告错误
-- 💡 Suggest features using the [feature request template](https://github.com/bmadcode/bmad-method/issues/new?template=feature_request.md)
+-   💡 使用[功能请求模板](https://github.com/bmadcode/bmad-method/issues/new?template=feature_request.md)建议功能
-- 📖 Read the full [Contributing Guidelines](../CONTRIBUTING.md)
+-   📖 阅读完整的[贡献指南](../CONTRIBUTING.md)
 
-## Example: Good vs Bad PRs
+## 示例：好的PR vs 坏的PR
 
-### 😀 Good PR Example
+### 😀 好的PR示例
 
-**Title**: "Fix broken link to installation guide"
+**标题**：“修复安装指南的损坏链接”
-**Changes**: One file, one line changed
+**更改**：一个文件，一行更改
-**Description**: "The link in README.md was pointing to the wrong file. Updated to point to correct installation guide."
+**描述**：“README.md中的链接指向了错误的文件。已更新为指向正确的安装指南。”
 
-### 😞 Bad PR Example
+### 😞 坏的PR示例
 
-**Title**: "Updates"
+**标题**：“更新”
-**Changes**: 50 files, entire codebase reformatted
+**更改**：50个文件，整个代码库重新格式化
-**Description**: "Made some improvements"
+**描述**：“做了一些改进”
 
 ---
 
-**Remember**: We're here to help! Don't be afraid to ask questions. Every expert was once a beginner.
+**请记住**：我们随时为您提供帮助！不要害怕提问。每个专家都曾经是初学者。

docs/user-guide.md

@@ -1,50 +1,50 @@
-# BMad Method — User Guide
+# BMad方法 — 用户指南
 
-This guide will help you understand and effectively use the BMad Method for agile AI-driven planning and development.
+本指南将帮助您理解并有效使用BMad方法进行敏捷的AI驱动规划和开发。
 
-## The BMad Plan and Execute Workflow
+## BMad规划与执行工作流
 
-First, here is the full standard Greenfield Planning + Execution Workflow. Brownfield is very similar, but it's suggested to understand this greenfield first, even if on a simple project before tackling a brownfield project. The BMad Method needs to be installed to the root of your new project folder. For the planning phase, you can optionally perform it with powerful web agents, potentially resulting in higher quality results at a fraction of the cost it would take to complete if providing your own API key or credits in some Agentic tools. For planning, powerful thinking models and larger context - along with working as a partner with the agents will net the best results.
+首先，这里是完整的标准绿地规划+执行工作流。棕地项目非常相似，但建议在处理棕地项目之前，先在一个简单的项目上理解这个绿地工作流。BMad方法需要安装到您的新项目文件夹的根目录。对于规划阶段，您可以选择使用强大的Web代理来执行，这可能会以比您自己提供API密钥或在某些代理工具中提供积分所需成本的一小部分，获得更高质量的结果。对于规划，强大的思维模型和更大的上下文——以及与代理作为合作伙伴一起工作——将获得最佳结果。
 
-If you are going to use the BMad Method with a Brownfield project (an existing project), review **[Working in the Brownfield](./working-in-the-brownfield.md)**.
+如果您打算在棕地项目（现有项目）中使用BMad方法，请查阅**[在棕地中工作](./working-in-the-brownfield.md)**。
 
-If the diagrams below don't render, install Markdown All in One along with the Markdown Preview Mermaid Support plugins to VSCode (or one of the forked clones). With these plugins, if you right click on the tab when open, there should be an Open Preview option, or check the IDE documentation.
+如果下面的图表没有渲染，请将Markdown All in One以及Markdown Preview Mermaid Support插件安装到VSCode（或其某个分叉克隆版本）。安装这些插件后，如果您在打开时右键单击选项卡，应该会有一个“打开预览”选项，或查看IDE文档。
 
-### The Planning Workflow (Web UI or Powerful IDE Agents)
+### 规划工作流（Web UI或强大的IDE代理）
 
-Before development begins, BMad follows a structured planning workflow that's ideally done in web UI for cost efficiency:
+在开发开始之前，BMad遵循一个结构化的规划工作流，为了成本效益，最好在Web UI中完成：
 
 ```mermaid
 graph TD
-    A["Start: Project Idea"] --> B{"Optional: Analyst Research"}
+    A["开始：项目构思"] --> B{"可选：分析师研究"}
-    B -->|Yes| C["Analyst: Brainstorming (Optional)"]
+    B -->|是| C["分析师：头脑风暴（可选）"]
-    B -->|No| G{"Project Brief Available?"}
+    B -->|否| G{"有项目简报吗？"}
-    C --> C2["Analyst: Market Research (Optional)"]
+    C --> C2["分析师：市场研究（可选）"]
-    C2 --> C3["Analyst: Competitor Analysis (Optional)"]
+    C2 --> C3["分析师：竞争对手分析（可选）"]
-    C3 --> D["Analyst: Create Project Brief"]
+    C3 --> D["分析师：创建项目简报"]
     D --> G
-    G -->|Yes| E["PM: Create PRD from Brief (Fast Track)"]
+    G -->|是| E["产品经理：从简报创建PRD（快速通道）"]
-    G -->|No| E2["PM: Interactive PRD Creation (More Questions)"]
+    G -->|否| E2["产品经理：交互式PRD创建（更多问题）"]
-    E --> F["PRD Created with FRs, NFRs, Epics & Stories"]
+    E --> F["创建了包含FR、NFR、史诗和故事的PRD"]
     E2 --> F
-    F --> F2{"UX Required?"}
+    F --> F2{"需要UX吗？"}
-    F2 -->|Yes| F3["UX Expert: Create Front End Spec"]
+    F2 -->|是| F3["UX专家：创建前端规范"]
-    F2 -->|No| H["Architect: Create Architecture from PRD"]
+    F2 -->|否| H["架构师：从PRD创建架构"]
-    F3 --> F4["UX Expert: Generate UI Prompt for Lovable/V0 (Optional)"]
+    F3 --> F4["UX专家：为Lovable/V0生成UI提示（可选）"]
-    F4 --> H2["Architect: Create Architecture from PRD + UX Spec"]
+    F4 --> H2["架构师：从PRD+UX规范创建架构"]
-    H --> Q{"Early Test Strategy? (Optional)"}
+    H --> Q{"早期测试策略？（可选）"}
     H2 --> Q
-    Q -->|Yes| R["QA: Early Test Architecture Input on High-Risk Areas"]
+    Q -->|是| R["QA：高风险区域的早期测试架构输入"]
-    Q -->|No| I
+    Q -->|否| I
-    R --> I["PO: Run Master Checklist"]
+    R --> I["产品负责人：运行主清单"]
-    I --> J{"Documents Aligned?"}
+    I --> J{"文档是否对齐？"}
-    J -->|Yes| K["Planning Complete"]
+    J -->|是| K["规划完成"]
-    J -->|No| L["PO: Update Epics & Stories"]
+    J -->|否| L["产品负责人：更新史诗和故事"]
-    L --> M["Update PRD/Architecture as needed"]
+    L --> M["根据需要更新PRD/架构"]
     M --> I
-    K --> N["📁 Switch to IDE (If in a Web Agent Platform)"]
+    K --> N["📁 切换到IDE（如果在Web代理平台中）"]
-    N --> O["PO: Shard Documents"]
+    N --> O["产品负责人：分片文档"]
-    O --> P["Ready for SM/Dev Cycle"]
+    O --> P["准备好进行SM/Dev循环"]
 
     style A fill:#f5f5f5,color:#000
     style B fill:#e3f2fd,color:#000
@@ -73,64 +73,64 @@ graph TD
     style P fill:#34a853,color:#fff
 ```
 
-#### Web UI to IDE Transition
+#### Web UI到IDE的转换
 
-**Critical Transition Point**: Once the PO confirms document alignment, you must switch from web UI to IDE to begin the development workflow:
+**关键转换点**：一旦产品负责人确认文档对齐，您必须从Web UI切换到IDE以开始开发工作流：
 
-1. **Copy Documents to Project**: Ensure `docs/prd.md` and `docs/architecture.md` are in your project's docs folder (or a custom location you can specify during installation)
+1.  **将文档复制到项目**：确保`docs/prd.md`和`docs/architecture.md`位于您项目的docs文件夹中（或您在安装期间可以指定的自定义位置）
-2. **Switch to IDE**: Open your project in your preferred Agentic IDE
+2.  **切换到IDE**：在您首选的代理IDE中打开您的项目
-3. **Document Sharding**: Use the PO agent to shard the PRD and then the Architecture
+3.  **文档分片**：使用PO代理分片PRD，然后分片架构
-4. **Begin Development**: Start the Core Development Cycle that follows
+4.  **开始开发**：开始遵循核心开发周期
 
-#### Planning Artifacts (Standard Paths)
+#### 规划工件（标准路径）
 
 ```text
 PRD              → docs/prd.md
-Architecture     → docs/architecture.md
+架构     → docs/architecture.md
-Sharded Epics    → docs/epics/
+分片的史诗    → docs/epics/
-Sharded Stories  → docs/stories/
+分片的故事  → docs/stories/
-QA Assessments   → docs/qa/assessments/
+QA评估   → docs/qa/assessments/
-QA Gates         → docs/qa/gates/
+QA门禁         → docs/qa/gates/
 ```
 
-### The Core Development Cycle (IDE)
+### 核心开发周期（IDE）
 
-Once planning is complete and documents are sharded, BMad follows a structured development workflow:
+一旦规划完成并且文档被分片，BMad将遵循一个结构化的开发工作流：
 
 ```mermaid
 graph TD
-    A["Development Phase Start"] --> B["SM: Reviews Previous Story Dev/QA Notes"]
+    A["开发阶段开始"] --> B["SM：审查上一个故事的开发/QA说明"]
-    B --> B2["SM: Drafts Next Story from Sharded Epic + Architecture"]
+    B --> B2["SM：从分片的史诗+架构中起草下一个故事"]
-    B2 --> S{"High-Risk Story? (Optional)"}
+    B2 --> S{"高风险故事？（可选）"}
-    S -->|Yes| T["QA: *risk + *design on Draft Story"]
+    S -->|是| T["QA：对草稿故事进行*risk + *design"]
-    S -->|No| B3
+    S -->|否| B3
-    T --> U["Test Strategy & Risk Profile Created"]
+    T --> U["创建了测试策略和风险概况"]
-    U --> B3{"PO: Validate Story Draft (Optional)"}
+    U --> B3{"PO：验证故事草稿（可选）"}
-    B3 -->|Validation Requested| B4["PO: Validate Story Against Artifacts"]
+    B3 -->|请求验证| B4["PO：根据工件验证故事"]
-    B3 -->|Skip Validation| C{"User Approval"}
+    B3 -->|跳过验证| C{"用户批准"}
     B4 --> C
-    C -->|Approved| D["Dev: Sequential Task Execution"]
+    C -->|已批准| D["开发：顺序执行任务"]
-    C -->|Needs Changes| B2
+    C -->|需要更改| B2
-    D --> E["Dev: Implement Tasks + Tests"]
+    D --> E["开发：实施任务+测试"]
-    E --> V{"Mid-Dev QA Check? (Optional)"}
+    E --> V{"开发中期QA检查？（可选）"}
-    V -->|Yes| W["QA: *trace or *nfr for Early Validation"]
+    V -->|是| W["QA：用于早期验证的*trace或*nfr"]
-    V -->|No| F
+    V -->|否| F
-    W --> X["Dev: Address Coverage/NFR Gaps"]
+    W --> X["开发：解决覆盖率/NFR差距"]
-    X --> F["Dev: Run All Validations"]
+    X --> F["开发：运行所有验证"]
-    F --> G["Dev: Mark Ready for Review + Add Notes"]
+    F --> G["开发：标记为待审查+添加说明"]
-    G --> H{"User Verification"}
+    G --> H{"用户验证"}
-    H -->|Request QA Review| I["QA: Test Architect Review + Quality Gate"]
+    H -->|请求QA审查| I["QA：测试架构师审查+质量门禁"]
-    H -->|Approve Without QA| M["IMPORTANT: Verify All Regression Tests and Linting are Passing"]
+    H -->|未经QA批准| M["重要：验证所有回归测试和Linting都通过"]
-    I --> J["QA: Test Architecture Analysis + Active Refactoring"]
+    I --> J["QA：测试架构分析+主动重构"]
-    J --> L{"QA Decision"}
+    J --> L{"QA决策"}
-    L -->|Needs Dev Work| D
+    L -->|需要开发工作| D
-    L -->|Approved| M
+    L -->|已批准| M
-    H -->|Needs Fixes| D
+    H -->|需要修复| D
-    M --> N["IMPORTANT: COMMIT YOUR CHANGES BEFORE PROCEEDING!"]
+    M --> N["重要：在继续之前提交您的更改！"]
-    N --> Y{"Gate Update Needed?"}
+    N --> Y{"需要更新门禁吗？"}
-    Y -->|Yes| Z["QA: *gate to Update Status"]
+    Y -->|是| Z["QA：*gate更新状态"]
-    Y -->|No| K
+    Y -->|否| K
-    Z --> K["Mark Story as Done"]
+    Z --> K["将故事标记为完成"]
     K --> B
 
     style A fill:#f5f5f5,color:#000
@@ -160,52 +160,52 @@ graph TD
     style Z fill:#ffd54f,color:#000
 ```
 
-## Prerequisites
+## 先决条件
 
-Before installing BMad Method, ensure you have:
+在安装BMad方法之前，请确保您有：
 
 -   **Node.js** ≥ 18, **npm** ≥ 9
-- **Git** installed and configured
+-   已安装并配置**Git**
-- **(Optional)** VS Code with "Markdown All in One" + "Markdown Preview Mermaid Support" extensions
+-   **（可选）** VS Code及“Markdown All in One”+“Markdown Preview Mermaid Support”扩展
 
-## Installation
+## 安装
 
-### Optional
+### 可选
 
-If you want to do the planning on the web with Claude (Sonnet 4 or Opus), Gemini Gem (2.5 Pro), or Custom GPTs:
+如果您想在Web上使用Claude（Sonnet 4或Opus）、Gemini Gem（2.5 Pro）或自定义GPT进行规划：
 
-1. Navigate to `dist/teams/`
+1.  导航到`dist/teams/`
-2. Copy `team-fullstack.txt`
+2.  复制`team-fullstack.txt`
-3. Create new Gemini Gem or CustomGPT
+3.  创建新的Gemini Gem或自定义GPT
-4. Upload file with instructions: "Your critical operating instructions are attached, do not break character as directed"
+4.  上传文件并附上说明：“您的关键操作说明已附上，请按指示不要脱离角色”
-5. Type `/help` to see available commands
+5.  输入`/help`查看可用命令
 
-### IDE Project Setup
+### IDE项目设置
 
 ```bash
-# Interactive installation (recommended)
+# 交互式安装（推荐）
 npx bmad-method install
 ```
 
-## Special Agents
+## 特殊代理
 
-There are two BMad agents — in the future they'll be consolidated into a single BMad-Master.
+有两个BMad代理——将来它们将被合并为一个单一的BMad-Master。
 
 ### BMad-Master
 
-This agent can do any task or command that all other agents can do, aside from actual story implementation. Additionally, this agent can help explain the BMad Method when on the web by accessing the knowledge base and explaining anything to you about the process.
+除了实际的故事实施外，该代理可以执行所有其他代理可以执行的任何任务或命令。此外，该代理可以通过访问知识库并向您解释有关流程的任何内容，来帮助在Web上解释BMad方法。
 
-If you don't want to bother switching between different agents aside from the dev, this is the agent for you. Just remember that as the context grows, the performance of the agent degrades, therefore it is important to instruct the agent to compact the conversation and start a new conversation with the compacted conversation as the initial message. Do this often, preferably after each story is implemented.
+如果您不想除了开发之外在不同代理之间切换，那么这个代理适合您。只需记住，随着上下文的增长，代理的性能会下降，因此指示代理压缩对话并以压缩后的对话作为初始消息开始新的对话非常重要。请经常这样做，最好在每个故事实施后都这样做。
 
 ### BMad-Orchestrator
 
-This agent should NOT be used within the IDE, it is a heavyweight, special-purpose agent that utilizes a lot of context and can morph into any other agent. This exists solely to facilitate the teams within the web bundles. If you use a web bundle you will be greeted by the BMad Orchestrator.
+该代理不应在IDE中使用，它是一个重量级的、特殊用途的代理，利用大量上下文，并且可以变形为任何其他代理。它仅用于促进Web包中的团队。如果您使用Web包，您将被BMad Orchestrator迎接。
 
-### How Agents Work
+### 代理如何工作
 
-#### Dependencies System
+#### 依赖系统
 
-Each agent has a YAML section that defines its dependencies:
+每个代理都有一个YAML部分，定义其依赖关系：
 
 ```yaml
 dependencies:
@@ -219,97 +219,97 @@ dependencies:
     - bmad-kb.md
 ```
 
-**Key Points:**
+**要点：**
 
-- Agents only load resources they need (lean context)
+-   代理只加载它们需要的资源（精简上下文）
-- Dependencies are automatically resolved during bundling
+-   依赖项在打包过程中自动解析
-- Resources are shared across agents to maintain consistency
+-   资源在代理之间共享以保持一致性
 
-#### Agent Interaction
+#### 代理交互
 
-**In IDE:**
+**在IDE中：**
 
 ```bash
-# Some IDEs, like Cursor or Windsurf for example, utilize manual rules so interaction is done with the '@' symbol
+# 某些IDE，例如Cursor或Windsurf，使用手动规则，因此交互是通过“@”符号完成的
-@pm Create a PRD for a task management app
+@pm 为任务管理应用创建一个PRD
-@architect Design the system architecture
+@architect 设计系统架构
-@dev Implement the user authentication
+@dev 实施用户身份验证
 
-# Some IDEs, like Claude Code, use slash commands instead
+# 某些IDE，例如Claude Code，使用斜杠命令
-/pm Create user stories
+/pm 创建用户故事
-/dev Fix the login bug
+/dev 修复登录错误
 ```
 
-#### Interactive Modes
+#### 交互模式
 
-- **Incremental Mode**: Step-by-step with user input
+-   **增量模式**：逐步进行，需要用户输入
-- **YOLO Mode**: Rapid generation with minimal interaction
+-   **YOLO模式**：快速生成，交互最少
 
-## IDE Integration
+## IDE集成
 
-### IDE Best Practices
+### IDE最佳实践
 
-- **Context Management**: Keep relevant files only in context, keep files as lean and focused as necessary
+-   **上下文管理**：仅在上下文中保留相关文件，保持文件尽可能精简和专注
-- **Agent Selection**: Use appropriate agent for task
+-   **代理选择**：为任务使用适当的代理
-- **Iterative Development**: Work in small, focused tasks
+-   **迭代开发**：以小的、专注的任务进行工作
-- **File Organization**: Maintain clean project structure
+-   **文件组织**：保持干净的项目结构
-- **Commit Regularly**: Save your work frequently
+-   **定期提交**：经常保存您的工作
 
-## The Test Architect (QA Agent)
+## 测试架构师（QA代理）
 
-### Overview
+### 概述
 
-The QA agent in BMad is not just a "senior developer reviewer" - it's a **Test Architect** with deep expertise in test strategy, quality gates, and risk-based testing. Named Quinn, this agent provides advisory authority on quality matters while actively improving code when safe to do so.
+BMad中的QA代理不仅仅是一个“高级开发人员审查员”——它是一个在测试策略、质量门禁和基于风险的测试方面拥有深厚专业知识的**测试架构师**。这个名为Quinn的代理在质量问题上提供咨询权威，同时在安全的情况下积极改进代码。
 
-#### Quick Start (Essential Commands)
+#### 快速入门（基本命令）
 
 ```bash
-@qa *risk {story}       # Assess risks before development
+@qa *risk {story}       # 开发前评估风险
-@qa *design {story}     # Create test strategy
+@qa *design {story}     # 创建测试策略
-@qa *trace {story}      # Verify test coverage during dev
+@qa *trace {story}      # 开发期间验证测试覆盖率
-@qa *nfr {story}        # Check quality attributes
+@qa *nfr {story}        # 检查质量属性
-@qa *review {story}     # Full assessment → writes gate
+@qa *review {story}     # 全面评估 → 写入门禁
 ```
 
-#### Command Aliases (Test Architect)
+#### 命令别名（测试架构师）
 
-The documentation uses short forms for convenience. Both styles are valid:
+为了方便，文档使用简写形式。两种样式都有效：
 
 ```text
 *risk    → *risk-profile
 *design  → *test-design
 *nfr     → *nfr-assess
-*trace   → *trace-requirements (or just *trace)
+*trace   → *trace-requirements（或仅*trace）
 *review  → *review
 *gate    → *gate
 ```
 
-### Core Capabilities
+### 核心能力
 
-#### 1. Risk Profiling (`*risk`)
+#### 1. 风险分析 (`*risk`)
 
-**When:** After story draft, before development begins (earliest intervention point)
+**何时：** 故事草稿后，开发开始前（最早的干预点）
 
-Identifies and assesses implementation risks:
+识别和评估实施风险：
 
-- **Categories**: Technical, Security, Performance, Data, Business, Operational
+-   **类别**：技术、安全、性能、数据、业务、运营
-- **Scoring**: Probability × Impact analysis (1-9 scale)
+-   **评分**：概率×影响分析（1-9分制）
-- **Mitigation**: Specific strategies for each identified risk
+-   **缓解**：针对每个已识别风险的具体策略
-- **Gate Impact**: Risks ≥9 trigger FAIL, ≥6 trigger CONCERNS (see `tasks/risk-profile.md` for authoritative rules)
+-   **门禁影响**：风险≥9触发FAIL，≥6触发CONCERNS（ authoritative rules请参见`tasks/risk-profile.md`）
 
-#### 2. Test Design (`*design`)
+#### 2. 测试设计 (`*design`)
 
-**When:** After story draft, before development begins (guides what tests to write)
+**何时：** 故事草稿后，开发开始前（指导要编写哪些测试）
 
-Creates comprehensive test strategies including:
+创建全面的测试策略，包括：
 
-- Test scenarios for each acceptance criterion
+-   每个验收标准的测试场景
-- Appropriate test level recommendations (unit vs integration vs E2E)
+-   适当的测试级别建议（单元vs集成vs端到端）
-- Risk-based prioritization (P0/P1/P2)
+-   基于风险的优先级（P0/P1/P2）
-- Test data requirements and mock strategies
+-   测试数据要求和模拟策略
-- Execution strategies for CI/CD integration
+-   CI/CD集成的执行策略
 
-**Example output:**
+**示例输出：**
 
 ```yaml
 test_summary:
@@ -319,167 +319,167 @@ test_summary:
     integration: 7
     e2e: 2
   by_priority:
-    P0: 8 # Must have - linked to critical risks
+    P0: 8 # 必须有 - 与关键风险相关
-    P1: 10 # Should have - medium risks
+    P1: 10 # 应该有 - 中等风险
-    P2: 6 # Nice to have - low risks
+    P2: 6 # 最好有 - 低风险
 ```
 
-#### 3. Requirements Tracing (`*trace`)
+#### 3. 需求跟踪 (`*trace`)
 
-**When:** During development (mid-implementation checkpoint)
+**何时：** 开发期间（实施中期检查点）
 
-Maps requirements to test coverage:
+将需求映射到测试覆盖范围：
 
-- Documents which tests validate each acceptance criterion
+-   记录哪些测试验证了每个验收标准
-- Uses Given-When-Then for clarity (documentation only, not BDD code)
+-   使用Given-When-Then以求清晰（仅文档，非BDD代码）
-- Identifies coverage gaps with severity ratings
+-   识别带有严重性评级的覆盖差距
-- Creates traceability matrix for audit purposes
+-   为审计目的创建可追溯性矩阵
 
-#### 4. NFR Assessment (`*nfr`)
+#### 4. NFR评估 (`*nfr`)
 
-**When:** During development or early review (validate quality attributes)
+**何时：** 开发期间或早期审查（验证质量属性）
 
-Validates non-functional requirements:
+验证非功能性需求：
 
-- **Core Four**: Security, Performance, Reliability, Maintainability
+-   **核心四项**：安全性、性能、可靠性、可维护性
-- **Evidence-Based**: Looks for actual implementation proof
+-   **基于证据**：寻找实际的实施证明
-- **Gate Integration**: NFR failures directly impact quality gates
+-   **门禁集成**：NFR失败直接影响质量门禁
 
-#### 5. Comprehensive Test Architecture Review (`*review`)
+#### 5. 全面的测试架构审查 (`*review`)
 
-**When:** After development complete, story marked "Ready for Review"
+**何时：** 开发完成，故事标记为“准备审查”
 
-When you run `@qa *review {story}`, Quinn performs:
+当您运行`@qa *review {story}`时，Quinn会执行：
 
-- **Requirements Traceability**: Maps every acceptance criterion to its validating tests
+-   **需求可追溯性**：将每个验收标准映射到其验证测试
-- **Test Level Analysis**: Ensures appropriate testing at unit, integration, and E2E levels
+-   **测试级别分析**：确保在单元、集成和端到端级别进行适当的测试
-- **Coverage Assessment**: Identifies gaps and redundant test coverage
+-   **覆盖率评估**：识别差距和冗余的测试覆盖
-- **Active Refactoring**: Improves code quality directly when safe
+-   **主动重构**：在安全的情况下直接提高代码质量
-- **Quality Gate Decision**: Issues PASS/CONCERNS/FAIL status based on findings
+-   **质量门禁决策**：根据发现发布PASS/CONCERNS/FAIL状态
 
-#### 6. Quality Gates (`*gate`)
+#### 6. 质量门禁 (`*gate`)
 
-**When:** After review fixes or when gate status needs updating
+**何时：** 审查修复后或需要更新门禁状态时
 
-Manages quality gate decisions:
+管理质量门禁决策：
 
-- **Deterministic Rules**: Clear criteria for PASS/CONCERNS/FAIL
+-   **确定性规则**：PASS/CONCERNS/FAIL的明确标准
-- **Parallel Authority**: QA owns gate files in `docs/qa/gates/`
+-   **并行权限**：QA在`docs/qa/gates/`中拥有门禁文件
-- **Advisory Nature**: Provides recommendations, not blocks
+-   **咨询性质**：提供建议，而非阻塞
-- **Waiver Support**: Documents accepted risks when needed
+-   **豁免支持**：在需要时记录接受的风险
 
-**Note:** Gates are advisory; teams choose their quality bar. WAIVED requires reason, approver, and expiry date. See `templates/qa-gate-tmpl.yaml` for schema and `tasks/review-story.md` (gate rules) and `tasks/risk-profile.md` for scoring.
+**注意：** 门禁是咨询性的；团队选择他们的质量标准。豁免需要理由、批准人和到期日期。有关模式，请参见`templates/qa-gate-tmpl.yaml`，有关门禁规则和评分，请参见`tasks/review-story.md`和`tasks/risk-profile.md`。
 
-### Working with the Test Architect
+### 与测试架构师合作
 
-#### Integration with BMad Workflow
+#### 与BMad工作流集成
 
-The Test Architect provides value throughout the entire development lifecycle. Here's when and how to leverage each capability:
+测试架构师在整个开发生命周期中提供价值。以下是何时以及如何利用每项功能：
 
-| **Stage**          | **Command** | **When to Use**         | **Value**                  | **Output**                                                     |
+| **阶段** | **命令** | **何时使用** | **价值** | **输出** |
-| ------------------ | ----------- | ----------------------- | -------------------------- | -------------------------------------------------------------- |
+| --- | --- | --- | --- | --- |
-| **Story Drafting** | `*risk`     | After SM drafts story   | Identify pitfalls early    | `docs/qa/assessments/{epic}.{story}-risk-{YYYYMMDD}.md`        |
+| **故事起草** | `*risk` | SM起草故事后 | 及早识别陷阱 | `docs/qa/assessments/{epic}.{story}-risk-{YYYYMMDD}.md` |
-|                    | `*design`   | After risk assessment   | Guide dev on test strategy | `docs/qa/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md` |
+| | `*design` | 风险评估后 | 指导开发测试策略 | `docs/qa/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md` |
-| **Development**    | `*trace`    | Mid-implementation      | Verify test coverage       | `docs/qa/assessments/{epic}.{story}-trace-{YYYYMMDD}.md`       |
+| **开发** | `*trace` | 实施中期 | 验证测试覆盖率 | `docs/qa/assessments/{epic}.{story}-trace-{YYYYMMDD}.md` |
-|                    | `*nfr`      | While building features | Catch quality issues early | `docs/qa/assessments/{epic}.{story}-nfr-{YYYYMMDD}.md`         |
+| | `*nfr` | 构建功能时 | 及早发现质量问题 | `docs/qa/assessments/{epic}.{story}-nfr-{YYYYMMDD}.md` |
-| **Review**         | `*review`   | Story marked complete   | Full quality assessment    | QA Results in story + gate file                                |
+| **审查** | `*review` | 故事标记为完成 | 全面质量评估 | 故事中的QA结果+门禁文件 |
-| **Post-Review**    | `*gate`     | After fixing issues     | Update quality decision    | Updated `docs/qa/gates/{epic}.{story}-{slug}.yml`              |
+| **审查后** | `*gate` | 修复问题后 | 更新质量决策 | 更新的`docs/qa/gates/{epic}.{story}-{slug}.yml` |
 
-#### Example Commands
+#### 示例命令
 
 ```bash
-# Planning Stage - Run these BEFORE development starts
+# 规划阶段 - 在开发开始前运行这些命令
-@qa *risk {draft-story}     # What could go wrong?
+@qa *risk {draft-story}     # 可能会出什么问题？
-@qa *design {draft-story}   # What tests should we write?
+@qa *design {draft-story}   # 我们应该编写哪些测试？
 
-# Development Stage - Run these DURING coding
+# 开发阶段 - 在编码期间运行这些命令
-@qa *trace {story}          # Are we testing everything?
+@qa *trace {story}          # 我们是否测试了所有内容？
-@qa *nfr {story}            # Are we meeting quality standards?
+@qa *nfr {story}            # 我们是否符合质量标准？
 
-# Review Stage - Run when development complete
+# 审查阶段 - 开发完成后运行
-@qa *review {story}         # Comprehensive assessment + refactoring
+@qa *review {story}         # 全面评估+重构
 
-# Post-Review - Run after addressing issues
+# 审查后 - 解决问题后运行
-@qa *gate {story}           # Update gate status
+@qa *gate {story}           # 更新门禁状态
 ```
 
-### Quality Standards Enforced
+### 强制执行的质量标准
 
-Quinn enforces these test quality principles:
+Quinn强制执行这些测试质量原则：
 
-- **No Flaky Tests**: Ensures reliability through proper async handling
+-   **无不稳定测试**：通过适当的异步处理确保可靠性
-- **No Hard Waits**: Dynamic waiting strategies only
+-   **无硬等待**：仅使用动态等待策略
-- **Stateless & Parallel-Safe**: Tests run independently
+-   **无状态且并行安全**：测试独立运行
-- **Self-Cleaning**: Tests manage their own test data
+-   **自清理**：测试管理自己的测试数据
-- **Appropriate Test Levels**: Unit for logic, integration for interactions, E2E for journeys
+-   **适当的测试级别**：单元测试用于逻辑，集成测试用于交互，E2E测试用于流程
-- **Explicit Assertions**: Keep assertions in tests, not helpers
+-   **明确的断言**：将断言保留在测试中，而不是辅助函数中
 
-### Gate Status Meanings
+### 门禁状态含义
 
-- **PASS**: All critical requirements met, no blocking issues
+-   **PASS**：所有关键要求均已满足，没有阻塞性问题
-- **CONCERNS**: Non-critical issues found, team should review
+-   **CONCERNS**：发现非关键问题，团队应审查
-- **FAIL**: Critical issues that should be addressed (security risks, missing P0 tests)
+-   **FAIL**：应解决的关键问题（安全风险、缺少P0测试）
-- **WAIVED**: Issues acknowledged but explicitly accepted by team
+-   **WAIVED**：问题已确认但团队明确豁免
 
-### Special Situations
+### 特殊情况
 
-**High-Risk Stories:**
+**高风险故事：**
 
-- Always run `*risk` and `*design` before development starts
+-   在开发开始前始终运行`*risk`和`*design`
-- Consider mid-development `*trace` and `*nfr` checkpoints
+-   考虑开发中期的`*trace`和`*nfr`检查点
 
-**Complex Integrations:**
+**复杂集成：**
 
-- Run `*trace` during development to ensure all integration points tested
+-   在开发期间运行`*trace`以确保所有集成点都经过测试
-- Follow up with `*nfr` to validate performance across integrations
+-   跟进`*nfr`以验证跨集成的性能
 
-**Performance-Critical:**
+**性能关键：**
 
-- Run `*nfr` early and often during development
+-   在开发期间尽早并经常运行`*nfr`
-- Don't wait until review to discover performance issues
+-   不要等到审查时才发现性能问题
 
-**Brownfield/Legacy Code:**
+**棕地/遗留代码：**
 
-- Start with `*risk` to identify regression dangers
+-   从`*risk`开始以识别回归危险
-- Use `*review` with extra focus on backward compatibility
+-   使用`*review`时要特别注意向后兼容性
 
-### Best Practices
+### 最佳实践
 
-- **Early Engagement**: Run `*design` and `*risk` during story drafting
+-   **早期参与**：在故事起草期间运行`*design`和`*risk`
-- **Risk-Based Focus**: Let risk scores drive test prioritization
+-   **基于风险的关注**：让风险评分驱动测试优先级
-- **Iterative Improvement**: Use QA feedback to improve future stories
+-   **迭代改进**：使用QA反馈来改进未来的故事
-- **Gate Transparency**: Share gate decisions with the team
+-   **门禁透明度**：与团队共享门禁决策
-- **Continuous Learning**: QA documents patterns for team knowledge sharing
+-   **持续学习**：QA记录模式以供团队知识共享
-- **Brownfield Care**: Pay extra attention to regression risks in existing systems
+-   **棕地关怀**：特别注意现有系统中的回归风险
 
-### Output Paths Reference
+### 输出路径参考
 
-Quick reference for where Test Architect outputs are stored:
+测试架构师输出存储位置的快速参考：
 
 ```text
 *risk-profile  → docs/qa/assessments/{epic}.{story}-risk-{YYYYMMDD}.md
 *test-design   → docs/qa/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md
 *trace         → docs/qa/assessments/{epic}.{story}-trace-{YYYYMMDD}.md
 *nfr-assess    → docs/qa/assessments/{epic}.{story}-nfr-{YYYYMMDD}.md
-*review        → QA Results section in story + gate file reference
+*review        → 故事中的QA结果部分+门禁文件参考
 *gate          → docs/qa/gates/{epic}.{story}-{slug}.yml
 ```
 
-## Technical Preferences System
+## 技术偏好系统
 
-BMad includes a personalization system through the `technical-preferences.md` file located in `.bmad-core/data/` - this can help bias the PM and Architect to recommend your preferences for design patterns, technology selection, or anything else you would like to put in here.
+BMad通过位于`.bmad-core/data/`中的`technical-preferences.md`文件包含了一个个性化系统 - 这可以帮助PM和架构师偏向于推荐您对设计模式、技术选择或您想在此处添加的任何其他内容。
 
-### Using with Web Bundles
+### 与Web包一起使用
 
-When creating custom web bundles or uploading to AI platforms, include your `technical-preferences.md` content to ensure agents have your preferences from the start of any conversation.
+在创建自定义Web包或上传到AI平台时，请包含您的`technical-preferences.md`内容，以确保代理在任何对话开始时都具有您的偏好。
 
-## Core Configuration
+## 核心配置
 
-The `bmad-core/core-config.yaml` file is a critical config that enables BMad to work seamlessly with differing project structures, more options will be made available in the future. Currently the most important is the devLoadAlwaysFiles list section in the yaml.
+`bmad-core/core-config.yaml`文件是一个关键配置，它使BMad能够与不同的项目结构无缝协作，将来会提供更多选项。目前最重要的是yaml中的devLoadAlwaysFiles列表部分。
 
-### Developer Context Files
+### 开发人员上下文文件
 
-Define which files the dev agent should always load:
+定义开发代理应始终加载哪些文件：
 
 ```yaml
 devLoadAlwaysFiles:
@@ -488,17 +488,17 @@ devLoadAlwaysFiles:
   - docs/architecture/project-structure.md
 ```
 
-You will want to verify from sharding your architecture that these documents exist, that they are as lean as possible, and contain exactly the information you want your dev agent to ALWAYS load into its context. These are the rules the agent will follow.
+您需要验证从您的架构分片中这些文档是否存在，它们是否尽可能精简，并准确包含您希望您的开发代理始终加载到其上下文中的信息。这些是代理将遵循的规则。
 
-As your project grows and the code starts to build consistent patterns, coding standards should be reduced to include only the standards the agent still needs enforced. The agent will look at surrounding code in files to infer the coding standards that are relevant to the current task.
+随着您的项目增长并且代码开始构建一致的模式，编码标准应减少到仅包括代理仍然需要强制执行的标准。代理将查看文件中的周围代码以推断与当前任务相关的编码标准。
 
-## Getting Help
+## 获取帮助
 
-- **Discord Community**: [Join Discord](https://discord.gg/gk8jAdXWmj)
+-   **Discord社区**：[加入Discord](https://discord.gg/gk8jAdXWmj)
-- **GitHub Issues**: [Report bugs](https://github.com/bmadcode/bmad-method/issues)
+-   **GitHub Issues**：[报告错误](https://github.com/bmadcode/bmad-method/issues)
-- **Documentation**: [Browse docs](https://github.com/bmadcode/bmad-method/docs)
+-   **文档**：[浏览文档](https://github.com/bmadcode/bmad-method/docs)
-- **YouTube**: [BMadCode Channel](https://www.youtube.com/@BMadCode)
+-   **YouTube**：[BMadCode频道](https://www.youtube.com/@BMadCode)
 
-## Conclusion
+## 结论
 
-Remember: BMad is designed to enhance your development process, not replace your expertise. Use it as a powerful tool to accelerate your projects while maintaining control over design decisions and implementation details.
+请记住：BMad旨在增强您的开发过程，而不是取代您的专业知识。将其作为加速项目同时保持对设计决策和实施细节控制的强大工具。

docs/versioning-and-releases.md

@@ -1,130 +1,130 @@
-# Versioning and Releases
+# 版本控制和发布
 
-BMad Method uses a simplified release system with manual control and automatic release notes generation.
+BMad方法使用一个简化的发布系统，具有手动控制和自动生成发布说明的功能。
 
-## 🚀 Release Workflow
+## 🚀 发布工作流
 
-### Command Line Release (Recommended)
+### 命令行发布（推荐）
 
-The fastest way to create a release with beautiful release notes:
+创建带有精美发布说明的发布的最快方法：
 
 ```bash
-# Preview what will be in the release
+# 预览发布内容
 npm run preview:release
 
-# Create a release
+# 创建一个发布
-npm run release:patch    # 5.1.0 → 5.1.1 (bug fixes)
+npm run release:patch    # 5.1.0 → 5.1.1 (错误修复)
-npm run release:minor    # 5.1.0 → 5.2.0 (new features)
+npm run release:minor    # 5.1.0 → 5.2.0 (新功能)
-npm run release:major    # 5.1.0 → 6.0.0 (breaking changes)
+npm run release:major    # 5.1.0 → 6.0.0 (重大更改)
 
-# Watch the release process
+# 观察发布过程
 npm run release:watch
 ```
 
-### One-Liner Release
+### 一行命令发布
 
 ```bash
 npm run preview:release && npm run release:minor && npm run release:watch
 ```
 
-## 📝 What Happens Automatically
+## 📝 自动发生的事情
 
-When you trigger a release, the GitHub Actions workflow automatically:
+当您触发发布时，GitHub Actions工作流会自动：
 
-1. ✅ **Validates** - Runs tests, linting, and formatting checks
+1.  ✅ **验证** - 运行测试、linting和格式检查
-2. ✅ **Bumps Version** - Updates `package.json` and installer version
+2.  ✅ **提升版本** - 更新`package.json`和安装程序版本
-3. ✅ **Generates Release Notes** - Categorizes commits since last release:
+3.  ✅ **生成发布说明** - 将自上次发布以来的提交分类：
-   - ✨ **New Features** (`feat:`, `Feature:`)
+    -   ✨ **新功能** (`feat:`, `Feature:`)
-   - 🐛 **Bug Fixes** (`fix:`, `Fix:`)
+    -   🐛 **错误修复** (`fix:`, `Fix:`)
-   - 🔧 **Maintenance** (`chore:`, `Chore:`)
+    -   🔧 **维护** (`chore:`, `Chore:`)
-   - 📦 **Other Changes** (everything else)
+    -   📦 **其他更改** (其他所有内容)
-4. ✅ **Creates Git Tag** - Tags the release version
+4.  ✅ **创建Git标签** - 标记发布版本
-5. ✅ **Publishes to NPM** - With `@latest` tag for user installations
+5.  ✅ **发布到NPM** - 带有`@latest`标签供用户安装
-6. ✅ **Creates GitHub Release** - With formatted release notes
+6.  ✅ **创建GitHub发布** - 带有格式化的发布说明
 
-## 📋 Sample Release Notes
+## 📋 示例发布说明
 
-The workflow automatically generates professional release notes like this:
+工作流会自动生成如下专业的发布说明：
 
 ````markdown
-## 🚀 What's New in v5.2.0
+## 🚀 v5.2.0的新功能
 
-### ✨ New Features
+### ✨ 新功能
 
-- feat: add team collaboration mode
+- feat: 添加团队协作模式
-- feat: enhance CLI with interactive prompts
+- feat: 通过交互式提示增强CLI
 
-### 🐛 Bug Fixes
+### 🐛 错误修复
 
-- fix: resolve installation path issues
+- fix: 解决安装路径问题
-- fix: handle edge cases in agent loading
+- fix: 处理代理加载中的边缘情况
 
-### 🔧 Maintenance
+### 🔧 维护
 
-- chore: update dependencies
+- chore: 更新依赖项
-- chore: improve error messages
+- chore: 改进错误消息
 
-## 📦 Installation
+## 📦 安装
 
 ```bash
 npx bmad-method install
 ```
 ````
 
-**Full Changelog**: https://github.com/bmadcode/BMAD-METHOD/compare/v5.1.0...v5.2.0
+**完整变更日志**: https://github.com/bmadcode/BMAD-METHOD/compare/v5.1.0...v5.2.0
 
 ````
 
-## 🎯 User Installation
+## 🎯 用户安装
 
-After any release, users can immediately get the new version with:
+任何发布后，用户可以立即通过以下方式获取新版本：
 
 ```bash
-npx bmad-method install    # Always gets latest release
+npx bmad-method install    # 总是获取最新版本
 ```
 
-## 📊 Preview Before Release
+## 📊 发布前预览
 
-Always preview what will be included in your release:
+始终预览您的发布中将包含的内容：
 
 ```bash
 npm run preview:release
 ```
 
-This shows:
+这将显示：
 
-- Commits since last release
+-   自上次发布以来的提交
-- Categorized changes
+-   分类的更改
-- Estimated next version
+-   估计的下一个版本
-- Release notes preview
+-   发布说明预览
 
-## 🔧 Manual Release (GitHub UI)
+## 🔧 手动发布（GitHub UI）
 
-You can also trigger releases through GitHub Actions:
+您也可以通过GitHub Actions触发发布：
 
-1. Go to **GitHub Actions** → **Manual Release**
+1.  转到**GitHub Actions** → **Manual Release**
-2. Click **"Run workflow"**
+2.  点击**"Run workflow"**
-3. Choose version bump type (patch/minor/major)
+3.  选择版本提升类型（patch/minor/major）
-4. Everything else happens automatically
+4.  其他所有事情都会自动发生
 
-## 📈 Version Strategy
+## 📈 版本策略
 
-- **Patch** (5.1.0 → 5.1.1): Bug fixes, minor improvements
+-   **Patch** (5.1.0 → 5.1.1): 错误修复、次要改进
-- **Minor** (5.1.0 → 5.2.0): New features, enhancements
+-   **Minor** (5.1.0 → 5.2.0): 新功能、增强
-- **Major** (5.1.0 → 6.0.0): Breaking changes, major redesigns
+-   **Major** (5.1.0 → 6.0.0): 重大更改、重大重新设计
 
-## 🛠️ Development Workflow
+## 🛠️ 开发工作流
 
-1. **Develop Freely** - Merge PRs to main without triggering releases
+1.  **自由开发** - 将PR合并到main而不会触发发布
-2. **Test Unreleased Changes** - Clone repo to test latest main branch
+2.  **测试未发布的更改** - 克隆存储库以测试最新的main分支
-3. **Release When Ready** - Use command line or GitHub Actions to cut releases
+3.  **准备好后发布** - 使用命令行或GitHub Actions来发布
-4. **Users Get Updates** - Via simple `npx bmad-method install` command
+4.  **用户获取更新** - 通过简单的`npx bmad-method install`命令
 
-This gives you complete control over when releases happen while automating all the tedious parts like version bumping, release notes, and publishing.
+这使您可以完全控制何时发布，同时自动化所有繁琐的部分，如版本提升、发布说明和发布。
 
-## 🔍 Troubleshooting
+## 🔍 故障排除
 
-### Check Release Status
+### 检查发布状态
 
 ```bash
 gh run list --workflow="Manual Release"
@@ -132,24 +132,24 @@ npm view bmad-method dist-tags
 git tag -l | sort -V | tail -5
 ```
 
-### View Latest Release
+### 查看最新发布
 
 ```bash
 gh release view --web
 npm view bmad-method versions --json
 ```
 
-### If Version Sync Needed
+### 如果需要版本同步
 
-If your local files don't match the published version after a release:
+如果发布后您的本地文件与已发布版本不匹配：
 
 ```bash
-./tools/sync-version.sh    # Automatically syncs local files with npm latest
+./tools/sync-version.sh    # 自动将本地文件与npm最新版本同步
 ```
 
-### If Release Fails
+### 如果发布失败
 
-- Check GitHub Actions logs: `gh run view <run-id> --log-failed`
+-   检查GitHub Actions日志：`gh run view <run-id> --log-failed`
-- Verify NPM tokens are configured
+-   验证NPM令牌是否已配置
-- Ensure branch protection allows workflow pushes
+-   确保分支保护允许工作流推送
 ````

docs/versions.md

@@ -1,48 +1,48 @@
-# Version History
+# 版本历史
 
-## Previous Versions
+## 以前的版本
 
-- [Version 3](https://github.com/bmadcode/BMad-Method/tree/V3)
+- [版本3](https://github.com/bmadcode/BMad-Method/tree/V3)
-- [Version 2](https://github.com/bmadcode/BMad-Method/tree/V2)
+- [版本2](https://github.com/bmadcode/BMad-Method/tree/V2)
-- [Version 1](https://github.com/bmadcode/BMad-Method/tree/V1)
+- [版本1](https://github.com/bmadcode/BMad-Method/tree/V1)
 
-## Current Version: V4 - Alpha
+## 当前版本：V4 - Alpha
 
-Guiding Principles of V4:
+V4的指导原则：
 
-- Simple to understand, install and start using
+-   简单易懂，易于安装和开始使用
-- Support Greenfield and Brownfield Scenarios
+-   支持绿地和棕地场景
-- Greater configurability and more scenarios for usage - but kept out of the main package to maintain simplicity
+-   更大的可配置性和更多的使用场景 - 但为了保持简单性而将其保留在主包之外
-- Helpers for installers and web builders that will work with any OS and IDE easily
+-   为安装程序和Web构建器提供帮助程序，可轻松与任何操作系统和IDE配合使用
-- Align all agents to be the same for IDE and Web, without losing the power of the web versions, or the leanness of the files in the IDE to reduce context
+-   使所有代理在IDE和Web上保持一致，而不会失去Web版本的功能，也不会减少IDE中文件的精简以减少上下文
-- Further improvements to the two most important agents - the SM and DEV
+-   进一步改进两个最重要的代理 - SM和DEV
 
 ## V3
 
-With the customizability of V2, there were still some issues. A PM could only easily do one thing, create a PRD. And maintaining the consistency between Web and IDE agents was a pain.
+尽管V2具有可定制性，但仍存在一些问题。PM只能轻松地做一件事，即创建PRD。而且，在Web和IDE代理之间保持一致性是一件痛苦的事情。
 
-V3 didn't fix the disconnect, but it did make it easier to maintain them all in a single folder, but there were only two official ide agents - all the rest were really made and optimized for the web.
+V3没有解决脱节问题，但它确实使在单个文件夹中维护所有内容变得更容易，但只有两个官方的ide代理 - 所有其余的都是为Web真正制作和优化的。
 
-V3's biggest impact was a full explosion of customizability. Tasks, Personas, Agent Configurations, Doc Templates, data payloads.
+V3最大的影响是可定制性的全面爆发。任务、角色、代理配置、文档模板、数据有效载荷。
 
-BUT - the BIGGEST change was the realization that we were barely scratching the surface of what could be loaded into Gemini Gems and still have very long chats. The BMad AGENT arose, and with a single V3 release - the future of the BMad Method was changed forever.
+但是 - 最大的变化是意识到我们仅仅触及了可以加载到Gemini Gems中并仍然进行非常长时间聊天的表面。BMad代理应运而生，随着一个V3版本的发布 - BMad方法的未来被永远改变了。
 
-Now, instead of configuring 4+ web agents, all needing many files uploaded to create them, a single Agent called BMad, with a whole team, and the ability to switch and maintain personas evolved. Now you could in the same chat thread, talk to the whole team, or anyone on the team. No more exporting and reimporting docs to different chats - all of the sudden, you could finish the PRD, and ask Josh to pass it off to the Architect, and that was it, the architect just had it and we moved on! And all of that with just 7 total files to upload, delivering all power.
+现在，不再需要配置4个以上的Web代理，所有这些代理都需要上传许多文件来创建它们，一个名为BMad的单一代理，拥有整个团队，并且能够切换和维护角色。现在，您可以在同一个聊天线程中与整个团队或团队中的任何人交谈。不再需要在不同聊天之间导出和重新导入文档 - 突然之间，您可以完成PRD，并要求Josh将其交给架构师，就这样，架构师就拥有了它，我们继续前进！而所有这一切只需上传7个文件，即可提供所有功能。
 
-But V3 had a major flaw - with massive configuration comes massive complexity - and in some ways, V3 started to get away from core principles - power through simplicity. The core system needs to do one thing well and be solid, and not stretch too thing with every possible thing.
+但是V3有一个主要缺陷 - 巨大的配置带来了巨大的复杂性 - 在某些方面，V3开始偏离核心原则 - 通过简单实现强大。核心系统需要做好一件事并保持稳固，而不是用所有可能的东西来过度扩展。
 
-Also - while the dev is amazing and better in V3 than all the past, along with the SM - the dev started over documenting every step and really started to bloat stories with their own notes. And the SM was forgetting to add details to stories, or embellishing information. This was fixed somewhat in V3.1 - but the dev is still over explaining everything it does, instead of just capturing the changes to the story.
+此外 - 虽然dev在V3中非常出色并且比过去所有版本都好，但与SM一起 - dev开始过度记录每一步，并真正开始用自己的笔记来膨胀故事。而SM则忘记向故事中添加细节，或修饰信息。这在V3.1中有所修复 - 但dev仍然过度解释它所做的一切，而不是仅仅捕获对故事的更改。
 
 ## V2
 
-After V1 proved that the BMad method was solid and repeatable, 2 key ideas emerged. Separation of concerns, and building for the web made easier. By separating out templates - it was now much easier for the PRD fields to be customized, or the architecture.
+在V1证明BMad方法是可靠且可重复的之后，出现了两个关键思想。关注点分离，以及使Web构建更容易。通过分离出模板 - 现在可以更容易地自定义PRD字段或架构。
 
-And the introduction that really supercharged everything in my opinion, the web versions! There were 4 hard coded web variants hand crafted - and we saw that we could, dirt cheap, work with agents for hours in the massive context of Gemini - from a PRD generating PM, through to an architect and even an analyst that could help us do extensive market research and brain storming.
+在我看来，真正为一切注入活力的引子是Web版本！有4个硬编码的Web变体是手工制作的 - 我们看到，我们可以以极低的成本，在Gemini的巨大上下文中与代理工作数小时 - 从生成PRD的PM，到架构师，甚至是可以帮助我们进行广泛市场研究和头脑风暴的分析师。
 
-What I never expected is the names would stick, and people would keep the sample names I made that I thought people would configure. But now 4 version is, people refer to Mary, and John, and Bob! And when I randomly changed the names, I got A LOT of feedback! These have become trusted allies people are relying on, including for me!
+我从未预料到的是，这些名字会保留下来，人们会继续使用我制作的我以为人们会配置的示例名称。但是现在4个版本过去了，人们仍然提到Mary、John和Bob！当我随机更改名字时，我收到了很多反馈！这些已经成为人们（包括我）依赖的值得信赖的盟友！
 
 ## V1
 
-Believe it or not (well you can view the link), V1 was a simple 7 file system! 7 Core agents working in harmony to help build a pretty specific type of application. But it showed its power and adaptability.
+信不信由你（好吧，你可以查看链接），V1是一个简单的7文件系统！7个核心代理和谐地工作，帮助构建一种非常特定类型的应用程序。但它展示了它的力量和适应性。
 
-Meant to be a simple Tech Demo showing how custom agents with agile personas can help streamline your project, and create rails for your dev agents that to that point had gone unmatched - while also putting a focus on the planning phases - the project sparked the imagination of many, and a seed of a potential was realized.
+旨在作为一个简单的技术演示，展示具有敏捷角色的自定义代理如何帮助简化您的项目，并为您的开发代理创建迄今为止无与伦比的轨道 - 同时还关注规划阶段 - 该项目激发了许多人的想象力，一个潜力的种子得以实现。

docs/working-in-the-brownfield.md

@@ -1,216 +1,216 @@
-# Working in the Brownfield: A Complete Guide
+# 在棕地中工作：完整指南
 
-> **HIGHLY RECOMMENDED: Use Gemini Web or Gemini CLI for Brownfield Documentation Generation!**
+> **强烈推荐：使用Gemini Web或Gemini CLI进行棕地文档生成！**
 >
-> Gemini Web's 1M+ token context window or Gemini CLI (when it's working) can analyze your ENTIRE codebase, or critical sections of it, all at once (obviously within reason):
+> Gemini Web的1M+令牌上下文窗口或Gemini CLI（当它工作时）可以一次性分析您的整个代码库或其关键部分（当然是在合理范围内）：
 >
-> - Upload via GitHub URL or use gemini cli in the project folder
+> -   通过GitHub URL上传或在项目文件夹中使用gemini cli
-> - If working in the web: use `npx bmad-method flatten` to flatten your project into a single file, then upload that file to your web agent.
+> -   如果在Web中工作：使用`npx bmad-method flatten`将您的项目展平为单个文件，然后将该文件上传到您的Web代理。
 
-## What is Brownfield Development?
+## 什么是棕地开发？
 
-Brownfield development refers to adding features, fixing bugs, or modernizing existing software projects. Unlike greenfield (new) projects, brownfield work requires understanding existing code, respecting constraints, and ensuring new changes integrate seamlessly without breaking existing functionality.
+棕地开发是指为现有软件项目添加功能、修复错误或进行现代化改造。与绿地（新）项目不同，棕地工作需要理解现有代码、尊重约束，并确保新更改无缝集成而不会破坏现有功能。
 
-## When to Use BMad for Brownfield
+## 何时为棕地使用BMad
 
-- Add significant new features to existing applications
+-   向现有应用程序添加重要的新功能
-- Modernize legacy codebases
+-   现代化遗留代码库
-- Integrate new technologies or services
+-   集成新技术或服务
-- Refactor complex systems
+-   重构复杂系统
-- Fix bugs that require architectural understanding
+-   修复需要架构理解的错误
-- Document undocumented systems
+-   记录未记录的系统
 
-## When NOT to use a Brownfield Flow
+## 何时不使用棕地流程
 
-If you have just completed an MVP with BMad, and you want to continue with post-MVP, its easier to just talk to the PM and ask it to work with you to create a new epic to add into the PRD, shard out the epic, update any architecture documents with the architect, and just go from there.
+如果您刚刚用BMad完成了MVP，并且想继续进行MVP后的工作，那么与PM交谈并要求他与您合作创建一个新的史诗以添加到PRD中，分片史诗，与架构师一起更新任何架构文档，然后从那里开始会更容易。
 
-## The Complete Brownfield Workflow
+## 完整的棕地工作流
 
-1. **Follow the [<ins>User Guide - Installation</ins>](user-guide.md#installation) steps to setup your agent in the web.**
+1.  **遵循[<ins>用户指南-安装</ins>](user-guide.md#installation)步骤在Web中设置您的代理。**
-2. **Generate a 'flattened' single file of your entire codebase** run: `npx bmad-method flatten`
+2.  **生成整个代码库的“扁平化”单个文件** 运行：`npx bmad-method flatten`
 
-### Choose Your Approach
+### 选择您的方法
 
-#### Approach A: PRD-First (Recommended if adding very large and complex new features, single or multiple epics or massive changes)
+#### 方法A：PRD优先（推荐用于添加非常大和复杂的新功能、单个或多个史诗或大规模更改）
 
-**Best for**: Large codebases, monorepos, or when you know exactly what you want to build
+**最适合**：大型代码库、monorepos，或者当您确切知道要构建什么时
 
-1. **Create PRD First** to define requirements
+1.  **首先创建PRD**来定义需求
-2. **Document only relevant areas** based on PRD needs
+2.  **仅根据PRD需求记录相关区域**
-3. **More efficient** - avoids documenting unused code
+3.  **更高效** - 避免记录未使用的代码
 
-#### Approach B: Document-First (Good for Smaller Projects)
+#### 方法B：文档优先（适用于较小项目）
 
-**Best for**: Smaller codebases, unknown systems, or exploratory changes
+**最适合**：较小的代码库、未知的系统或探索性更改
 
-1. **Document entire system** first
+1.  **首先记录整个系统**
-2. **Create PRD** with full context
+2.  **用完整的上下文创建PRD**
-3. **More thorough** - captures everything
+3.  **更彻底** - 捕获所有内容
 
-### Approach A: PRD-First Workflow (Recommended)
+### 方法A：PRD优先工作流（推荐）
 
-#### Phase 1: Define Requirements First
+#### 阶段1：首先定义需求
 
-**In Gemini Web (with your flattened-codebase.xml uploaded):**
+**在Gemini Web中（上传了您的flattened-codebase.xml）：**
 
 ```bash
 @pm
 *create-brownfield-prd
 ```
 
-The PM will:
+PM将：
 
-- **Ask about your enhancement** requirements
+-   **询问您的增强**需求
-- **Explore the codebase** to understand current state
+-   **探索代码库**以了解当前状态
-- **Identify affected areas** that need documentation
+-   **识别需要文档的受影响区域**
-- **Create focused PRD** with clear scope
+-   **创建具有明确范围的专注PRD**
 
-**Key Advantage**: The PRD identifies which parts of your monorepo/large codebase actually need documentation!
+**主要优势**：PRD确定了您的monorepo/大型代码库的哪些部分实际上需要文档！
 
-#### Phase 2: Focused Documentation
+#### 阶段2：专注文档
 
-**Still in Gemini Web, now with PRD context:**
+**仍在Gemini Web中，现在有了PRD上下文：**
 
 ```bash
 @architect
 *document-project
 ```
 
-The architect will:
+架构师将：
 
-- **Ask about your focus** if no PRD was provided
+-   **如果未提供PRD，则询问您的重点**
-- **Offer options**: Create PRD, provide requirements, or describe the enhancement
+-   **提供选项**：创建PRD、提供需求或描述增强功能
-- **Reference the PRD/description** to understand scope
+-   **引用PRD/描述**以了解范围
-- **Focus on relevant modules** identified in PRD or your description
+-   **专注于PRD或您的描述中识别的相关模块**
-- **Skip unrelated areas** to keep docs lean
+-   **跳过不相关的区域**以保持文档精简
-- **Generate ONE architecture document** for all environments
+-   **为所有环境生成一个架构文档**
 
-The architect creates:
+架构师创建：
 
-- **One comprehensive architecture document** following fullstack-architecture template
+-   **一个遵循fullstack-architecture模板的综合架构文档**
-- **Covers all system aspects** in a single file
+-   **在一个文件中涵盖所有系统方面**
-- **Easy to copy and save** as `docs/architecture.md`
+-   **易于复制并另存为**`docs/architecture.md`
-- **Can be sharded later** in IDE if desired
+-   **如果需要，以后可以在IDE中分片**
 
-For example, if you say "Add payment processing to user service":
+例如，如果您说“向用户服务添加支付处理”：
 
-- Documents only: user service, API endpoints, database schemas, payment integrations
+-   仅记录：用户服务、API端点、数据库模式、支付集成
-- Creates focused source tree showing only payment-related code paths
+-   创建仅显示与支付相关的代码路径的专注源树
-- Skips: admin panels, reporting modules, unrelated microservices
+-   跳过：管理面板、报告模块、不相关的微服务
 
-### Approach B: Document-First Workflow
+### 方法B：文档优先工作流
 
-#### Phase 1: Document the Existing System
+#### 阶段1：记录现有系统
 
-**Best Approach - Gemini Web with 1M+ Context**:
+**最佳方法 - 具有1M+上下文的Gemini Web**：
 
-1. **Go to Gemini Web** (gemini.google.com)
+1.  **转到Gemini Web** (gemini.google.com)
-2. **Upload your project**:
+2.  **上传您的项目**：
-   - **Option A**: Paste your GitHub repository URL directly
+    -   **选项A**：直接粘贴您的GitHub存储库URL
-   - **Option B**: Upload your flattened-codebase.xml file
+    -   **选项B**：上传您的flattened-codebase.xml文件
-3. **Load the architect agent**: Upload `dist/agents/architect.txt`
+3.  **加载架构师代理**：上传`dist/agents/architect.txt`
-4. **Run documentation**: Type `*document-project`
+4.  **运行文档**：输入`*document-project`
 
-The architect will generate comprehensive documentation of everything.
+架构师将生成所有内容的综合文档。
 
-#### Phase 2: Plan Your Enhancement
+#### 阶段2：规划您的增强功能
 
-##### Option A: Full Brownfield Workflow (Recommended for Major Changes)
+##### 选项A：完整的棕地工作流（推荐用于重大更改）
 
-**1. Create Brownfield PRD**:
+**1. 创建棕地PRD**：
 
 ```bash
 @pm
 *create-brownfield-prd
 ```
 
-The PM agent will:
+PM代理将：
 
-- **Analyze existing documentation** from Phase 1
+-   **分析来自阶段1的现有文档**
-- **Request specific enhancement details** from you
+-   **向您请求具体的增强细节**
-- **Assess complexity** and recommend approach
+-   **评估复杂性**并推荐方法
-- **Create epic/story structure** for the enhancement
+-   **为增强功能创建史诗/故事结构**
-- **Identify risks and integration points**
+-   **识别风险和集成点**
 
-**How PM Agent Gets Project Context**:
+**PM代理如何获取项目上下文**：
 
-- In Gemini Web: Already has full project context from Phase 1 documentation
+-   在Gemini Web中：已经从阶段1的文档中获得了完整的项目上下文
-- In IDE: Will ask "Please provide the path to your existing project documentation"
+-   在IDE中：会问“请提供您现有项目文档的路径”
 
-**Key Prompts You'll Encounter**:
+**您会遇到的关键提示**：
 
-- "What specific enhancement or feature do you want to add?"
+-   “您想添加什么具体的增强或功能？”
-- "Are there any existing systems or APIs this needs to integrate with?"
+-   “这是否需要与任何现有系统或API集成？”
-- "What are the critical constraints we must respect?"
+-   “我们必须遵守哪些关键约束？”
-- "What is your timeline and team size?"
+-   “您的时间表和团队规模是多少？”
 
-**2. Create Brownfield Architecture**:
+**2. 创建棕地架构**：
 
 ```bash
 @architect
 *create-brownfield-architecture
 ```
 
-The architect will:
+架构师将：
 
-- **Review the brownfield PRD**
+-   **审查棕地PRD**
-- **Design integration strategy**
+-   **设计集成策略**
-- **Plan migration approach** if needed
+-   **如果需要，规划迁移方法**
-- **Identify technical risks**
+-   **识别技术风险**
-- **Define compatibility requirements**
+-   **定义兼容性要求**
 
-##### Option B: Quick Enhancement (For Focused Changes)
+##### 选项B：快速增强（用于专注的更改）
 
-**For Single Epic Without Full PRD**:
+**对于没有完整PRD的单个史诗**：
 
 ```bash
 @pm
 *create-brownfield-epic
 ```
 
-Use when:
+在以下情况下使用：
 
-- Enhancement is well-defined and isolated
+-   增强功能定义明确且孤立
-- Existing documentation is comprehensive
+-   现有文档全面
-- Changes don't impact multiple systems
+-   更改不影响多个系统
-- You need quick turnaround
+-   您需要快速周转
 
-**For Single Story**:
+**对于单个故事**：
 
 ```bash
 @pm
 *create-brownfield-story
 ```
 
-Use when:
+在以下情况下使用：
 
-- Bug fix or tiny feature
+-   错误修复或微小功能
-- Very isolated change
+-   非常孤立的更改
-- No architectural impact
+-   没有架构影响
-- Clear implementation path
+-   清晰的实施路径
 
-### Phase 3: Validate Planning Artifacts
+### 阶段3：验证规划工件
 
 ```bash
 @po
 *execute-checklist-po
 ```
 
-The PO ensures:
+PO确保：
 
-- Compatibility with existing system
+-   与现有系统兼容
-- No breaking changes planned
+-   没有计划中的重大更改
-- Risk mitigation strategies in place
+-   风险缓解策略到位
-- Clear integration approach
+-   清晰的集成方法
 
-### Phase 4: Save and Shard Documents
+### 阶段4：保存和分片文档
 
-1. Save your PRD and Architecture as:
+1.  将您的PRD和架构另存为：
     docs/prd.md
     docs/architecture.md
-   (Note: You can optionally prefix with 'brownfield-' if managing multiple versions)
+    （注意：如果管理多个版本，您可以选择性地以“brownfield-”为前缀）
-2. Shard your docs:
+2.  分片您的文档：
-   In your IDE
+    在您的IDE中
 
     ```bash
     @po
@@ -222,376 +222,376 @@ The PO ensures:
     shard docs/architecture.md
     ```
 
-### Phase 5: Transition to Development
+### 阶段5：过渡到开发
 
-**Follow the [<ins>Enhanced IDE Development Workflow</ins>](enhanced-ide-development-workflow.md)**
+**遵循[<ins>增强的IDE开发工作流</ins>](enhanced-ide-development-workflow.md)**
 
-## Brownfield Best Practices
+## 棕地最佳实践
 
-### 1. Always Document First
+### 1. 始终先记录
 
-Even if you think you know the codebase:
+即使您认为自己了解代码库：
 
-- Run `document-project` to capture current state
+-   运行`document-project`以捕获当前状态
-- AI agents need this context
+-   AI代理需要这个上下文
-- Discovers undocumented patterns
+-   发现未记录的模式
 
-### 2. Respect Existing Patterns
+### 2. 尊重现有模式
 
-The brownfield templates specifically look for:
+棕地模板专门寻找：
 
-- Current coding conventions
+-   当前的编码约定
-- Existing architectural patterns
+-   现有的架构模式
-- Technology constraints
+-   技术约束
-- Team preferences
+-   团队偏好
 
-### 3. Plan for Gradual Rollout
+### 3. 规划逐步推出
 
-Brownfield changes should:
+棕地更改应：
 
-- Support feature flags
+-   支持功能标志
-- Plan rollback strategies
+-   规划回滚策略
-- Include migration scripts
+-   包括迁移脚本
-- Maintain backwards compatibility
+-   保持向后兼容性
 
-### 4. Test Integration Thoroughly
+### 4. 彻底测试集成
 
-#### Why the Test Architect is Critical for Brownfield
+#### 为什么测试架构师对棕地至关重要
 
-In brownfield projects, the Test Architect (Quinn) becomes your safety net against breaking existing functionality. Unlike greenfield where you're building fresh, brownfield requires careful validation that new changes don't destabilize what already works.
+在棕地项目中，测试架构师（Quinn）成为您防止破坏现有功能的安全网。与您从头开始构建的绿地不同，棕地需要仔细验证新更改不会破坏已经正常工作的内容。
 
-#### Brownfield-Specific Testing Challenges
+#### 棕地特定的测试挑战
 
-The Test Architect addresses unique brownfield complexities:
+测试架构师解决了独特的棕地复杂性：
 
-| **Challenge**               | **How Test Architect Helps**                      | **Command**         |
+| **挑战** | **测试架构师如何帮助** | **命令** |
-| --------------------------- | ------------------------------------------------- | ------------------- |
+| --- | --- | --- |
-| **Regression Risks**        | Identifies which existing features might break    | `*risk`             |
+| **回归风险** | 识别哪些现有功能可能会中断 | `*risk` |
-| **Legacy Dependencies**     | Maps integration points and hidden dependencies   | `*trace`            |
+| **遗留依赖** | 映射集成点和隐藏的依赖关系 | `*trace` |
-| **Performance Degradation** | Validates no slowdown in existing flows           | `*nfr`              |
+| **性能下降** | 验证现有流程没有减速 | `*nfr` |
-| **Coverage Gaps**           | Finds untested legacy code that new changes touch | `*design`           |
+| **覆盖差距** | 查找新更改触及的未经测试的遗留代码 | `*design` |
-| **Breaking Changes**        | Detects API/contract violations                   | `*review`           |
+| **重大更改** | 检测API/合同违规 | `*review` |
-| **Migration Safety**        | Validates data transformations and rollback plans | `*risk` + `*review` |
+| **迁移安全** | 验证数据转换和回滚计划 | `*risk` + `*review` |
 
-#### Complete Test Architect Workflow for Brownfield
+#### 棕地的完整测试架构师工作流
 
-##### Stage 1: Before Development (Risk & Strategy)
+##### 阶段1：开发前（风险与策略）
 
-**CRITICAL FOR BROWNFIELD - Run These First:**
+**对棕地至关重要 - 首先运行这些：**
 
 ```bash
-# 1. RISK ASSESSMENT (Run IMMEDIATELY after story creation)
+# 1. 风险评估（故事创建后立即运行）
 @qa *risk {brownfield-story}
-# Identifies: Legacy dependencies, breaking changes, integration points
+# 识别：遗留依赖、重大更改、集成点
-# Output: docs/qa/assessments/{epic}.{story}-risk-{YYYYMMDD}.md
+# 输出：docs/qa/assessments/{epic}.{story}-risk-{YYYYMMDD}.md
-# Brownfield Focus:
+# 棕地重点：
-#   - Regression probability scoring
+#   - 回归概率评分
-#   - Affected downstream systems
+#   - 受影响的下游系统
-#   - Data migration risks
+#   - 数据迁移风险
-#   - Rollback complexity
+#   - 回滚复杂性
 
-# 2. TEST DESIGN (After risk assessment)
+# 2. 测试设计（风险评估后）
 @qa *design {brownfield-story}
-# Creates: Regression test strategy + new feature tests
+# 创建：回归测试策略+新功能测试
-# Output: docs/qa/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md
+# 输出：docs/qa/assessments/{epic}.{story}-test-design-{YYYYMMDD}.md
-# Brownfield Focus:
+# 棕地重点：
-#   - Existing functionality that needs regression tests
+#   - 需要回归测试的现有功能
-#   - Integration test requirements
+#   - 集成测试要求
-#   - Performance benchmarks to maintain
+#   - 要维持的性能基准
-#   - Feature flag test scenarios
+#   - 功能标志测试场景
 ```
 
-##### Stage 2: During Development (Continuous Validation)
+##### 阶段2：开发期间（持续验证）
 
-**Monitor Integration Health While Coding:**
+**在编码时监控集成健康状况：**
 
 ```bash
-# 3. REQUIREMENTS TRACING (Mid-development checkpoint)
+# 3. 需求跟踪（开发中期检查点）
 @qa *trace {brownfield-story}
-# Maps: New requirements + existing functionality preservation
+# 映射：新需求+现有功能保留
-# Output: docs/qa/assessments/{epic}.{story}-trace-{YYYYMMDD}.md
+# 输出：docs/qa/assessments/{epic}.{story}-trace-{YYYYMMDD}.md
-# Brownfield Focus:
+# 棕地重点：
-#   - Existing features that must still work
+#   - 必须仍然工作的现有功能
-#   - New/old feature interactions
+#   - 新/旧功能交互
-#   - API contract preservation
+#   - API合同保留
-#   - Missing regression test coverage
+#   - 缺失的回归测试覆盖
 
-# 4. NFR VALIDATION (Before considering "done")
+# 4. NFR验证（考虑“完成”之前）
 @qa *nfr {brownfield-story}
-# Validates: Performance, security, reliability unchanged
+# 验证：性能、安全性、可靠性不变
-# Output: docs/qa/assessments/{epic}.{story}-nfr-{YYYYMMDD}.md
+# 输出：docs/qa/assessments/{epic}.{story}-nfr-{YYYYMMDD}.md
-# Brownfield Focus:
+# 棕地重点：
-#   - Performance regression detection
+#   - 性能回归检测
-#   - Security implications of integrations
+#   - 集成的安全影响
-#   - Backward compatibility validation
+#   - 向后兼容性验证
-#   - Load/stress on legacy components
+#   - 对遗留组件的负载/压力
 ```
 
-##### Stage 3: Code Review (Deep Integration Analysis)
+##### 阶段3：代码审查（深度集成分析）
 
-**Comprehensive Brownfield Review:**
+**全面的棕地审查：**
 
 ```bash
-# 5. FULL REVIEW (When development complete)
+# 5. 全面审查（开发完成时）
 @qa *review {brownfield-story}
-# Performs: Deep analysis + active refactoring
+# 执行：深度分析+主动重构
-# Outputs:
+# 输出：
-#   - QA Results in story file
+#   - 故事文件中的QA结果
-#   - Gate file: docs/qa/gates/{epic}.{story}-{slug}.yml
+#   - 门禁文件：docs/qa/gates/{epic}.{story}-{slug}.yml
 ```
 
-The review specifically analyzes:
+审查特别分析：
 
-- **API Breaking Changes**: Validates all existing contracts maintained
+-   **API重大更改**：验证所有现有合同是否得到维护
-- **Data Migration Safety**: Checks transformation logic and rollback procedures
+-   **数据迁移安全**：检查转换逻辑和回滚程序
-- **Performance Regression**: Compares against baseline metrics
+-   **性能回归**：与基准指标进行比较
-- **Integration Points**: Validates all touchpoints with legacy code
+-   **集成点**：验证与遗留代码的所有接触点
-- **Feature Flag Logic**: Ensures proper toggle behavior
+-   **功能标志逻辑**：确保正确的切换行为
-- **Dependency Impacts**: Maps affected downstream systems
+-   **依赖影响**：映射受影响的下游系统
 
-##### Stage 4: Post-Review (Gate Updates)
+##### 阶段4：审查后（门禁更新）
 
 ```bash
-# 6. GATE STATUS UPDATE (After addressing issues)
+# 6. 门禁状态更新（解决问题后）
 @qa *gate {brownfield-story}
-# Updates: Quality gate decision after fixes
+# 更新：修复后的质量门禁决策
-# Output: docs/qa/gates/{epic}.{story}-{slug}.yml
+# 输出：docs/qa/gates/{epic}.{story}-{slug}.yml
-# Brownfield Considerations:
+# 棕地考虑：
-#   - May WAIVE certain legacy code issues
+#   - 可能会豁免某些遗留代码问题
-#   - Documents technical debt acceptance
+#   - 记录技术债务接受情况
-#   - Tracks migration progress
+#   - 跟踪迁移进度
 ```
 
-#### Brownfield-Specific Risk Scoring
+#### 棕地特定的风险评分
 
-The Test Architect uses enhanced risk scoring for brownfield:
+测试架构师对棕地使用增强的风险评分：
 
-| **Risk Category**      | **Brownfield Factors**                     | **Impact on Gate**  |
+| **风险类别** | **棕地因素** | **对门禁的影响** |
-| ---------------------- | ------------------------------------------ | ------------------- |
+| --- | --- | --- |
-| **Regression Risk**    | Number of integration points × Age of code | Score ≥9 = FAIL     |
+| **回归风险** | 集成点数量×代码年龄 | 评分≥9 = FAIL |
-| **Data Risk**          | Migration complexity × Data volume         | Score ≥6 = CONCERNS |
+| **数据风险** | 迁移复杂性×数据量 | 评分≥6 = CONCERNS |
-| **Performance Risk**   | Current load × Added complexity            | Score ≥6 = CONCERNS |
+| **性能风险** | 当前负载×增加的复杂性 | 评分≥6 = CONCERNS |
-| **Compatibility Risk** | API consumers × Contract changes           | Score ≥9 = FAIL     |
+| **兼容性风险** | API消费者×合同更改 | 评分≥9 = FAIL |
 
-#### Brownfield Testing Standards
+#### 棕地测试标准
 
-Quinn enforces additional standards for brownfield:
+Quinn对棕地强制执行额外的标准：
 
-- **Regression Test Coverage**: Every touched legacy module needs tests
+-   **回归测试覆盖率**：每个接触到的遗留模块都需要测试
-- **Performance Baselines**: Must maintain or improve current metrics
+-   **性能基准**：必须维持或改进当前的指标
-- **Rollback Procedures**: Every change needs a rollback plan
+-   **回滚程序**：每个更改都需要一个回滚计划
-- **Feature Flags**: All risky changes behind toggles
+-   **功能标志**：所有有风险的更改都在切换开关后面
-- **Integration Tests**: Cover all legacy touchpoints
+-   **集成测试**：覆盖所有遗留接触点
-- **Contract Tests**: Validate API compatibility
+-   **合同测试**：验证API兼容性
-- **Data Validation**: Migration correctness checks
+-   **数据验证**：迁移正确性检查
 
-#### Quick Reference: Brownfield Test Commands
+#### 快速参考：棕地测试命令
 
-| **Scenario**                      | **Commands to Run**                                  | **Order**  | **Why Critical**              |
+| **场景** | **要运行的命令** | **顺序** | **为何关键** |
-| --------------------------------- | ---------------------------------------------------- | ---------- | ----------------------------- |
+| --- | --- | --- | --- |
-| **Adding Feature to Legacy Code** | `*risk` → `*design` → `*trace` → `*review`           | Sequential | Map all dependencies first    |
+| **向遗留代码添加功能** | `*risk` → `*design` → `*trace` → `*review` | 顺序 | 首先映射所有依赖 |
-| **API Modification**              | `*risk` → `*design` → `*nfr` → `*review`             | Sequential | Prevent breaking consumers    |
+| **API修改** | `*risk` → `*design` → `*nfr` → `*review` | 顺序 | 防止破坏消费者 |
-| **Performance-Critical Change**   | `*nfr` early and often → `*review`                   | Continuous | Catch degradation immediately |
+| **性能关键的更改** | `*nfr`早期并经常→ `*review` | 持续 | 立即发现性能下降 |
-| **Data Migration**                | `*risk` → `*design` → `*trace` → `*review` → `*gate` | Full cycle | Ensure data integrity         |
+| **数据迁移** | `*risk` → `*design` → `*trace` → `*review` → `*gate` | 完整周期 | 确保数据完整性 |
-| **Bug Fix in Complex System**     | `*risk` → `*trace` → `*review`                       | Focused    | Prevent side effects          |
+| **复杂系统中的错误修复** | `*risk` → `*trace` → `*review` | 专注 | 防止副作用 |
 
-#### Integration with Brownfield Scenarios
+#### 与棕地场景的集成
 
-**Scenario-Specific Guidance:**
+**特定场景指南：**
 
-1. **Legacy Code Modernization**
+1.  **遗留代码现代化**
-   - Start with `*risk` to map all dependencies
+    -   从`*risk`开始以映射所有依赖关系
-   - Use `*design` to plan strangler fig approach
+    -   使用`*design`规划绞杀者无花果方法
-   - Run `*trace` frequently to ensure nothing breaks
+    -   经常运行`*trace`以确保没有任何东西损坏
-   - `*review` with focus on gradual migration
+    -   `*review`时专注于逐步迁移
 
-2. **Adding Features to Monolith**
+2.  **向单体添加功能**
-   - `*risk` identifies integration complexity
+    -   `*risk`识别集成复杂性
-   - `*design` plans isolation strategies
+    -   `*design`规划隔离策略
-   - `*nfr` monitors performance impact
+    -   `*nfr`监控性能影响
-   - `*review` validates no monolith degradation
+    -   `*review`验证没有单体性能下降
 
-3. **Microservice Extraction**
+3.  **微服务提取**
-   - `*risk` maps service boundaries
+    -   `*risk`映射服务边界
-   - `*trace` ensures functionality preservation
+    -   `*trace`确保功能保留
-   - `*nfr` validates network overhead acceptable
+    -   `*nfr`验证网络开销可接受
-   - `*gate` documents accepted trade-offs
+    -   `*gate`记录接受的权衡
 
-4. **Database Schema Changes**
+4.  **数据库模式更改**
-   - `*risk` assesses migration complexity
+    -   `*risk`评估迁移复杂性
-   - `*design` plans backward-compatible approach
+    -   `*design`规划向后兼容的方法
-   - `*trace` maps all affected queries
+    -   `*trace`映射所有受影响的查询
-   - `*review` validates migration safety
+    -   `*review`验证迁移安全性
 
-### 5. Communicate Changes
+### 5. 沟通更改
 
-Document:
+记录：
 
-- What changed and why
+-   更改了什么以及为什么
-- Migration instructions
+-   迁移说明
-- New patterns introduced
+-   引入的新模式
-- Deprecation notices
+-   弃用通知
 
-## Common Brownfield Scenarios
+## 常见棕地场景
 
-### Scenario 1: Adding a New Feature
+### 场景1：添加新功能
 
-1. Document existing system
+1.  记录现有系统
-2. Create brownfield PRD focusing on integration
+2.  创建专注于集成的棕地PRD
-3. **Test Architect Early Involvement**:
+3.  **测试架构师早期参与**：
-   - Run `@qa *risk` on draft stories to identify integration risks
+    -   在草稿故事上运行`@qa *risk`以识别集成风险
-   - Use `@qa *design` to plan regression test strategy
+    -   使用`@qa *design`规划回归测试策略
-4. Architecture emphasizes compatibility
+4.  架构强调兼容性
-5. Stories include integration tasks with test requirements
+5.  故事包括带有测试要求的集成任务
-6. **During Development**:
+6.  **开发期间**：
-   - Developer runs `@qa *trace` to verify coverage
+    -   开发人员运行`@qa *trace`以验证覆盖率
-   - Use `@qa *nfr` to monitor performance impact
+    -   使用`@qa *nfr`监控性能影响
-7. **Review Stage**: `@qa *review` validates integration safety
+7.  **审查阶段**：`@qa *review`验证集成安全性
 
-### Scenario 2: Modernizing Legacy Code
+### 场景2：现代化遗留代码
 
-1. Extensive documentation phase
+1.  广泛的文档阶段
-2. PRD includes migration strategy
+2.  PRD包括迁移策略
-3. **Test Architect Strategy Planning**:
+3.  **测试架构师策略规划**：
-   - `@qa *risk` assesses modernization complexity
+    -   `@qa *risk`评估现代化复杂性
-   - `@qa *design` plans parallel testing approach
+    -   `@qa *design`规划并行测试方法
-4. Architecture plans gradual transition (strangler fig pattern)
+4.  架构规划逐步过渡（绞杀者无花果模式）
-5. Stories follow incremental modernization with:
+5.  故事遵循增量现代化，并带有：
-   - Regression tests for untouched legacy code
+    -   未触及的遗留代码的回归测试
-   - Integration tests for new/old boundaries
+    -   新/旧边界的集成测试
-   - Performance benchmarks at each stage
+    -   每个阶段的性能基准
-6. **Continuous Validation**: Run `@qa *trace` after each increment
+6.  **持续验证**：每个增量后运行`@qa *trace`
-7. **Gate Management**: Use `@qa *gate` to track technical debt acceptance
+7.  **门禁管理**：使用`@qa *gate`跟踪技术债务接受情况
 
-### Scenario 3: Bug Fix in Complex System
+### 场景3：复杂系统中的错误修复
 
-1. Document relevant subsystems
+1.  记录相关子系统
-2. Use `create-brownfield-story` for focused fix
+2.  使用`create-brownfield-story`进行专注修复
-3. **Test Architect Risk Assessment**: Run `@qa *risk` to identify side effect potential
+3.  **测试架构师风险评估**：运行`@qa *risk`以识别副作用的可能性
-4. Include regression test requirements from `@qa *design` output
+4.  包括来自`@qa *design`输出的回归测试要求
-5. **During Fix**: Use `@qa *trace` to map affected functionality
+5.  **修复期间**：使用`@qa *trace`映射受影响的功能
-6. **Before Commit**: Run `@qa *review` for comprehensive validation
+6.  **提交前**：运行`@qa *review`进行全面验证
-7. Test Architect validates no side effects using:
+7.  测试架构师使用以下方法验证无副作用：
-   - Risk profiling for side effect analysis (probability × impact scoring)
+    -   用于副作用分析的风险分析（概率×影响评分）
-   - Trace matrix to ensure fix doesn't break related features
+    -   跟踪矩阵以确保修复不会破坏相关功能
-   - NFR assessment to verify performance/security unchanged
+    -   NFR评估以验证性能/安全性不变
-   - Gate decision documents fix safety
+    -   门禁决策记录修复安全性
 
-### Scenario 4: API Integration
+### 场景4：API集成
 
-1. Document existing API patterns
+1.  记录现有的API模式
-2. PRD defines integration requirements
+2.  PRD定义集成要求
-3. **Test Architect Contract Analysis**:
+3.  **测试架构师合同分析**：
-   - `@qa *risk` identifies breaking change potential
+    -   `@qa *risk`识别重大更改的可能性
-   - `@qa *design` creates contract test strategy
+    -   `@qa *design`创建合同测试策略
-4. Architecture ensures consistent patterns
+4.  架构确保一致的模式
-5. **API Testing Focus**:
+5.  **API测试重点**：
-   - Contract tests for backward compatibility
+    -   用于向后兼容性的合同测试
-   - Integration tests for new endpoints
+    -   新端点的集成测试
-   - Performance tests for added load
+    -   增加负载的性能测试
-6. Stories include API documentation updates
+6.  故事包括API文档更新
-7. **Validation Checkpoints**:
+7.  **验证检查点**：
-   - `@qa *trace` maps all API consumers
+    -   `@qa *trace`映射所有API消费者
-   - `@qa *nfr` validates response times
+    -   `@qa *nfr`验证响应时间
-   - `@qa *review` ensures no breaking changes
+    -   `@qa *review`确保没有重大更改
-8. **Gate Decision**: Document any accepted breaking changes with migration path
+8.  **门禁决策**：记录任何接受的重大更改以及迁移路径
 
-## Troubleshooting
+## 故障排除
 
-### "The AI doesn't understand my codebase"
+### “AI不理解我的代码库”
 
-**Solution**: Re-run `document-project` with more specific paths to critical files
+**解决方案**：用更具体的关键文件路径重新运行`document-project`
 
-### "Generated plans don't fit our patterns"
+### “生成的计划不符合我们的模式”
 
-**Solution**: Update generated documentation with your specific conventions before planning phase
+**解决方案**：在规划阶段之前，用您的特定约定更新生成的文档
 
-### "Too much boilerplate for small changes"
+### “小更改的样板太多”
 
-**Solution**: Use `create-brownfield-story` instead of full workflow
+**解决方案**：使用`create-brownfield-story`代替完整的工作流
 
-### "Integration points unclear"
+### “集成点不清楚”
 
-**Solution**: Provide more context during PRD creation, specifically highlighting integration systems
+**解决方案**：在PRD创建期间提供更多上下文，特别强调集成系统
 
-## Quick Reference
+## 快速参考
 
-### Brownfield-Specific Commands
+### 棕地特定命令
 
 ```bash
-# Document existing project
+# 记录现有项目
 @architect *document-project
 
-# Create enhancement PRD
+# 创建增强PRD
 @pm *create-brownfield-prd
 
-# Create architecture with integration focus
+# 创建具有集成重点的架构
 @architect *create-brownfield-architecture
 
-# Quick epic creation
+# 快速创建史诗
 @pm *create-brownfield-epic
 
-# Single story creation
+# 创建单个故事
 @pm *create-brownfield-story
 ```
 
-### Test Architect Commands for Brownfield
+### 用于棕地的测试架构师命令
 
-Note: Short forms shown below. Full commands: `*risk-profile`, `*test-design`, `*nfr-assess`, `*trace-requirements`
+注意：下面显示的是简写形式。完整命令：`*risk-profile`、`*test-design`、`*nfr-assess`、`*trace-requirements`
 
 ```bash
-# BEFORE DEVELOPMENT (Planning)
+# 开发前（规划）
-@qa *risk {story}     # Assess regression & integration risks
+@qa *risk {story}     # 评估回归和集成风险
-@qa *design {story}   # Plan regression + new feature tests
+@qa *design {story}   # 规划回归+新功能测试
 
-# DURING DEVELOPMENT (Validation)
+# 开发期间（验证）
-@qa *trace {story}    # Verify coverage of old + new
+@qa *trace {story}    # 验证新旧覆盖率
-@qa *nfr {story}      # Check performance degradation
+@qa *nfr {story}      # 检查性能下降
 
-# AFTER DEVELOPMENT (Review)
+# 开发后（审查）
-@qa *review {story}   # Deep integration analysis
+@qa *review {story}   # 深度集成分析
-@qa *gate {story}     # Update quality decision
+@qa *gate {story}     # 更新质量决策
 ```
 
-### Decision Tree
+### 决策树
 
 ```text
-Do you have a large codebase or monorepo?
+您有大型代码库或monorepo吗？
-├─ Yes → PRD-First Approach
+├─ 是 → PRD优先方法
-│   └─ Create PRD → Document only affected areas
+│   └─ 创建PRD → 仅记录受影响的区域
-└─ No → Is the codebase well-known to you?
+└─ 否 → 您是否熟悉代码库？
-    ├─ Yes → PRD-First Approach
+    ├─ 是 → PRD优先方法
-    └─ No → Document-First Approach
+    └─ 否 → 文档优先方法
 
-Is this a major enhancement affecting multiple systems?
+这是一个影响多个系统的重大增强吗？
-├─ Yes → Full Brownfield Workflow
+├─ 是 → 完整的棕地工作流
-│   └─ ALWAYS run Test Architect *risk + *design first
+│   └─ 始终首先运行测试架构师*risk + *design
-└─ No → Is this more than a simple bug fix?
+└─ 否 → 这是否比简单的错误修复更复杂？
-    ├─ Yes → *create-brownfield-epic
+    ├─ 是 → *create-brownfield-epic
-    │   └─ Run Test Architect *risk for integration points
+    │   └─ 为集成点运行测试架构师*risk
-    └─ No → *create-brownfield-story
+    └─ 否 → *create-brownfield-story
-        └─ Still run *risk if touching critical paths
+        └─ 如果触及关键路径，仍运行*risk
 
-Does the change touch legacy code?
+更改是否触及遗留代码？
-├─ Yes → Test Architect is MANDATORY
+├─ 是 → 测试架构师是强制性的
-│   ├─ *risk → Identify regression potential
+│   ├─ *risk → 识别回归可能性
-│   ├─ *design → Plan test coverage
+│   ├─ *design → 规划测试覆盖率
-│   └─ *review → Validate no breakage
+│   └─ *review → 验证无中断
-└─ No → Test Architect is RECOMMENDED
+└─ 否 → 推荐测试架构师
-    └─ *review → Ensure quality standards
+    └─ *review → 确保质量标准
 ```
 
-## Conclusion
+## 结论
 
-Brownfield development with BMad Method provides structure and safety when modifying existing systems. The Test Architect becomes your critical safety net, using risk assessment, regression testing, and continuous validation to ensure new changes don't destabilize existing functionality.
+在修改现有系统时，使用BMad方法的棕地开发提供了结构和安全性。测试架构师成为您防止破坏现有功能的关键安全网，使用风险评估、回归测试和持续验证来确保新更改不会破坏现有功能。
 
-**The Brownfield Success Formula:**
+**棕地成功公式：**
 
-1. **Document First** - Understand what exists
+1.  **首先记录** - 了解存在什么
-2. **Assess Risk Early** - Use Test Architect `*risk` before coding
+2.  **尽早评估风险** - 在编码前使用测试架构师`*risk`
-3. **Plan Test Strategy** - Design regression + new feature tests
+3.  **规划测试策略** - 设计回归+新功能测试
-4. **Validate Continuously** - Check integration health during development
+4.  **持续验证** - 在开发期间检查集成健康状况
-5. **Review Comprehensively** - Deep analysis before committing
+5.  **全面审查** - 在提交前进行深度分析
-6. **Gate Decisively** - Document quality decisions
+6.  **果断地进行门禁** - 记录质量决策
 
-Remember: **In brownfield, the Test Architect isn't optional - it's your insurance policy against breaking production.**
+请记住：**在棕地中，测试架构师不是可选的——它是您防止生产中断的保险单。**