<!-- 由 BMAD™ Core 驱动 -->

# 创建下一个故事任务

## 目的

根据项目进度和史诗定义，确定下一个合乎逻辑的故事，然后使用 `故事模板` 准备一个全面的、自包含的、可操作的故事文件。此任务确保故事富含所有必要的技术背景、需求和验收标准，使其准备好由开发代理高效实施，而无需额外的研究或寻找自身背景。

## 顺序任务执行（在当前任务完成前不要继续）

### 0. 加载核心配置并检查工作流

-   从项目根目录加载 `{root}/core-config.yaml`
-   如果文件不存在，则停止并通知用户：“未找到 core-config.yaml。此文件是创建故事所必需的。您可以：1) 从 GITHUB bmad-core/core-config.yaml 复制并为您的项目配置它 或 2) 对您的项目运行 BMad 安装程序以自动升级并添加该文件。请在继续之前添加并配置 core-config.yaml。”
-   提取关键配置：`devStoryLocation`、`prd.*`、`architecture.*`、`workflow.*`

### 1. 确定要准备的下一个故事

#### 1.1 定位史诗文件并审查现有故事

-   根据配置中的 `prdSharded`，定位史诗文件（分片位置/模式或单片PRD部分）
-   如果 `devStoryLocation` 有故事文件，则加载最高的 `{epicNum}.{storyNum}.story.md` 文件
-   **如果存在最高的故事：**
    -   验证状态是否为“完成”。如果不是，则提醒用户：“警报：发现未完成的故事！文件：{lastEpicNum}.{lastStoryNum}.story.md 状态：[当前状态] 您应首先修复此故事，但您想接受风险并覆盖以草稿形式创建下一个故事吗？”
    -   如果继续，则选择当前史诗中的下一个顺序故事
    -   如果史诗已完成，则提示用户：“史诗 {epicNum} 已完成：史诗 {epicNum} 中的所有故事均已完成。您想：1) 从故事1开始史诗 {epicNum + 1} 2) 选择要处理的特定故事 3) 取消故事创建”
    -   **关键**：切勿自动跳到另一个史诗。用户必须明确指示要创建哪个故事。
-   **如果没有故事文件：** 下一个故事始终是 1.1（第一个史诗的第一个故事）
-   向用户宣布已识别的故事：“已确定要准备的下一个故事：{epicNum}.{storyNum} - {故事标题}”

### 2. 收集故事需求和上一个故事的背景

-   从已识别的史诗文件中提取故事需求
-   如果存在上一个故事，则审查开发代理记录部分以获取：
    -   完成说明和调试日志参考
    -   实施偏差和技术决策
    -   遇到的挑战和经验教训
-   提取为当前故事准备提供信息的相​​关见解

### 3. 收集架构背景

#### 3.1 确定架构阅读策略

-   **如果 `architectureVersion: >= v4` 且 `architectureSharded: true`**：阅读 `{architectureShardedLocation}/index.md`，然后按照下面的结构化阅读顺序进行
-   **否则**：对类似部分使用单片 `architectureFile`

#### 3.2 根据故事类型阅读架构文档

**对于所有故事：** tech-stack.md、unified-project-structure.md、coding-standards.md、testing-strategy.md

**对于后端/API故事，另外：** data-models.md、database-schema.md、backend-architecture.md、rest-api-spec.md、external-apis.md

**对于前端/UI故事，另外：** frontend-architecture.md、components.md、core-workflows.md、data-models.md

**对于全栈故事：** 阅读上面的后端和前端部分

#### 3.3 提取特定于故事的技术细节

仅提取与实施当前故事直接相关的信息。不要发明源文档中没有的新库、模式或标准。

提取：

-   故事将使用的特定数据模型、模式或结构
-   故事必须实施或使用的API端点
-   故事中UI元素的组件规范
-   新代码的文件路径和命名约定
-   特定于故事功能的测试要求
-   影响故事的安全或性能考虑

始终引用源文档：`[来源：architecture/{filename}.md#{section}]`

### 4. 验证项目结构对齐

-   将故事需求与 `docs/architecture/unified-project-structure.md` 中的项目结构指南进行交叉引用
-   确保文件路径、组件位置或模块名称与定义的结构保持一致
-   在故事草稿的“项目结构说明”部分记录任何结构冲突

### 5. 用完整上下文填充故事模板

-   创建新故事文件：使用故事模板在 `{devStoryLocation}/{epicNum}.{storyNum}.story.md` 创建
-   填写基本故事信息：标题、状态（草稿）、故事陈述、来自史诗的验收标准
-   **`开发说明`部分（关键）：**
    -   关键：此部分必须仅包含从架构文档中提取的信息。切勿发明或假设技术细节。
    -   包括步骤2-3中的所有相关技术细节，按类别组织：
        -   **上一个故事的见解**：上一个故事的关键经验教训
        -   **数据模型**：特定的模式、验证规则、关系[附带来源参考]
        -   **API规范**：端点细节、请求/响应格式、身份验证要求[附带来源参考]
        -   **组件规范**：UI组件细节、属性、状态管理[附带来源参考]
        -   **文件位置**：根据项目结构应创建新代码的确切路径
        -   **测试要求**：来自testing-strategy.md的特定测试用例或策略
        -   **技术约束**：版本要求、性能考虑、安全规则
    -   每个技术细节都必须包含其来源参考：`[来源：architecture/{filename}.md#{section}]`
    -   如果在架构文档中未找到某个类别的信息，则明确说明：“在架构文档中未找到具体指导”
-   **`任务/子任务`部分：**
    -   仅根据：史诗需求、故事AC、审查过的架构信息，生成详细的、顺序的技术任务列表
    -   每个任务都必须引用相关的架构文档
    -   根据测试策略，将单元测试作为明确的子任务包括在内
    -   在适用的情况下将任务链接到AC（例如，`任务1 (AC: 1, 3)`）
-   在步骤4中添加有关项目结构对齐或发现的差异的说明

### 6. 故事草稿完成和审查

-   审查所有部分的完整性和准确性
-   验证技术细节的所有来源参考都已包括在内
-   确保任务与史诗需求和架构约束保持一致
-   将状态更新为“草稿”并保存故事文件
-   执行 `{root}/tasks/execute-checklist` `{root}/checklists/story-draft-checklist`
-   向用户提供摘要，包括：
    -   创建的故事：`{devStoryLocation}/{epicNum}.{storyNum}.story.md`
    -   状态：草稿
    -   从架构文档中包含的关键技术组件
    -   注意到的史诗和架构之间的任何偏差或冲突
    -   清单结果
    -   下一步：对于复杂的故事，建议用户仔细审查故事草稿，并可选择让PO运行任务 `{root}/tasks/validate-next-story`