@rdmind/rdmind 0.0.9-alpha.1 → 0.0.9

package/.knowledge/.ext/.bmad-core/tasks/analyze-prd.md

@@ -0,0 +1,123 @@
+<!-- Powered by BMAD™ Core -->
+
+# 分析PRD文档任务
+
+## ⚠️ 重要提醒 ⚠️
+
+**这是个可执行的工作流程，不是参考文档**
+
+用这个任务时：
+
+1. **必须分析现有PRD** - 不能凭空创建需求
+2. **必须逐步分析** - 按顺序分析PRD的各个部分
+3. **必须识别不确定项** - 标记需要进一步确认的内容
+4. **必须输出TRD** - 生成技术需求文档
+
+## 任务目标
+
+将PM产出的PRD文档转化为详细的功能需求文档(TRD)，深入分析业务流程和功能细节，标记不确定事项，为架构师提供清晰的功能需求指导。
+
+## 输入要求
+
+- 一个或多个PRD文档路径
+- 项目基本信息（可选）
+
+## 输出产物
+
+- `docs/trd.md` - 技术需求文档
+- `docs/trd_todo.md` - 待确认事项列表（如果有不确定项）
+
+## 执行步骤
+
+### 步骤1：PRD文档分析
+
+1. **读取PRD文档**：加载用户提供的PRD文档
+2. **文档结构分析**：分析PRD的章节结构和内容完整性
+3. **需求提取**：从PRD中提取功能需求和非功能需求
+4. **业务背景理解**：理解业务目标、成功指标和约束条件
+
+### 步骤2：功能需求细化
+
+1. **用户故事细化**：
+   - 将PRD中的用户故事转化为详细的操作步骤
+   - 明确用户角色、操作流程、期望结果
+   - 识别用户操作的异常情况和处理逻辑
+2. **业务流程分析**：
+   - 详细分析核心业务流程的每个步骤
+   - 识别业务决策点和分支逻辑
+   - 确定业务规则和约束条件
+
+3. **功能规格制定**：
+   - 基于功能需求识别功能模块
+   - 详细描述操作流程和数据流
+   - 识别系统集成点和数据交换需求
+
+### 步骤3：不确定项识别
+
+1. **业务澄清识别**：
+   - 标记需要业务方澄清的需求细节
+   - 识别可能的业务逻辑冲突
+   - 记录需要进一步确认的业务规则
+
+2. **功能细节识别**：
+   - 标记需要进一步明确的功能实现细节
+   - 识别复杂的业务逻辑和异常处理
+   - 记录需要详细说明的用户操作流程
+
+### 步骤4：文档生成
+
+1. **TRD文档生成**：
+   - 使用trd-tmpl.yaml模板生成功能需求文档
+   - 确保所有确定的功能需求都被记录
+   - 保持文档结构清晰和逻辑完整
+
+2. **待办事项生成**：
+   - 如果有不确定项，生成trd_todo.md文档
+   - 按优先级排序待确认事项
+   - 为每个事项提供背景和影响分析
+
+## 交互要求
+
+当遇到以下情况时，需要与用户交互：
+
+1. **PRD文档不完整**：询问缺失的部分或要求补充信息
+2. **需求理解有歧义**：确认对需求的理解是否正确
+3. **业务流程复杂**：当业务流程复杂时，询问具体的处理逻辑
+4. **优先级确认**：确认功能需求的优先级排序
+
+## 质量检查
+
+完成TRD生成后，进行以下检查：
+
+1. **完整性检查**：确保所有PRD需求都被转化为功能需求
+2. **一致性检查**：确保功能需求与业务需求保持一致
+3. **详细性检查**：确保功能需求描述详细，包含足够的实现细节
+4. **清晰性检查**：确保功能需求描述清晰，架构师和开发团队能够理解
+
+## 输出格式
+
+### TRD文档结构
+
+- 文档信息
+- 业务背景
+- 功能需求分析
+- 非功能需求分析
+- 功能规格
+- 实现指导
+- 待确认事项
+
+### 待办事项文档结构
+
+- 业务澄清列表
+- 功能细节列表
+- 业务规则列表
+- 优先级排序
+- 建议的解决路径
+
+## 注意事项
+
+1. **保持功能导向**：TRD应该专注于功能需求，为架构师提供清晰的功能指导
+2. **确保详细性**：所有功能需求都应该详细描述，包含足够的实现细节
+3. **标记不确定项**：不要猜测，不确定的内容要明确标记
+4. **保持可追溯性**：功能需求要与PRD中的业务需求保持可追溯关系
+5. **避免技术设计**：不要进行API设计、数据库设计等技术设计，这些交给架构师

package/.knowledge/.ext/.bmad-core/tasks/apply-qa-fixes.md

@@ -0,0 +1,150 @@
+<!-- Powered by BMAD™ Core -->
+
+# apply-qa-fixes
+
+基于特定story的QA结果（gate和评估）实现修复。这个任务让Dev代理系统性地处理QA输出并应用代码/测试变更，同时只更新story文件中允许的部分。
+
+## 目的
+
+- 读取story的QA输出（gate YAML + 评估markdown）
+- 创建优先级的、确定性的修复计划
+- 应用代码和测试变更来关闭差距并解决问题
+- 只更新Dev代理允许的story部分
+
+## 输入
+
+```yaml
+required:
+  - story_id: '{epic}.{story}' # 比如 "2.2"
+  - qa_root: 来自 `bmad-core/core-config.yaml` 键 `qa.qaLocation` (比如 `docs/project/qa`)
+  - story_root: 来自 `bmad-core/core-config.yaml` 键 `devStoryLocation` (比如 `docs/project/stories`)
+
+optional:
+  - story_title: '{title}' # 如果缺失，从story H1推导
+  - story_slug: '{slug}' # 如果缺失，从标题推导（小写，连字符分隔）
+```
+
+## 要读取的QA源
+
+- gate (YAML): `{qa_root}/gates/{epic}.{story}-*.yml`
+  - 如果有多个，使用修改时间最新的
+- 评估 (Markdown):
+  - Test Design: `{qa_root}/assessments/{epic}.{story}-test-design-*.md`
+  - Traceability: `{qa_root}/assessments/{epic}.{story}-trace-*.md`
+  - Risk Profile: `{qa_root}/assessments/{epic}.{story}-risk-*.md`
+  - NFR Assessment: `{qa_root}/assessments/{epic}.{story}-nfr-*.md`
+
+## 先决条件
+
+- 仓库在本地构建和测试运行（Deno 2）
+- 可用的lint和测试命令：
+  - `deno lint`
+  - `deno test -A`
+
+## 流程（不要跳过步骤）
+
+### 0) 加载核心配置和定位Story
+
+- 读取 `bmad-core/core-config.yaml` 并解析 `qa_root` 和 `story_root`
+- 在 `{story_root}/{epic}.{story}.*.md` 中定位story文件
+  - 如果缺失则停止并询问正确的story id/路径
+
+### 1) 收集QA发现
+
+- 解析最新的gate YAML：
+  - `gate` (PASS|CONCERNS|FAIL|WAIVED)
+  - `top_issues[]` 包含 `id`, `severity`, `finding`, `suggested_action`
+  - `nfr_validation.*.status` 和注释
+  - `trace` 覆盖率总结/差距
+  - `test_design.coverage_gaps[]`
+  - `risk_summary.recommendations.must_fix[]` (如果存在)
+- 读取任何存在的评估markdown并提取明确的差距/建议
+
+### 2) 构建确定性修复计划（优先级顺序）
+
+按顺序应用，最高优先级优先：
+
+1. `top_issues` 中的高严重性项目（安全/性能/可靠性/可维护性）
+2. NFR状态：所有FAIL必须修复 → 然后CONCERNS
+3. Test Design `coverage_gaps`（如果指定，优先P0场景）
+4. 未覆盖的Trace需求（AC级别）
+5. Risk `must_fix` 建议
+6. 中等严重性问题，然后低严重性
+
+指导：
+
+- 优先在代码变更之前/同时添加测试来关闭覆盖率差距
+- 保持变更最小化和针对性；遵循项目架构和TS/Deno规则
+
+### 3) 应用变更
+
+- 按计划实现代码修复
+- 添加缺失的测试来关闭覆盖率差距（优先单元测试；AC要求的集成测试）
+- 通过 `deps.ts` 保持导入集中化（见 `docs/project/typescript-rules.md`）
+- 遵循 `src/core/di.ts` 中的DI边界和现有模式
+
+### 4) 验证
+
+- 运行 `deno lint` 并修复问题
+- 运行 `deno test -A` 直到所有测试通过
+- 迭代直到干净
+
+### 5) 更新Story（仅允许的部分）
+
+关键：Dev代理仅被授权更新story文件的这些部分。不要修改任何其他部分（比如，QA结果、Story、验收标准、开发笔记、测试）：
+
+- Tasks / Subtasks Checkboxes（标记你添加的任何修复子任务为完成）
+- Dev Agent Record →
+  - Agent Model Used（如果更改）
+  - Debug Log References（命令/结果，比如lint/测试）
+  - Completion Notes List（更改了什么，为什么，如何）
+  - File List（所有添加/修改/删除的文件）
+- Change Log（新的日期条目描述应用的修复）
+- Status（见下面的规则）
+
+状态规则：
+
+- 如果gate是PASS且所有识别的差距都已关闭 → 设置 `Status: Ready for Done`
+- 否则 → 设置 `Status: Ready for Review` 并通知QA重新运行评审
+
+### 6) 不要编辑gate文件
+
+- Dev不修改gate YAML。如果修复解决了问题，请求QA重新运行 `review-story` 来更新gate
+
+## 阻塞条件
+
+- 缺失 `bmad-core/core-config.yaml`
+- 找不到 `story_id` 的story文件
+- 没有找到QA工件（既没有gate也没有评估）
+  - 停止并请求QA生成至少一个gate文件（或仅在有明确的开发者提供的修复列表时继续）
+
+## 完成Checklist
+
+- deno lint: 0个问题
+- deno test -A: 所有测试通过
+- 所有高严重性 `top_issues` 已解决
+- NFR FAIL → 已解决；CONCERNS最小化或已记录
+- 覆盖率差距已关闭或已明确记录理由
+- Story已更新（仅允许的部分）包括文件列表和变更日志
+- 根据状态规则设置状态
+
+## 示例：Story 2.2
+
+给定gate `docs/project/qa/gates/2.2-*.yml` 显示
+
+- `coverage_gaps`: Back action行为未测试（AC2）
+- `coverage_gaps`: 集中化依赖执行未测试（AC4）
+
+修复计划：
+
+- 添加测试确保Toolkit Menu "Back" action返回到Main Menu
+- 添加静态测试验证service/view的导入通过 `deps.ts`
+- 重新运行lint/测试并相应更新Dev Agent Record + File List
+
+## 关键原则
+
+- 确定性的、风险优先的优先级排序
+- 最小化、可维护的变更
+- 测试验证行为并关闭差距
+- 严格遵循允许的story更新区域
+- gate所有权仍归QA；Dev通过状态信号准备就绪

package/.knowledge/.ext/.bmad-core/tasks/brownfield-create-epic.md

@@ -0,0 +1,162 @@
+<!-- Powered by BMAD™ Core -->
+
+# 创建现有项目Epic任务
+
+## 目的
+
+为较小的现有项目增强功能创建单个Epic，这些增强不需要完整的PRD和架构文档流程。这个任务适用于可以在有限范围内完成的独立功能或修改。
+
+## 什么时候使用这个任务
+
+**在以下情况下使用这个任务：**
+
+- 增强功能可以在1-3个Story中完成
+- 不需要重大的架构变更
+- 增强功能遵循现有的项目模式
+- 集成复杂度很低
+- 对现有系统的风险较低
+
+**在以下情况下使用完整的现有项目PRD/架构流程：**
+
+- 增强功能需要多个协调的Story
+- 需要架构规划
+- 需要大量的集成工作
+- 需要风险评估和缓解规划
+
+## 操作指南
+
+### 1. 项目分析（必需）
+
+在创建Epic之前，收集现有项目的基本信息：
+
+**现有项目背景：**
+
+- [ ] 了解项目目的和当前功能
+- [ ] 确定现有技术栈
+- [ ] 了解当前架构模式
+- [ ] 确定与现有系统的集成点
+
+**增强功能范围：**
+
+- [ ] 明确定义和限定增强功能范围
+- [ ] 评估对现有功能的影响
+- [ ] 确定所需的集成点
+- [ ] 建立成功标准
+
+### 2. Epic创建
+
+按照以下结构创建一个聚焦的Epic：
+
+#### Epic标题
+
+{{增强功能名称}} - 现有项目增强
+
+#### Epic目标
+
+{{1-2句话描述Epic将完成什么以及为什么它有价值}}
+
+#### Epic描述
+
+**现有系统背景：**
+
+- 当前相关功能：{{简要描述}}
+- 技术栈：{{相关现有技术}}
+- 集成点：{{新工作与现有系统的连接点}}
+
+**增强功能详情：**
+
+- 要添加/修改的内容：{{清晰描述}}
+- 如何集成：{{集成方法}}
+- 成功标准：{{可衡量的结果}}
+
+#### 故事列表
+
+列出完成Epic的1-3个聚焦Story：
+
+1. **Story 1：** {{Story标题和简要描述}}
+2. **Story 2：** {{Story标题和简要描述}}
+3. **Story 3：** {{Story标题和简要描述}}
+
+#### 兼容性要求
+
+- [ ] 现有API保持不变
+- [ ] 数据库模式变更向后兼容
+- [ ] UI变更遵循现有模式
+- [ ] 性能影响最小
+
+#### 风险缓解
+
+- **主要风险：** {{对现有系统的主要风险}}
+- **缓解措施：** {{如何解决风险}}
+- **回滚计划：** {{如何在需要时撤销变更}}
+
+#### 完成定义
+
+- [ ] 所有Story完成并满足验收标准
+- [ ] 通过测试验证现有功能
+- [ ] 集成点正常工作
+- [ ] 适当更新文档
+- [ ] 现有功能无回归
+
+### 3. 验证Checklist
+
+在最终确定Epic之前，确保：
+
+**范围验证：**
+
+- [ ] Epic最多可以在1-3个Story中完成
+- [ ] 不需要架构文档
+- [ ] 增强功能遵循现有模式
+- [ ] 集成复杂度可控
+
+**风险评估：**
+
+- [ ] 对现有系统的风险较低
+- [ ] 回滚计划可行
+- [ ] 测试方法覆盖现有功能
+- [ ] 团队对集成点有足够了解
+
+**完整性检查：**
+
+- [ ] Epic目标清晰且可实现
+- [ ] Story范围适当
+- [ ] 成功标准可衡量
+- [ ] 依赖关系已确定
+
+### 4. 交接给故事经理
+
+Epic验证完成后，向Story经理提供以下交接：
+
+---
+
+**Story经理交接：**
+
+"请为这个现有项目Epic开发详细的用户Story。关键考虑因素：
+
+- 这是对运行{{技术栈}}的现有系统的增强
+- 集成点：{{列出关键集成点}}
+- 要遵循的现有模式：{{相关现有模式}}
+- 关键兼容性要求：{{关键要求}}
+- 每个Story必须包含验证现有功能保持完整的检查
+
+Epic应该在交付{{Epic目标}}的同时保持系统完整性。"
+
+---
+
+## 成功标准
+
+Epic创建成功时：
+
+1. 增强功能范围明确定义且大小适当
+2. 集成方法尊重现有系统架构
+3. 对现有功能的风险最小化
+4. Story按逻辑顺序排列以确保安全实施
+5. 兼容性要求明确指定
+6. 回滚计划可行且有文档记录
+
+## 重要说明
+
+- 这个任务专门用于小型现有项目增强
+- 如果范围超过3个Story，考虑使用完整的现有项目PRD流程
+- 始终优先考虑现有系统完整性而不是新功能
+- 对范围或复杂度有疑问时，升级到完整的现有项目规划

package/.knowledge/.ext/.bmad-core/tasks/brownfield-create-story.md

@@ -0,0 +1,149 @@
+<!-- Powered by BMAD™ Core -->
+
+# 创建 Brownfield Story 任务
+
+## 目的
+
+为非常小的 brownfield 增强功能创建单个用户故事，这些功能可以在一次专注的开发会话中完成。这个任务适用于需要现有系统集成意识的最小添加或 bug 修复。
+
+## 什么时候用这个任务
+
+**用这个任务的情况：**
+
+- 增强功能可以在单个 story 中完成
+- 不需要新架构或重大设计
+- 变更完全遵循现有模式
+- 集成简单，风险最小
+- 变更有清晰的边界，影响范围小
+
+**用 brownfield-create-epic 的情况：**
+
+- 增强功能需要 2-3 个协调的 story
+- 需要一些设计工作
+- 涉及多个集成点
+
+**用完整的 brownfield PRD/架构流程的情况：**
+
+- 增强功能需要多个协调的 story
+- 需要架构规划
+- 需要大量集成工作
+
+## 操作指南
+
+### 1. 快速项目评估
+
+收集现有项目的最小但必要的上下文：
+
+**当前系统上下文：**
+
+- [ ] 识别相关的现有功能
+- [ ] 记录该领域的技术栈
+- [ ] 清楚理解集成点
+- [ ] 识别类似工作的现有模式
+
+**变更范围：**
+
+- [ ] 明确具体的变更内容
+- [ ] 识别影响边界
+- [ ] 建立成功标准
+
+### 2. Story 创建
+
+按照这个结构创建单个专注的 story：
+
+#### Story 标题
+
+{{具体增强功能}} - Brownfield 添加
+
+#### 用户故事
+
+作为 {{用户类型}}，
+我希望 {{具体操作/能力}}，
+以便 {{明确的好处/价值}}。
+
+#### Story 上下文
+
+**现有系统集成：**
+
+- 集成对象：{{现有组件/系统}}
+- 技术栈：{{相关技术栈}}
+- 遵循模式：{{要遵循的现有模式}}
+- 接触点：{{具体集成点}}
+
+#### 验收标准
+
+**功能需求：**
+
+1. {{主要功能需求}}
+2. {{次要功能需求（如果有）}}
+3. {{集成需求}}
+
+**集成需求：** 4. 现有 {{相关功能}} 继续正常工作，无变化 5. 新功能遵循现有 {{模式}} 模式 6. 与 {{系统/组件}} 的集成保持当前行为
+
+**质量需求：** 7. 变更被适当的测试覆盖 8. 文档在需要时更新 9. 验证现有功能无回归
+
+#### 技术说明
+
+- **集成方法：** {{如何连接到现有系统}}
+- **现有模式参考：** {{要遵循的模式的链接或描述}}
+- **关键约束：** {{任何重要的限制或要求}}
+
+#### 完成定义
+
+- [ ] 功能需求满足
+- [ ] 集成需求验证
+- [ ] 现有功能回归测试
+- [ ] 代码遵循现有模式和标准
+- [ ] 测试通过（现有和新的）
+- [ ] 文档在适用时更新
+
+### 3. 风险和兼容性检查
+
+**最小风险评估：**
+
+- **主要风险：** {{对现有系统的主要风险}}
+- **缓解措施：** {{简单的缓解方法}}
+- **回滚方案：** {{需要时如何撤销}}
+
+**兼容性验证：**
+
+- [ ] 对现有 API 无破坏性变更
+- [ ] 数据库变更（如果有）仅为添加性
+- [ ] UI 变更遵循现有设计模式
+- [ ] 性能影响可忽略
+
+### 4. 验证 Checklist
+
+在最终确定 story 之前，确认：
+
+**范围验证：**
+
+- [ ] Story 可以在一次开发会话中完成
+- [ ] 集成方法简单直接
+- [ ] 完全遵循现有模式
+- [ ] 不需要设计或架构工作
+
+**清晰度检查：**
+
+- [ ] Story 需求明确无歧义
+- [ ] 集成点明确指定
+- [ ] 成功标准可测试
+- [ ] 回滚方法简单
+
+## 成功标准
+
+Story 创建成功时：
+
+1. 增强功能明确定义，适合单次会话的范围
+2. 集成方法简单直接，风险低
+3. 现有系统模式已识别并将被遵循
+4. 回滚计划简单可行
+5. 验收标准包括现有功能验证
+
+## 重要说明
+
+- 这个任务仅适用于非常小的 brownfield 变更
+- 如果分析过程中复杂度增加，升级到 brownfield-create-epic
+- 始终优先考虑现有系统完整性
+- 对集成复杂度有疑问时，改用 brownfield-create-epic
+- Story 应该不超过 4 小时的专注开发工作

package/.knowledge/.ext/.bmad-core/tasks/correct-course.md

@@ -0,0 +1,72 @@
+<!-- Powered by BMAD™ Core -->
+
+# 项目变更处理任务
+
+## 目的
+
+- 用 `.bmad-core/checklists/change-checklist` 来系统性地处理项目变更
+- 分析变更对 epic、项目文档和 MVP 的影响
+- 探索解决方案（比如调整范围、回滚功能、重新规划）
+- 为受影响的文档（epic、用户故事、PRD、架构文档等）起草具体的修改建议
+- 生成"Sprint 变更提案"文档，包含影响分析和修改建议，供大家评审
+- 如果变更太大需要重新规划，确保能顺利转给 PM 或架构师处理
+
+## 操作步骤
+
+### 1. 开始前准备
+
+- **确认任务和背景：**
+  - 和用户确认要开始"项目变更处理任务"
+  - 了解变更的具体情况，确保清楚问题是什么以及可能的影响
+  - 确认能访问所有相关文档（PRD、Epic/Story、架构文档、UI/UX 规范）以及 `.bmad-core/checklists/change-checklist`
+- **选择工作方式：**
+  - 问用户想怎么处理：
+    - **"一步步来（推荐）："** 我们逐项过 change-checklist，每项都讨论清楚再起草修改建议，这样可以做得更细致。
+    - **"批量处理："** 我一次性分析完 checklist，然后给你一个完整的变更建议，这样更快但需要你仔细审查。
+  - 用户选好后，确认方式并告诉用户："现在开始用 change-checklist 分析变更并起草修改建议。我会按你选择的方式来指导你。"
+
+### 2. 按 Checklist 分析变更
+
+- 系统性地过 change-checklist 的第 1-4 节（包括变更背景、Epic/Story 影响分析、文档冲突解决、路径评估等）
+- 对每个 checklist 项目：
+  - 向用户展示相关的问题和考虑点
+  - 收集必要信息，分析相关文档（PRD、epic、架构文档、story 历史等）来评估影响
+  - 和用户讨论每个项目的发现
+  - 记录每个 checklist 项目的状态（如 `[x] 已处理`、`[N/A]`、`[!] 需要进一步行动`）以及相关决策
+  - 一起商定第 4 节建议的"推荐方案"
+
+### 3. 起草修改建议
+
+- 基于 checklist 分析结果和商定的"推荐方案"（如果变更太大需要重新规划，直接转给 PM/架构师）：
+  - 找出需要更新的具体文档（如特定 epic、用户故事、PRD 部分、架构文档、图表等）
+  - **为每个文档起草具体的修改建议。** 比如：
+    - 修改用户故事文本、验收标准或优先级
+    - 在 epic 内添加、删除、重新排序或拆分用户故事
+    - 建议修改架构图表（提供更新的 Mermaid 图表或清晰的文字描述）
+    - 更新 PRD 或架构文档中的技术列表、配置详情或特定部分
+    - 必要时起草新的小文档（如特定决策的说明）
+  - 如果选择"一步步来"，和用户逐个讨论并完善每个文档的修改建议
+  - 如果选择"批量处理"，把所有修改建议整理好，下一步一起展示
+
+### 4. 生成"Sprint 变更提案"
+
+- 把完整的 checklist 分析结果和所有商定的修改建议整理成一个"Sprint 变更提案"文档，按照 change-checklist 第 5 节的结构来写
+- 提案要清楚地包含：
+  - **分析摘要：** 简单说明原始问题、分析出的影响（对 epic、文档、MVP 范围的影响）以及选择这个方案的理由
+  - **具体修改建议：** 对每个受影响的文档，清楚地说明要改什么（如"将 Story X.Y 从：[旧文本] 改为：[新文本]"、"给 Story A.B 添加新验收标准：[新 AC]"、"按以下方式更新架构文档第 3.2 节：[新/修改的文本或图表描述]"）
+- 向用户展示完整的"Sprint 变更提案"草稿，收集反馈并做最终调整
+
+### 5. 最终确定和后续安排
+
+- 获得用户对"Sprint 变更提案"的明确批准，包括所有具体的修改建议
+- 向用户提供最终确定的"Sprint 变更提案"文档
+- **根据变更的性质决定下一步：**
+  - **如果修改建议能解决问题，可以直接实施或由 PO/SM 安排：** 说明"项目变更处理任务"已完成，用户现在可以开始实施这些变更（如更新实际项目文档、backlog 项目）。如果需要，建议转给 PO/SM 来安排 backlog
+  - **如果分析表明变更需要重新规划（如重大范围变更、主要架构调整）：** 明确说明这个结论。建议用户下一步找 PM 或架构师，把"Sprint 变更提案"作为重新规划的重要参考
+
+## 输出结果
+
+- **主要输出：** 一个"Sprint 变更提案"文档（markdown 格式），包含：
+  - checklist 分析的摘要（问题、影响、选择方案的理由）
+  - 对所有受影响文档的具体修改建议
+- **过程记录：** 一个带注释的 change-checklist（或完成记录），记录过程中的讨论、发现和决策