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

package/xiaoma-core/checklists/change-checklist.md

@@ -1,184 +0,0 @@
-<!-- Powered by XiaoMa™ 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.
-
-**Instructions:** Review each item with the user. Mark `[x]` for completed/confirmed, `[N/A]` if not applicable, or add notes for discussion points.
-
-[[LLM: INITIALIZATION INSTRUCTIONS - CHANGE NAVIGATION
-
-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
-2. Minor adjustments within a story don't require this process
-3. The goal is to minimize wasted work while adapting to new realities
-4. User buy-in is critical - they must understand and approve changes
-
-Required context:
-
-- The triggering story or issue
-- Current project state (completed stories, current epic)
-- Access to PRD, architecture, and other key documents
-- 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
-
-[[LLM: Start by fully understanding what went wrong and why. Don't jump to solutions yet. Ask probing questions:
-
-- 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
-
-[[LLM: Changes ripple through the project structure. Systematically evaluate:
-
-1. Can we salvage the current epic with modifications?
-2. Do future epics still make sense given this change?
-3. Are we creating or eliminating dependencies?
-4. Does the epic sequence need reordering?
-
-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
-
-[[LLM: Documentation drives development in BMad. Check each artifact:
-
-1. Does this change invalidate documented decisions?
-2. Are architectural assumptions still valid?
-3. Do user flows need rethinking?
-4. Are technical constraints different than documented?
-
-Be thorough - missed conflicts cause future problems.]]
-
-- [ ] **Review PRD:**
-  - [ ] Does the issue conflict with the core goals or requirements stated in the PRD?
-  - [ ] Does the PRD need clarification or updates based on the new understanding?
-- [ ] **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?
-- [ ] **Review Frontend Spec (if applicable):**
-  - [ ] Does the issue conflict with the FE architecture, component library choice, or UI/UX design?
-  - [ ] Are specific FE components or user flows impacted?
-- [ ] **Review Other Artifacts (if applicable):**
-  - [ ] Consider impact on deployment scripts, IaC, monitoring setup, etc.
-- [ ] **Summarize Artifact Impact:** List all artifacts requiring updates and the nature of the changes needed.
-
-## 4. Path Forward Evaluation
-
-[[LLM: Present options clearly with pros/cons. For each path:
-
-1. What's the effort required?
-2. What work gets thrown away?
-3. What risks are we taking?
-4. How does this affect timeline?
-5. Is this sustainable long-term?
-
-Be honest about trade-offs. There's rarely a perfect solution.]]
-
-- [ ] **Option 1: Direct Adjustment / Integration:**
-  - [ ] 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:**
-  - [ ] 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:**
-  - [ ] Is the original PRD MVP still achievable given the issue and constraints?
-  - [ ] Does the MVP scope need reduction (removing features/epics)?
-  - [ ] Do the core MVP goals need modification?
-  - [ ] Are alternative approaches needed to meet the original MVP intent?
-  - [ ] **Extreme Case:** Does the issue necessitate a fundamental replan or potentially a new PRD V2 (to be handled by PM)?
-- [ ] **Select Recommended Path:** Based on the evaluation, agree on the most viable path forward.
-
-## 5. Sprint Change Proposal Components
-
-[[LLM: The proposal must be actionable and clear. Ensure:
-
-1. The issue is explained in plain language
-2. Impacts are quantified where possible
-3. The recommended path has clear rationale
-4. Next steps are specific and assigned
-5. Success criteria for the change are defined
-
-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).
-- [ ] **High-Level Action Plan:** Next steps for stories/updates.
-- [ ] **Agent Handoff Plan:** Identify roles needed (PM, Arch, Design Arch, PO).
-
-## 6. Final Review & Handoff
-
-[[LLM: Changes require coordination. Before concluding:
-
-1. Is the user fully aligned with the plan?
-2. Do all stakeholders understand the impacts?
-3. Are handoffs to other agents clear?
-4. Is there a rollback plan if the change fails?
-5. How will we validate the change worked?
-
-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.
-
----

package/xiaoma-core/checklists/dev-completion-checklist.md

@@ -1,324 +0,0 @@
-# 开发完成检查清单
-
-## 检查清单概述
-
-本检查清单用于开发者在完成用户故事实现后进行全面的自检验证，确保代码质量、功能完整性和测试覆盖度都达到要求标准。
-
-## 代码实现完整性检查
-
-### 数据库层实现
-
-- [ ] **Entity类**: 实体类字段映射正确，注解完整
-- [ ] **Mapper接口**: 所有必需的数据库操作方法已实现
-- [ ] **Mapper XML**: SQL语句正确，参数映射准确
-- [ ] **数据验证**: 数据校验注解和逻辑完整
-- [ ] **事务处理**: 事务边界和传播行为正确设置
-
-### 业务逻辑层实现
-
-- [ ] **Service接口**: 业务接口定义清晰完整
-- [ ] **Service实现**: 业务逻辑实现符合需求
-- [ ] **业务规则**: 所有业务规则都已实现
-- [ ] **异常处理**: 异常情况处理完善
-- [ ] **数据转换**: DTO和Entity转换逻辑正确
-
-### API接口层实现
-
-- [ ] **Controller方法**: 所有API端点都已实现
-- [ ] **参数验证**: 请求参数验证逻辑完整
-- [ ] **响应格式**: 响应数据格式符合API规范
-- [ ] **HTTP状态码**: 状态码使用正确
-- [ ] **错误处理**: 错误响应格式标准化
-
-### 配置和依赖
-
-- [ ] **依赖注入**: Spring Bean配置正确
-- [ ] **配置文件**: 必要的配置参数已添加
-- [ ] **数据库配置**: 数据源和连接池配置正确
-- [ ] **日志配置**: 日志级别和格式配置适当
-
-## 代码质量检查
-
-### 代码规范
-
-- [ ] **命名规范**: 类名、方法名、变量名符合Java规范
-- [ ] **代码格式**: 代码缩进、空行、注释格式统一
-- [ ] **注释完整**: 关键方法和复杂逻辑有充分注释
-- [ ] **导入优化**: 无多余的import语句
-- [ ] **Magic Number**: 避免硬编码数字，使用常量
-
-### 设计原则
-
-- [ ] **单一职责**: 每个类和方法职责单一清晰
-- [ ] **开闭原则**: 设计对扩展开放，对修改封闭
-- [ ] **依赖倒置**: 依赖抽象而不是具体实现
-- [ ] **接口隔离**: 接口定义简洁，职责分离
-- [ ] **DRY原则**: 避免重复代码，提取公共方法
-
-### 性能考虑
-
-- [ ] **SQL优化**: 数据库查询语句优化，避免N+1问题
-- [ ] **缓存使用**: 适当使用缓存提升性能
-- [ ] **资源管理**: 正确关闭资源，避免内存泄漏
-- [ ] **算法复杂度**: 算法时间和空间复杂度合理
-- [ ] **批量操作**: 批量数据操作使用批处理
-
-## 功能实现验证
-
-### 核心功能验证
-
-- [ ] **主要流程**: 核心业务流程功能正常
-- [ ] **数据CRUD**: 增删改查操作都正确实现
-- [ ] **业务规则**: 所有业务规则验证生效
-- [ ] **数据关联**: 相关数据的关联和级联操作正确
-- [ ] **状态管理**: 数据状态转换逻辑正确
-
-### 边界条件处理
-
-- [ ] **空值处理**: null值和空字符串处理适当
-- [ ] **边界值**: 最大值、最小值、临界值处理正确
-- [ ] **数据长度**: 字符串长度限制验证有效
-- [ ] **数值范围**: 数值范围校验生效
-- [ ] **并发处理**: 并发访问情况下数据一致性保证
-
-### 异常情况处理
-
-- [ ] **参数异常**: 无效参数抛出适当异常
-- [ ] **业务异常**: 业务逻辑异常处理完善
-- [ ] **系统异常**: 系统级异常有合理降级处理
-- [ ] **网络异常**: 网络超时和连接异常处理
-- [ ] **数据库异常**: 数据库连接和操作异常处理
-
-## 测试代码完整性
-
-### 单元测试
-
-- [ ] **测试覆盖率**: 代码覆盖率达到80%以上
-- [ ] **Service测试**: 业务逻辑层单元测试完整
-- [ ] **Mapper测试**: 数据访问层测试充分
-- [ ] **Controller测试**: API接口单元测试完整
-- [ ] **工具类测试**: 工具类和辅助方法测试完整
-
-### 集成测试
-
-- [ ] **数据库集成**: 数据库操作集成测试
-- [ ] **API集成**: API接口集成测试
-- [ ] **服务集成**: 多个服务间集成测试
-- [ ] **外部依赖**: 外部服务调用集成测试
-- [ ] **端到端测试**: 完整业务流程端到端测试
-
-### 测试质量
-
-- [ ] **测试数据**: 测试用例使用多样化测试数据
-- [ ] **断言充分**: 测试断言覆盖所有重要输出
-- [ ] **独立性**: 测试用例之间相互独立
-- [ ] **可重复性**: 测试结果稳定可重复
-- [ ] **清理机制**: 测试后数据清理机制完善
-
-## API规范符合性
-
-### 请求处理
-
-- [ ] **HTTP方法**: 使用正确的HTTP方法(GET/POST/PUT/DELETE)
-- [ ] **URL设计**: URL路径设计符合RESTful规范
-- [ ] **参数绑定**: 请求参数正确绑定到方法参数
-- [ ] **Content-Type**: 正确处理不同的Content-Type
-- [ ] **请求头处理**: 必要的请求头信息正确处理
-
-### 响应处理
-
-- [ ] **统一格式**: 响应格式符合项目统一标准
-- [ ] **状态码**: HTTP状态码使用准确
-- [ ] **错误响应**: 错误响应格式标准化
-- [ ] **分页处理**: 分页查询响应格式正确
-- [ ] **响应头**: 必要的响应头信息完整
-
-### 文档一致性
-
-- [ ] **Swagger注解**: API文档注解完整准确
-- [ ] **参数说明**: 请求参数说明详细
-- [ ] **响应说明**: 响应数据结构说明清晰
-- [ ] **示例数据**: 请求响应示例准确
-- [ ] **错误码说明**: 错误码含义说明完整
-
-## 数据库设计符合性
-
-### 数据模型
-
-- [ ] **表结构**: 实际表结构与设计文档一致
-- [ ] **字段类型**: 数据库字段类型使用正确
-- [ ] **约束条件**: 主键、外键、唯一约束正确设置
-- [ ] **索引设计**: 查询索引设计合理有效
-- [ ] **默认值**: 字段默认值设置合理
-
-### 数据操作
-
-- [ ] **CRUD完整**: 增删改查操作完整实现
-- [ ] **事务一致性**: 事务边界设置保证数据一致性
-- [ ] **软删除**: 删除操作使用软删除机制
-- [ ] **乐观锁**: 并发更新使用乐观锁机制
-- [ ] **审计字段**: 创建时间、更新时间等审计字段维护
-
-### 性能优化
-
-- [ ] **查询优化**: SQL查询语句性能优化
-- [ ] **批量处理**: 批量数据操作使用批处理
-- [ ] **连接查询**: 避免过多的连接查询
-- [ ] **分页查询**: 大数据量查询使用分页
-- [ ] **缓存策略**: 适当使用查询缓存
-
-## 安全性检查
-
-### 输入验证
-
-- [ ] **参数校验**: 所有输入参数都有适当校验
-- [ ] **SQL注入**: 使用参数化查询防止SQL注入
-- [ ] **XSS防护**: 输入数据转义防止XSS攻击
-- [ ] **文件上传**: 文件上传安全验证
-- [ ] **权限验证**: API接口权限验证生效
-
-### 数据安全
-
-- [ ] **敏感数据**: 敏感数据加密存储
-- [ ] **日志安全**: 日志中不包含敏感信息
-- [ ] **错误信息**: 错误信息不暴露敏感内容
-- [ ] **访问控制**: 数据访问权限控制适当
-- [ ] **数据脱敏**: 查询结果适当脱敏
-
-## 测试执行结果
-
-### 自动化测试
-
-- [ ] **单元测试**: 所有单元测试通过 ✅
-- [ ] **集成测试**: 集成测试全部通过 ✅
-- [ ] **API测试**: API接口测试全部通过 ✅
-- [ ] **覆盖率测试**: 代码覆盖率达到要求 ✅
-- [ ] **静态分析**: 静态代码分析通过 ✅
-
-### 功能测试
-
-- [ ] **正常流程**: 正常业务流程测试通过
-- [ ] **异常流程**: 异常处理流程测试通过
-- [ ] **边界测试**: 边界条件测试通过
-- [ ] **性能测试**: 性能基准测试通过
-- [ ] **压力测试**: 并发压力测试通过
-
-### 测试报告
-
-- [ ] **测试结果**: 测试结果详细记录
-- [ ] **覆盖报告**: 代码覆盖率报告生成
-- [ ] **性能数据**: 性能测试数据收集
-- [ ] **问题记录**: 发现的问题全部记录
-- [ ] **修复验证**: 修复后的验证结果
-
-## 文档和注释
-
-### 代码文档
-
-- [ ] **类注释**: 所有类都有详细的javadoc注释
-- [ ] **方法注释**: 公共方法都有参数和返回值说明
-- [ ] **复杂逻辑**: 复杂业务逻辑有充分的行内注释
-- [ ] **TODO清理**: 临时TODO注释已清理或转为任务
-- [ ] **版权信息**: 新增文件包含版权和作者信息
-
-### API文档
-
-- [ ] **Swagger更新**: Swagger文档与实现保持一致
-- [ ] **示例更新**: API调用示例更新到最新
-- [ ] **错误码更新**: 错误码文档更新完整
-- [ ] **变更记录**: API变更记录在changelog中
-- [ ] **版本标识**: API版本标识正确
-
-### 实现说明
-
-- [ ] **设计思路**: 复杂功能有设计思路说明
-- [ ] **技术选择**: 技术选择理由记录
-- [ ] **已知限制**: 当前实现的限制条件说明
-- [ ] **扩展建议**: 未来扩展建议记录
-- [ ] **依赖说明**: 外部依赖使用说明
-
-## 版本控制和部署
-
-### 代码提交
-
-- [ ] **提交信息**: 提交信息清晰描述变更内容
-- [ ] **分支策略**: 遵循项目分支管理策略
-- [ ] **冲突解决**: 代码合并冲突已正确解决
-- [ ] **文件清理**: 无临时文件和调试代码提交
-- [ ] **版本标识**: 相关文件版本号正确更新
-
-### 构建验证
-
-- [ ] **编译通过**: 代码编译无错误无警告
-- [ ] **依赖检查**: 项目依赖完整无冲突
-- [ ] **打包验证**: 应用打包成功
-- [ ] **启动验证**: 应用启动无错误
-- [ ] **功能验证**: 部署后功能验证通过
-
-## 完成标准确认
-
-### 功能完成度
-
-- [ ] **需求实现**: 用户故事所有需求都已实现
-- [ ] **验收标准**: 所有验收标准都能通过验证
-- [ ] **API规范**: API实现完全符合设计规范
-- [ ] **数据库**: 数据库操作符合设计要求
-- [ ] **错误处理**: 异常和错误处理完善
-
-### 质量标准
-
-- [ ] **代码质量**: 代码质量达到项目标准
-- [ ] **测试质量**: 测试覆盖率和质量达标
-- [ ] **性能标准**: 性能指标满足要求
-- [ ] **安全标准**: 安全检查全部通过
-- [ ] **文档标准**: 文档完整性达到要求
-
-### 交付就绪
-
-- [ ] **功能验证**: 开发者自测全部通过
-- [ ] **代码审查**: 代码自审查完成
-- [ ] **文档更新**: 相关文档都已更新
-- [ ] **部署验证**: 测试环境部署验证通过
-- [ ] **移交准备**: 准备好移交给QA团队
-
-## 问题记录和处理
-
-### 问题分类
-
-- [ ] **功能问题**: 功能实现不符合需求
-- [ ] **性能问题**: 性能不满足要求
-- [ ] **质量问题**: 代码质量不达标
-- [ ] **安全问题**: 安全漏洞或风险
-- [ ] **兼容问题**: 兼容性问题
-
-### 问题处理
-
-- [ ] **问题分析**: 详细分析问题原因
-- [ ] **解决方案**: 制定具体解决方案
-- [ ] **修复实施**: 按方案进行问题修复
-- [ ] **验证测试**: 修复后重新测试验证
-- [ ] **影响评估**: 评估修复对其他功能的影响
-
-## 使用说明
-
-### 检查流程
-
-1. 完成功能开发后，逐项检查本清单
-2. 对于每个检查项，标记通过(✅)或需要修复(❌)
-3. 记录发现的问题和修复方案
-4. 修复问题后重新检查相关项目
-5. 所有检查项通过后，更新故事状态为"Review"
-
-### 自检技巧
-
-- 站在用户角度验证功能完整性
-- 从代码质量角度审查实现质量
-- 从测试角度验证功能正确性
-- 从运维角度考虑部署和维护
-
-### 常见问题
-
-- **测试覆盖率不足**: 补充缺失的测试用例
-- **API文档不一致**: 更新Swagger注解和文档
-- **异常处理不完善**: 添加适当的异常处理逻辑
-- **性能问题**: 优化查询语句和算法实现