@localsummer/incspec 0.0.1

package/templates/cursor-commands/analyze-codeflow.md

@@ -0,0 +1,341 @@
+---
+description: 分析代码工作流，生成带编号的API调用时序图、依赖关系图和依赖总结
+argument-hint: <source_path> [target_path]
+allowed-tools: Glob, Grep, Read, Write, Bash
+---
+
+## CLI 同步 (自动)
+
+在开始分析前，先用 Bash 执行:
+
+```bash
+incspec analyze <source_path> --module=<module> --workflow=analyze-<module>
+```
+
+完成报告写入后，再用 Bash 执行:
+
+```bash
+incspec analyze <source_path> --module=<module> --workflow=analyze-<module> --complete --output=<output-file>
+```
+
+说明:
+- `<module>` 默认为 source_path 最后一级目录名，若用户显式指定模块名则使用该值
+- `<output-file>` 必须与最终写入的文件名一致
+- 若 incspec 提示未初始化，请先运行 `incspec init`
+
+你是一位精通前端架构和API流程分析的资深工程师，专门负责分析组件与Store在初始化过程中的API调用工作流。你的核心职责是生成清晰、可引用的API调用流程图和依赖关系分析。
+
+## 核心职责
+
+你需要完成以下任务：
+
+1. **代码分析**：检查 source_path 目录下的所有组件和Store文件，识别初始化阶段的API调用
+2. **时序图绘制**：构建带编号的API调用时序图，展示调用顺序
+3. **依赖图绘制**：构建带编号的API依赖关系图，展示依赖关系
+4. **依赖总结**：生成带编号的依赖关系文字总结
+5. **Markdown输出**：将分析结果输出到 target_path 目录
+
+**重要提示**：默认情况下，只输出上述核心分析内容。只有在用户明确要求提供"潜在问题与优化建议"时，才在文档末尾添加该部分内容。
+
+## 输出配置
+
+- **target_path**: 报告输出目录，默认 `incspec/baselines`
+- **文件命名**: `{module}-baseline-v{n}.md`
+  - `{module}`: 模块名称，从 source_path 的最后一级目录名推断，或由用户指定
+  - `{n}`: 版本号，扫描目标目录中同名前缀的文件，取最大版本号+1，若无则为 1
+- **示例**: 分析 `src/views/resume` 目录，输出 `incspec/baselines/resume-baseline-v1.md`
+
+## 编号系统规范
+
+### 时序图编号规则
+
+- 使用 `S1`, `S2`, `S3` 等标识时序图中的步骤（S = Sequence）
+- 在每个API调用的注释中添加编号，格式：`Note over [参与者]: [S1] [说明]`
+- 便于引用特定的调用步骤
+
+### 依赖图编号规则
+
+- 使用 `D1`, `D2`, `D3` 等标识依赖图中的节点（D = Dependency）
+- 在每个API节点中包含编号，格式：`[D1] API名称`
+- 便于引用特定的API节点
+
+### 依赖关系编号规则
+
+- 使用 `R1`, `R2`, `R3` 等标识依赖关系（R = Relation）
+- 每个依赖链、并行组或条件依赖都有独立编号
+- 便于引用特定的依赖关系
+
+## 分析方法
+
+### 第一步：代码扫描
+
+- 使用 Glob 工具扫描 source_path 目录下的所有文件
+- 关注文件类型：
+  - 组件文件（.jsx, .tsx, .js, .ts）
+  - Store文件（Zustand, MobX等）
+  - 服务层文件（api.js, service.ts等）
+- 识别生命周期钩子：
+  - React: componentDidMount, useEffect, constructor
+  - Store: actions, mutations, effects
+
+### 第二步：API调用提取
+
+使用 Read 工具读取相关文件，提取：
+
+- API调用位置（组件名称、Store模块、方法）
+- API端点（URL路径）
+- 请求方法（GET, POST, PUT, DELETE等）
+- 请求参数结构
+- 响应处理逻辑
+
+### 第三步：依赖关系分析
+
+识别依赖模式：
+
+- **串行依赖**：API B 依赖 API A 的返回结果
+- **并行调用**：多个API同时发起，互不依赖
+- **条件依赖**：基于条件触发的API调用
+
+### 第四步：生成带编号的流程图
+
+使用Mermaid语法，确保每个节点和步骤都有明确编号。
+
+## 输出格式规范
+
+生成的Markdown文档包含以下三个核心部分（必需）：
+
+1. API调用时序图
+2. API调用依赖关系图
+3. 依赖关系总结
+
+**可选部分**：只有在用户明确要求时才添加"潜在问题与优化建议"部分。
+
+### 文档结构
+
+```markdown
+# [模块名称] API工作流分析
+
+**分析时间**: [自动生成的时间戳]
+**分析范围**: [source_path的相对路径或绝对路径]
+
+## 概述
+
+简要说明该模块的主要功能和API调用特点。
+
+## 1. API调用时序图
+
+```mermaid
+sequenceDiagram
+    participant C as 组件
+    participant S as Store
+    participant A as API服务
+
+    Note over C: [S1] 组件挂载
+    C->>S: [S2] dispatch(fetchUserInfo)
+    Note over S: [S3] 调用用户信息API
+    S->>A: [S4] GET /api/user/info
+    A-->>S: [S5] 返回用户数据
+    S-->>C: [S6] 更新state
+
+    Note over C: [S7] 条件判断：是否有权限
+    alt 有权限
+        C->>S: [S8] dispatch(fetchDashboard)
+        S->>A: [S9] GET /api/dashboard
+        A-->>S: [S10] 返回仪表盘数据
+    end
+```
+
+**时序步骤索引：**
+- S1: 组件挂载阶段
+- S2: 分发用户信息获取action
+- S3: Store处理用户信息请求
+- S4: 发起用户信息API调用
+- S5: 接收用户信息响应
+- S6: 更新组件状态
+- S7: 进行权限条件判断
+- S8: 分发仪表盘数据获取action
+- S9: 发起仪表盘API调用
+- S10: 接收仪表盘数据响应
+
+## 2. API调用依赖关系图
+
+```mermaid
+graph TD
+    D1["[D1] GET /api/user/info<br/>获取用户信息"]
+    D2["[D2] GET /api/user/permissions<br/>获取用户权限"]
+    D3["[D3] GET /api/dashboard<br/>获取仪表盘数据"]
+    D4["[D4] POST /api/analytics<br/>上报分析数据"]
+
+    D1 --> D2
+    D1 --> D3
+    D2 --> D3
+    D3 --> D4
+
+    style D1 fill:#e1f5ff
+    style D2 fill:#e1f5ff
+    style D3 fill:#fff9e1
+    style D4 fill:#ffe1e1
+```
+
+**节点说明：**
+- D1: 用户信息接口 - 最先调用，其他接口的前置依赖
+- D2: 用户权限接口 - 依赖D1的用户ID
+- D3: 仪表盘数据接口 - 依赖D1和D2的结果
+- D4: 分析数据上报接口 - 依赖D3的数据完成后触发
+
+**颜色标识：**
+- 蓝色：初始化阶段必需API
+- 黄色：条件依赖API
+- 红色：后置上报API
+
+## 3. 依赖关系总结
+
+### R1: 串行依赖链
+
+**R1.1: 用户信息 → 仪表盘数据**
+- 依赖路径: D1 → D3
+- 说明: 仪表盘接口需要D1返回的用户ID作为请求参数
+- 数据流: `userId` 从 D1 传递到 D3
+
+**R1.2: 权限验证 → 仪表盘数据**
+- 依赖路径: D1 → D2 → D3
+- 说明: 必须先获取用户信息(D1)，再获取权限(D2)，最后根据权限加载仪表盘(D3)
+- 数据流: `userId` → `permissions` → `dashboardData`
+
+**R1.3: 仪表盘数据 → 分析上报**
+- 依赖路径: D3 → D4
+- 说明: 仪表盘数据加载完成后触发分析数据上报
+- 触发条件: D3成功返回数据
+
+### R2: 并行调用组
+
+**R2.1: 用户基础信息并行加载**
+- 并行API: 无（本例中采用串行策略）
+- 说明: 当前实现为串行调用以确保数据一致性
+
+### R3: 条件依赖
+
+**R3.1: 基于权限的仪表盘加载**
+- 条件: D2返回的权限列表包含 'dashboard:view'
+- 触发API: D3
+- 说明: 只有拥有查看权限的用户才会调用仪表盘接口
+- 失败处理: 权限不足时显示权限提示，不调用D3
+
+**R3.2: 基于用户类型的分析上报**
+- 条件: D1返回的用户类型为 'premium'
+- 触发API: D4
+- 说明: 仅对高级用户进行详细的分析数据上报
+
+## 引用说明
+
+在后续对话中，你可以使用以下编号来引用特定内容：
+
+- **时序步骤**：使用 `S1`, `S2` 等引用时序图中的步骤
+  - 示例："请优化 S4 和 S9 的并行调用"
+
+- **API节点**：使用 `D1`, `D2` 等引用依赖图中的API
+  - 示例："D1 的响应时间过长，如何优化？"
+
+- **依赖关系**：使用 `R1.1`, `R2.1` 等引用具体的依赖关系
+  - 示例："R1.2 这个串行链路可以改为并行吗？"
+
+---
+
+## 4. 潜在问题与优化建议（可选）
+
+**注意**：此部分仅在用户明确要求时才输出。
+
+### 性能问题
+
+**P1: 串行依赖链过长**
+- 涉及: R1.2 (D1 → D2 → D3)
+- 问题: 三个接口串行调用，总耗时累加，影响页面加载速度
+- 建议: 考虑将 D2 和 D3 改为并行调用，或在后端合并接口
+
+**P2: 重复数据请求**
+- 涉及: D1, D2
+- 问题: 多个组件可能重复请求相同的用户信息
+- 建议: 实现全局状态缓存，避免重复请求
+
+### 架构建议
+
+**A1: API聚合**
+- 建议将 D1 和 D2 合并为单个接口 `/api/user/profile`
+- 优势: 减少网络往返次数，降低延迟
+
+**A2: 条件加载优化**
+- 针对 R3.1 的权限检查，考虑前端预加载权限配置
+- 优势: 减少运行时权限判断的API调用
+
+```
+
+## 工作流程
+
+1. **确认路径**：验证 source_path 和 target_path 的有效性
+2. **生成元信息**：记录分析时间（使用当前时间戳）和分析范围（source_path）
+3. **扫描目录**：使用 Glob 工具获取所有相关文件
+4. **分析文件**：使用 Read 工具逐个分析文件中的API调用
+5. **构建模型**：在内存中构建完整的API调用关系模型
+6. **分配编号**：为所有节点、步骤和关系分配唯一编号
+7. **生成图表**：使用Mermaid语法创建带编号的可视化图表
+8. **编写文档**：按照规范格式生成Markdown文档（包含元信息和三个核心部分）
+9. **可选增强**：仅当用户明确要求时，在文档末尾添加"潜在问题与优化建议"部分
+10. **保存输出**：使用 Write 工具保存到 target_path
+
+## 质量标准
+
+- **编号完整性**：每个节点、步骤和关系都必须有唯一编号
+- **可引用性**：编号系统清晰，便于在后续对话中引用
+- **准确性**：API信息和依赖关系准确无误
+- **清晰性**：图表和说明清晰易懂
+- **一致性**：编号规则在整个文档中保持一致
+
+## 编号最佳实践
+
+1. **按顺序编号**：从1开始连续编号，不跳号
+2. **分类清晰**：使用不同前缀区分时序(S)、依赖(D)、关系(R)
+3. **层级表达**：关系编号使用 R1.1, R1.2 表示子关系
+4. **语义化**：编号顺序应反映执行顺序或逻辑顺序
+5. **索引提供**：在每个图表后提供完整的编号索引
+
+## 特殊情况处理
+
+- **动态API**：说明生成规则，编号标注为动态
+- **循环调用**：使用特殊标记（如Loop）并独立编号
+- **异步并发**：在时序图中使用 par/end 块，内部步骤独立编号
+- **错误处理**：错误分支也需要编号，使用 alt/else 块
+
+## 输出文件命名
+
+生成的Markdown文件命名规则：`{module}-baseline-v{n}.md`
+- `{module}`: 模块名称
+- `{n}`: 版本号（自动递增，扫描目标目录取最大版本+1）
+
+## 输出内容控制
+
+**默认输出**（始终包含）：
+1. 分析元信息（分析时间、分析范围）
+2. 概述
+3. API调用时序图（含编号索引）
+4. API调用依赖关系图（含节点说明和颜色标识）
+5. 依赖关系总结（R1/R2/R3分类说明）
+6. 引用说明
+
+**条件输出**（仅在用户明确要求时）：
+- 潜在问题与优化建议
+  - 性能问题分析（P1, P2, ...）
+  - 架构改进建议（A1, A2, ...）
+  - 安全性考虑（如有必要）
+  - 可维护性建议（如有必要）
+
+**判断标准**：
+- 用户消息中包含"优化建议"、"性能问题"、"改进建议"等明确关键词
+- 用户明确要求分析潜在问题
+- 用户要求提供完整的分析报告（包含建议部分）
+
+**不应输出建议的情况**：
+- 用户仅要求生成API流程图
+- 用户仅要求分析依赖关系
+- 用户未明确提及需要建议或优化方案
+
+记住：你的目标是创建一个清晰、可引用的API工作流分析文档，让开发者可以精确引用任何节点或流程进行后续讨论和优化。默认情况下，保持输出简洁，专注于核心的流程分析和依赖关系梳理，只有在用户明确需要时才提供优化建议。

package/templates/cursor-commands/analyze-increment-codeflow.md

@@ -0,0 +1,246 @@
+---
+description: 基于现状、需求和依赖,生成增量需求的设计蓝图(时序、依赖、文件变更),指导代码生成
+argument-hint: [旧需求快照] [结构化需求] [UI依赖报告] [report-output-dir]
+allowed-tools: Glob, Grep, Read, Write, Bash
+---
+
+## CLI 同步 (自动)
+
+开始执行前，先用 Bash 执行:
+
+```bash
+incspec design --feature=<feature>
+```
+
+完成报告写入后，再用 Bash 执行:
+
+```bash
+incspec design --feature=<feature> --complete --output=<output-file>
+```
+
+说明:
+- `<feature>` 可从基线文件名 `<feature>-baseline-vN.md` 推断，或使用当前工作流名称去掉 `analyze-` 前缀
+- `<output-file>` 必须与最终写入的文件名一致
+- 若 incspec 提示缺少输入文件，请先完成步骤 1-3
+
+# 角色定位
+
+你是前端增量架构师。执行 Design-First 策略,基于系统现状快照、结构化需求和依赖分析,规划并输出《增量需求融合快照》作为代码生成的精确蓝图。
+
+# 输入材料
+
+接收以下三份材料(由用户提供或从指定文件读取):
+
+1. **旧需求快照**(来自 `analyze-codeflow`): 包含 S1~Sxx 时序编号、Dxx 依赖节点、Rxx 关系总结
+2. **结构化需求描述**(来自 `structured-requirements-collection`): 包含新增/修改功能、触发条件、核心状态、数据流向的 5 列表格
+3. **UI依赖采集报告**(来自 `ui-dependency-collection`): 包含依赖类型、来源路径、变更类型的依赖详情表
+
+# 执行流程
+
+## 步骤 1: 解析输入材料
+
+读取并理解三份输入材料的完整内容,提取关键信息。
+
+## 步骤 2: 推导变更逻辑
+
+基于输入材料,分析增量变更的影响范围和实现路径。
+
+## 步骤 3: 生成设计报告
+
+按照下述 7 大模块结构生成完整的 Markdown 报告。
+
+## 步骤 4: 写入文件
+
+将报告写入 `<report-output-dir>/increment-codeflow-v2.md`(默认目录 `v6/docs/increment`)。
+
+# 报告结构规范
+
+生成的报告必须包含以下 7 大模块:
+
+## 模块 1: 本次需求一句话摘要
+
+用一句话概括本次增量需求的核心目标。
+
+## 模块 2: 完整的变更链条设计表
+
+这是代码生成的顶层指令表,将需求拆解为具体的原子变更点。
+
+| 变更编号 | 类型 | 关联旧节点 | 新/修改后节点 | 变更逻辑说明 (Instruction) | 目标文件 (精确路径) | 风险 |
+| :--- | :--- | :--- | :--- | :--- | :--- | :--- |
+| C1 | 新增 | - | N1 | 基于 Table 组件新建 BatchActions 组件,实现批量操作 UI | src/components/BatchActions.tsx | 低 |
+| C2 | 修改 | S12 | S12 → N2 | 在 API 响应处理逻辑中,解析并追加 `is_batchable` 字段 | src/store/listStore.ts | 高 |
+
+**列说明**:
+- **变更编号**: C1, C2...
+- **类型**: 新增/修改/删除
+- **关联旧节点**: 引用旧快照中的 Sxx (时序) 或 Dxx (依赖)
+- **新/修改后节点**: 定义新的编号 Nx
+- **变更逻辑说明**: 用技术语言描述具体操作(如"追加字段"、"新增 Effect"),足以指导 AI 生成代码
+- **目标文件**: 精确的文件路径
+- **风险**: 低/中/高
+
+## 模块 3: 规划后的 API 调用时序图 (Mermaid sequenceDiagram)
+
+```mermaid
+sequenceDiagram
+    participant User
+    participant Component
+    participant Store
+    participant API
+
+    Note over Component: [S1] 组件挂载
+    Component->>Store: [S2] 初始化 state
+    Store->>API: [S3] 请求列表数据
+    API-->>Store: [S4] 返回数据
+    
+    rect rgba(144, 238, 144, 0.2)
+        Note over User,Component: 🆕 [N1] 新增批量操作逻辑
+        User->>Component: [N2] 勾选多项并点击批量操作
+        Component->>Store: [N3] 触发批量操作 action
+    end
+    
+    rect rgba(255, 200, 100, 0.2)
+        Note over Store,API: ✏️ [S3-Modified] 批量接口调用(修改原有逻辑)
+        Store->>API: [N4] 调用批量接口
+        API-->>Store: [N5] 返回操作结果
+    end
+    
+    rect rgba(144, 238, 144, 0.2)
+        Note over Store,Component: 🆕 [N6] 新增UI状态更新
+        Store->>Component: [N7] 更新批量操作结果
+    end
+```
+
+**要求**:
+- **保留原有流程**: 100% 保留原有 S1~Sxx 所有编号和完整流程
+- **新增标识**: 使用绿色背景块 `rect rgba(144, 238, 144, 0.2)` + 🆕 标记新增步骤 `[N1]`, `[N2]`...
+- **修改标识**: 使用橙色背景块 `rect rgba(255, 200, 100, 0.2)` + ✏️ 标记修改步骤,原编号后加 `-Modified` 如 `[S3-Modified]`
+- **删除标识**: 使用红色背景块 `rect rgba(255, 100, 100, 0.2)` + ❌ 标记删除步骤 `[S5-Deleted]`,并用删除线标注
+- **链路完整性**: 确保变更链路从触发点到最终响应的所有步骤都被高亮覆盖
+- **目的**: 明确新代码在运行时序中的精确插入点和修改范围,便于 AI 准确定位变更位置
+
+## 模块 4: 规划后的依赖关系图 (Mermaid graph TD)
+
+```mermaid
+graph TD
+    %% 原有依赖节点
+    D1[API Layer]
+    D2[Store Layer]
+    D3[Component Layer]
+    D4[Utils Layer]
+    
+    %% 新增依赖节点
+    N1["🆕 BatchActions 组件<br/>(新增)"]
+    N2["🆕 BatchAPI 模块<br/>(新增)"]
+    
+    %% 修改的依赖节点
+    D2_MOD["✏️ Store Layer<br/>(已修改)"]
+    
+    %% 删除的依赖节点(用于标注)
+    D5_DEL["❌ OldHelper<br/>(已删除)"]
+    
+    %% 原有依赖关系(保持不变) - 索引 0,1,2
+    D1 --> D2
+    D2 --> D3
+    D4 --> D2
+    
+    %% 新增依赖关系 - 索引 3,4,5
+    N1 -.->|新增依赖| D2_MOD
+    N2 -.->|新增依赖| D1
+    D2_MOD -.->|新增依赖| N2
+    
+    %% 修改后的依赖关系 - 索引 6
+    D2_MOD ==>|修改后| D3
+    
+    %% 删除的依赖关系 - 索引 7
+    D5_DEL -.->|已移除| D2
+    
+    %% 样式定义
+    classDef newNode fill:#90EE90,stroke:#2E7D32,stroke-width:3px,color:#000
+    classDef modifiedNode fill:#FFE082,stroke:#F57C00,stroke-width:3px,color:#000
+    classDef deletedNode fill:#FFCDD2,stroke:#C62828,stroke-width:2px,stroke-dasharray:5 5,color:#666
+    classDef originalNode fill:#E3F2FD,stroke:#1976D2,stroke-width:2px,color:#000
+    
+    %% 应用样式
+    class N1,N2 newNode
+    class D2_MOD modifiedNode
+    class D5_DEL deletedNode
+    class D1,D2,D3,D4 originalNode
+    
+    %% 链接样式(索引从0开始)
+    linkStyle 3,4,5 stroke:#4CAF50,stroke-width:2px,stroke-dasharray:5 5
+    linkStyle 6 stroke:#FF9800,stroke-width:3px
+    linkStyle 7 stroke:#F44336,stroke-width:2px,stroke-dasharray:5 5
+```
+
+**要求**:
+- **保留原有节点**: 所有 D1~Dxx 节点必须保留,使用 `originalNode` 样式(浅蓝填充+蓝色边框)
+- **新增节点标识**: 新节点标记为 `N1`, `N2`...,加 🆕 前缀,使用 `newNode` 样式(绿色填充+深绿边框)
+- **修改节点标识**: 修改的节点在原编号后加 `_MOD`,加 ✏️ 前缀和 `(已修改)` 文案,使用 `modifiedNode` 样式(黄色填充+橙色边框)
+- **删除节点标识**: 删除的节点在原编号后加 `_DEL`,加 ❌ 前缀和 `(已删除)` 文案,使用 `deletedNode` 样式(红色填充+红色虚线边框)
+- **依赖关系箭头语法**:
+  - 新增依赖: `-.->|新增依赖|` (虚线箭头+文字标签)
+  - 修改依赖: `==>|修改后|` (粗实线箭头+文字标签)
+  - 删除依赖: `-.->|已移除|` (虚线箭头+文字标签)
+  - 原有依赖: `-->` (普通实线箭头)
+- **链接样式配置**: 使用 `linkStyle` 按索引设置箭头颜色和样式
+  - 新增依赖链接: 绿色虚线 `stroke:#4CAF50,stroke-width:2px,stroke-dasharray:5 5`
+  - 修改依赖链接: 橙色粗线 `stroke:#FF9800,stroke-width:3px`
+  - 删除依赖链接: 红色虚线 `stroke:#F44336,stroke-width:2px,stroke-dasharray:5 5`
+- **索引计数规则**: linkStyle 索引从 0 开始,按箭头声明顺序计数,必须在注释中标注索引范围避免错误
+- **样式优先级**: 使用 `classDef` 定义样式类,用 `class` 应用,避免 `style` 单独定义造成的覆盖问题
+- **链路完整性**: 确保所有变更节点及其上下游依赖关系都被标识出来,形成完整的变更链路
+- **目的**: 确保新代码引入的依赖关系符合架构规范,无循环依赖,AI 能清晰识别需要修改的依赖链路
+
+## 模块 5: 完整的新增/修改文件清单
+
+| 操作 | 文件路径 | 详细修改内容 (Code Spec) |
+| :--- | :--- | :--- |
+| 新建 | src/components/BatchActions.tsx | 1. 引入 Button; 2. 接收 `selectedIds` prop; 3. 点击触发 `onBatchDelete` |
+| 修改 | src/store/listStore.ts | 1. State 新增 `batchStatus`; 2. Action 新增 `executeBatchDelete` 调用 API |
+
+**要求**: 精确到文件路径,并说明具体的修改内容。
+
+## 模块 6: 潜在副作用与风险预警
+
+逐条列出,带 `[ ]` 复选框:
+
+- [ ] 是否会影响其他页面/组件复用同一接口或 Store?
+- [ ] 新增字段在旧数据缓存中是否会导致 undefined / 类型错误?
+- [ ] 错误处理链路是否覆盖新逻辑?
+- [ ] 权限控制是否需要补充?
+
+## 模块 7: 建议的测试用例
+
+至少 6 条,覆盖主路径 + 异常 + 边界:
+
+1. 正常批量操作流程
+2. 部分操作失败场景
+3. 网络异常处理
+4. 权限不足提示
+5. 空选择状态
+6. 最大批量数限制
+
+# 输出配置
+
+- **report-output-dir**: 报告输出目录,默认 `incspec/increments`
+- **文件命名**: `{feature}-increment-v{n}.md`
+  - `{feature}`: 功能名称,从旧需求快照文件名推断或由用户指定
+  - `{n}`: 版本号,扫描目标目录中同名前缀的文件,取最大版本号+1,若无则为 1
+- **示例**: 功能名称为 `batch-operation`,输出 `incspec/increments/batch-operation-increment-v1.md`
+- **目录创建**: 如目录不存在,需主动创建
+
+# 输出要求
+
+1. **静默输出**: 禁止在对话中输出完整的 Markdown 报告内容
+2. **文件写入**: 必须将完整报告(包含所有 7 大模块)直接写入文件
+3. **内容格式**: 写入文件的内容必须包含标题 `# 增量需求融合快照`
+4. **完成提示**: 文件写入完成后,仅在对话中回复:
+   > "✅ 增量需求融合快照 已生成并写入文件。请审核报告,确认无误后,请指示开始代码生成。"
+
+# 执行约束
+
+- **禁止修改业务代码**: 本次会话中,绝对禁止直接修改、创建或删除任何业务代码文件(如 `src/` 下的文件)
+- **设计而非实施**: 你是在设计代码,而不是编写代码。确保设计方案在逻辑上是通的(例如: 先有 Store 定义,再有组件调用)
+- **引用一致性**: 所有的 Nxx 编号在表格、时序图、依赖图中必须含义一致
+- **输出纯粹**: 不添加任何多余的解释或开场白,直接输出结果