# Prompt - 拆分Salesforce元数据拉取和部署子需求

## 输入引用

引用相关的 docs 文档链接：

- [REQ-010.md](../requirements/REQ-010.md) - Salesforce元数据拉取和部署主需求文档
- [Authentication.canvas](../Authentication.canvas) - 项目架构视觉化展示
- [001-元数据模块设计](../reference-code/metadata/001-元数据模块设计) - 数据库设计和模块架构
- [002-元数据拉取参考网页地址](../reference-code/metadata/002-元数据拉取参考网页地址) - 官方文档和开源项目参考
- [003-元数据拉取和部署数据库设计推荐](../reference-code/metadata/003-元数据拉取和部署数据库设计推荐) - 数据库设计推荐
- [004-元数据部署网页资料链接地址](../reference-code/metadata/004-元数据部署网页资料链接地址) - 部署相关参考资料

## Context Maps

强制列出本次 Prompt 依赖的 Canvas 文件：

- [Authentication.canvas](../Authentication.canvas) - 项目架构视觉化展示
- **相关节点**: [集成核心](node_integration_core) - 提供与Salesforce的各种连接方式
- **相关节点**: [SessionManager](node_session_manager_detail) - 会话管理，提供登录服务
- **相关节点**: [集成任务](node_integration_task) - 处理Salesforce的定时同步任务
- **相关节点**: [通用常量](node_common_constant) - Salesforce相关常量定义

## 目标

将 REQ-010 "Salesforce元数据拉取和部署" 需求拆分为多个可独立开发、测试和部署的子需求。每个子需求应该：
- 具有明确的范围和边界
- 可以独立完成并验证
- 遵循项目的现有架构和设计模式
- 具有清晰的依赖关系
- 包含完整的验收标准

## 输出格式

输出格式为 Markdown 文档，每个子需求包含以下结构：

```markdown
## 子需求 N: [子需求名称]

### 需求信息
- **子需求编号**: REQ-010-N
- **父需求**: REQ-010
- **需求类型**: [功能需求 | 数据需求 | 接口需求]
- **优先级**: [高 | 中 | 低]
- **预计工作量**: [人天]

### 需求描述
简要描述子需求的目标和范围

### 功能范围
列出子需求包含的具体功能点

### 验收标准
列出具体的验收标准，每个标准应该是可测试的

### 依赖关系
- **前置依赖**: 列出依赖的其他子需求
- **被依赖**: 列出依赖此子需求的其他子需求

### 技术要点
列出实现此子需求需要关注的技术点

### 数据库设计
列出需要创建或修改的数据库表

### API接口
列出需要创建或修改的API接口

### 风险点
列出实现此子需求可能遇到的风险
```

## 约束

- **技术栈限制**: 必须基于现有的 Spring Boot 3 + Vue 3 技术栈
- **架构约束**: 必须遵循 Authentication.canvas 中定义的架构和调用关系
- **模块约束**: 必须在 `datai-salesforce-metadata` 模块下实现
- **数据库约束**: 必须使用 MyBatis Plus 作为持久层框架
- **认证约束**: 必须使用现有的认证模块和 SessionManager 进行会话管理
- **API约束**: 必须使用现有的集成核心功能进行 Salesforce API 调用
- **文档约束**: 每个子需求必须遵循 REQ-010 中定义的验收标准
- **依赖约束**: 子需求之间的依赖关系必须清晰，避免循环依赖

## Rule Set

"请严格参考 @Authentication.canvas 中的状态机转移逻辑，不要自行发挥。"

**具体规则**：
- 必须使用 Canvas 中定义的类名和方法名
- 必须遵循 Canvas 中定义的调用关系
- 必须参考 Canvas 中的流程图逻辑
- 必须使用 SessionManager 进行会话管理和自动重新登录
- 必须使用现有的认证模块进行 OAuth 认证
- 必须使用现有的集成核心功能进行 API 调用
- 必须遵循现有的异常处理机制
- 必须遵循现有的日志记录规范

## 拆分原则

1. **独立性原则**: 每个子需求应该可以独立开发、测试和部署
2. **优先级原则**: 优先拆分高优先级、低依赖的需求
3. **粒度原则**: 每个子需求的工作量控制在 3-5 人天
4. **完整性原则**: 每个子需求应该包含完整的 CRUD 操作
5. **可测试性原则**: 每个子需求应该有清晰的验收标准

## 建议的子需求拆分方向

基于 REQ-010 的 7 个详细需求，建议按以下方向拆分：

### 方向 1: 基础设施层（优先级：高）
- 子需求 1: 数据库表结构设计和创建
- 子需求 2: 基础实体类和 Mapper 创建

### 方向 2: 配置管理层（优先级：高）
- 子需求 3: Salesforce 组织配置管理
- 子需求 4: 元数据任务定义管理

### 方向 3: 元数据拉取层（优先级：高）
- 子需求 5: Metadata API 客户端封装
- 子需求 6: 元数据拉取核心功能
- 子需求 7: 文件存储和解压处理

### 方向 4: 元数据部署层（优先级：高）
- 子需求 8: 元数据部署核心功能
- 子需求 9: Quick Deploy 功能实现
- 子需求 10: Destructive Changes 功能实现

### 方向 5: 元数据管理层（优先级：中）
- 子需求 11: 元数据组件索引和查询
- 子需求 12: 文件哈希对比和增量检测
- 子需求 13: 版本回溯功能

### 方向 6: 监控和日志层（优先级：中）
- 子需求 14: 作业执行监控
- 子需求 15: 详细日志记录和查询

### 方向 7: 异常处理和优化（优先级：中）
- 子需求 16: 异常处理机制完善
- 子需求 17: 性能优化和限流处理

## 验收标准

定义验证输出质量的具体标准：

1. **完整性**: 所有子需求必须覆盖 REQ-010 的所有功能点
2. **独立性**: 每个子需求应该可以独立开发和测试
3. **可追溯性**: 每个子需求必须能够追溯到 REQ-010 的具体需求项
4. **可测试性**: 每个子需求必须有清晰的验收标准
5. **可行性**: 每个子需求的工作量评估应该合理
6. **依赖清晰**: 子需求之间的依赖关系必须清晰明确
7. **技术可行**: 每个子需求的技术方案必须可行
8. **符合架构**: 每个子需求必须符合现有的项目架构

## 风险

识别使用此提示词可能带来的风险：

1. **拆分粒度风险**: 子需求拆分过细或过粗，影响开发效率
2. **依赖关系风险**: 子需求之间的依赖关系不清晰，导致开发阻塞
3. **工作量评估风险**: 工作量评估不准确，影响项目进度
4. **技术方案风险**: 某些子需求的技术方案可能存在技术难点
5. **优先级风险**: 子需求的优先级排序不合理，影响整体进度

## 使用指南

### 使用步骤

1. **准备工作**:
   - 阅读 REQ-010.md 了解完整需求
   - 阅读 Authentication.canvas 了解项目架构
   - 阅读参考资料了解技术细节

2. **拆分过程**:
   - 按照"建议的子需求拆分方向"进行拆分
   - 为每个子需求填写完整的输出格式
   - 确保每个子需求符合"拆分原则"

3. **验证检查**:
   - 检查所有子需求是否覆盖 REQ-010 的所有功能点
   - 检查每个子需求的验收标准是否清晰
   - 检查子需求之间的依赖关系是否合理
   - 检查工作量评估是否合理

4. **输出结果**:
   - 生成完整的子需求拆分文档
   - 保存为独立的 Markdown 文件（如 `010-metadata-retrieve-deploy-sub-requirements.md`）

### 注意事项

- 拆分时要考虑团队的技术能力和资源情况
- 优先拆分高优先级、低依赖的需求
- 每个子需求的工作量应该控制在 3-5 人天
- 子需求之间的依赖关系要尽量减少
- 每个子需求应该有明确的交付物

## 使用记录

| 日期 | 使用场景 | 输入参数 | 输出结果 | 反馈 | 改进措施 |
|------|---------|---------|---------|------|----------|
| 2026-01-17 | 拆分 REQ-010 子需求 | REQ-010.md, Authentication.canvas, 参考资料 | 生成子需求拆分文档 | - | - |