6aspec 2.0.0-dev.17 → 2.0.0-dev.18

package/.6aspec/rules/brown/brown_proposal_sop.md

@@ -1,9 +1,13 @@
 # 棕地需求 - Proposal SOP
 
-创建需求提案 - 所有流程的第一阶段。
+创建需求提案
 
 **适用流程**：轻量级、标准级、完整级
 
+**流程定位**：
+- **轻量级**：第一阶段，基于需求描述（如果之前使用了探索模式并生成了 explore-summary.md，也会参考探索发现）
+- **标准级/完整级**：第三阶段，基于 understand 和 impact 的分析结果
+
 **输入**：`/6aspec:brown:proposal` 后可选需求名称。
 
 **步骤**
@@ -11,25 +15,29 @@
 1. **选择需求并检查状态**
 
    - 读取 `6aspecdoc/brown/<name>/status.json`
-   - 确认 `phases.proposal` 为 "pending"
+   - 根据 `flowDepth` 检查前置阶段：
+     - **轻量级**：确认 `phases.proposal` 为 "pending"
+     - **标准级/完整级**：确认 `phases.impact` 为 "done"，如果未完成提示先运行 `/6aspec:brown:impact`
    - 如果proposal已完成，提示使用 `/6aspec:brown:continue` 进入下一阶段
 
-2. **收集需求信息**
+2. **读取前置文档**
+
+   根据 `flowDepth` 读取不同的前置文档：
 
-   首先读取 `6aspecdoc/brown/<name>/requirement.md` 中的"原始需求"部分：
-   - 如果 `inputSource.type = "text"`：直接使用其中记录的需求描述。
-   - 如果 `inputSource.type = "file"`：读取记录的来源文件路径，获取完整需求内容。
+   **轻量级流程**：
+   - `6aspecdoc/brown/<name>/requirement.md` - 原始需求
+   - `6aspecdoc/brown/<name>/explore-summary.md` - 探索摘要（如果存在）
 
-   如果原始需求信息不足以生成提案，再询问用户补充：
-   - 为什么需要这个变更？（Why）
-   - 要做什么？（What）
-   - 预期影响是什么？（Impact）
+   **标准级/完整级流程**：
+   - `6aspecdoc/brown/<name>/requirement.md` - 原始需求
+   - `6aspecdoc/brown/<name>/artifacts/understanding.md` - 现状分析
+   - `6aspecdoc/brown/<name>/artifacts/impact-analysis.md` - 影响面分析
 
-3. **创建提案文档**
+3. **创建提案文档（OpenSpec 格式）**
 
    创建 `6aspecdoc/brown/<name>/artifacts/proposal.md`：
    ```markdown
-   # 需求提案：<需求标题>
+   # Proposal: <需求标题>
 
    > **需求**: <name>
    > **流程**: <flowDepth>
@@ -37,56 +45,52 @@
    > **状态**: ✅ 已完成
    > **创建时间**: <timestamp>
 
-   ## 为什么做（Why）
-
-   ### 业务背景
-   <业务背景描述>
-
-   ### 要解决的问题
-   <要解决的问题>
+   ## Why
 
-   ### 预期收益
-   <预期收益>
+   <1-2 sentences explaining the problem/opportunity>
 
-   ## 要做什么（What）
+   ## What Changes
 
-   ### 功能概述
-   <高层次的功能概述，描述核心能力>
+   <Bullet points of what will be different>
+   - <变更点1>
+   - <变更点2>
+   - <变更点3>
 
-   ### 核心能力
-   - 能力1：<简要描述>
-   - 能力2：<简要描述>
-   - 能力3：<简要描述>
+   ## Capabilities
 
-   ### 范围界定
-   **包含**：
-   - <包含的内容>
+   ### New Capabilities
+   - `<capability-name>`: <brief description>
+   - `<capability-name>`: <brief description>
 
-   **不包含**：
-   - <不包含的内容>
+   ### Modified Capabilities
+   <!-- If modifying existing behavior -->
+   - `<capability-name>`: <brief description>
 
-   ## 预期影响（Impact）
+   ## Impact
 
-   ### 技术影响
-   - 数据库：<影响描述>
-   - 后端代码：<影响描述>
-   - 前端代码：<影响描述>
-   - API接口：<影响描述>
+   **轻量级流程**（基于需求描述或 explore 摘要）：
+   - `<file-path>`: <what changes>
+   - `<file-path>`: <what changes>
 
-   ### 业务影响
-   - 用户体验：<影响描述>
-   - 业务流程：<影响描述>
+   **标准级/完整级流程**（基于 understanding 和 impact 分析）：
+   - `<file-path>`: <what changes>（来自 impact-analysis.md）
+   - `<file-path>`: <what changes>（来自 impact-analysis.md）
 
-   ### 风险评估
-   - 技术风险：<风险描述>
-   - 业务风险：<风险描述>
-
-   ## 下一步
+   ## Next Steps
 
    - 轻量级流程：运行 `/6aspec:brown:specs` 进行需求规格定义
-   - 标准级/完整级流程：运行 `/6aspec:brown:understand` 进行需求理解与现状分析
+   - 标准级/完整级流程：运行 `/6aspec:brown:specs` 进行需求规格定义
    ```
 
+   **注意**：
+   - Proposal 格式遵循 OpenSpec 规范，保持简洁
+   - Why 部分：1-2 句话说明问题或机会
+   - What Changes 部分：列出主要变更点
+   - Capabilities 部分：列出新增或修改的系统能力（每个 capability 将对应一个 spec 文件）
+   - Impact 部分：列出受影响的文件和简要描述
+   - 轻量级流程的 Impact 基于需求描述或 explore 摘要（高层次评估）
+   - 标准级/完整级流程的 Impact 基于 impact-analysis.md（详细分析的摘要）
+
 4. **更新状态**
 
    更新 `6aspecdoc/brown/<name>/status.json`：
@@ -110,38 +114,38 @@
    **标准级流程**：
    ```json
    {
-     "status": "understanding_pending",
+     "status": "specs_pending",
      "flowDepth": "standard",
      "phases": {
+       "understand": "done",
+       "impact": "done",
        "proposal": "done",
-       "understand": "pending",
-       "specs": "blocked",
-       "impact": "blocked",
+       "specs": "pending",
        "design": "blocked",
        "tasks": "blocked",
        "implement": "blocked"
      },
-     "artifacts": ["proposal.md"]
+     "artifacts": ["understanding.md", "impact-analysis.md", "proposal.md"]
    }
    ```
 
    **完整级流程**：
    ```json
    {
-     "status": "understanding_pending",
+     "status": "specs_pending",
      "flowDepth": "complete",
      "phases": {
+       "understand": "done",
+       "impact": "done",
        "proposal": "done",
-       "understand": "pending",
-       "specs": "blocked",
-       "impact": "blocked",
+       "specs": "pending",
        "design": "blocked",
        "tasks": "blocked",
        "implement": "blocked",
        "verify": "blocked",
        "review": "blocked"
      },
-     "artifacts": ["proposal.md"]
+     "artifacts": ["understanding.md", "impact-analysis.md", "proposal.md"]
    }
    ```
 
@@ -156,15 +160,12 @@
 ## Proposal 完成：<name>
 
 **流程**: 轻量级
-**进度**: 1/5 阶段完成
+**进度**: 1/4 阶段完成
 
 ### 提案概要
-- 业务目标：<简述>
-- 核心能力：<数量> 个
-- 预期影响：<简述>
-
-### 关键风险
-<列出关键风险>
+- Why: <简述>
+- What Changes: <数量> 项变更
+- Capabilities: <数量> 个能力
 
 ### 文档位置
 6aspecdoc/brown/<name>/artifacts/proposal.md
@@ -180,22 +181,19 @@
 ## Proposal 完成：<name>
 
 **流程**: 标准级
-**进度**: 1/7 阶段完成
+**进度**: 3/6 阶段完成
 
 ### 提案概要
-- 业务目标：<简述>
-- 核心能力：<数量> 个
-- 预期影响：<简述>
-
-### 关键风险
-<列出关键风险>
+- Why: <简述>
+- What Changes: <数量> 项变更
+- Capabilities: <数量> 个能力
 
 ### 文档位置
 6aspecdoc/brown/<name>/artifacts/proposal.md
 
 ### 下一步
 - 直接回复补充或修正提案内容 → 我会更新本阶段文档（proposal.md）
-- 运行 `/6aspec:brown:understand` → 进入需求理解与现状分析阶段
+- 运行 `/6aspec:brown:specs` → 进入需求规格定义阶段
 - 运行 `/6aspec:brown:continue` → 自动进入下一阶段
 ```
 
@@ -204,22 +202,19 @@
 ## Proposal 完成：<name>
 
 **流程**: 完整级
-**进度**: 1/9 阶段完成
+**进度**: 3/8 阶段完成
 
 ### 提案概要
-- 业务目标：<简述>
-- 核心能力：<数量> 个
-- 预期影响：<简述>
-
-### 关键风险
-<列出关键风险>
+- Why: <简述>
+- What Changes: <数量> 项变更
+- Capabilities: <数量> 个能力
 
 ### 文档位置
 6aspecdoc/brown/<name>/artifacts/proposal.md
 
 ### 下一步
 - 直接回复补充或修正提案内容 → 我会更新本阶段文档（proposal.md）
-- 运行 `/6aspec:brown:understand` → 进入需求理解与现状分析阶段
+- 运行 `/6aspec:brown:specs` → 进入需求规格定义阶段
 - 运行 `/6aspec:brown:continue` → 自动进入下一阶段
 ```
 

package/.6aspec/rules/brown/brown_rollback_sop.md

@@ -12,7 +12,7 @@
 **限制**：
 - 只能一级一级往上退，不允许跨节点
 - 只能回退已完成的阶段（状态为 "done"）
-- 不能回退第一个阶段（proposal）
+- 不能回退第一个阶段（轻量级流程：proposal，标准级/完整级流程：understand）
 - 不能从实施阶段回退（implement、verify、review），因为代码已修改，回退文档会导致文档和代码不一致
 - 只允许在分析阶段回退（proposal、understand、specs、impact、design、tasks）
 - 已归档的需求不能回退
@@ -43,25 +43,25 @@
    - ~~implement → tasks~~（禁止：代码已修改）
 
    **标准级流程（standard）**：
-   - understand → proposal
-   - specs → understand
-   - impact → specs
-   - design → impact
+   - impact → understand
+   - proposal → impact
+   - specs → proposal
+   - design → specs
    - tasks → design
    - ~~implement → tasks~~（禁止：代码已修改）
 
    **完整级流程（complete）**：
-   - understand → proposal
-   - specs → understand
-   - impact → specs
-   - design → impact
+   - impact → understand
+   - proposal → impact
+   - specs → proposal
+   - design → specs
    - tasks → design
    - ~~implement → tasks~~（禁止：代码已修改）
    - ~~verify → implement~~（禁止：代码已修改）
    - ~~review → verify~~（禁止：代码已修改）
 
    **边界情况**：
-   - 如果当前在第一个阶段（proposal），提示无法回退
+   - 如果当前在第一个阶段（轻量级流程：proposal，标准级/完整级流程：understand），提示无法回退
    - 如果当前在实施阶段（implement、verify、review），提示无法回退（代码已修改）
    - 如果所有阶段都是 pending，提示没有可回退的阶段
 
@@ -181,7 +181,7 @@
 **防护措施**
 - 必须确认需求未归档
 - 必须确认当前阶段已完成（状态为 "done"）
-- 不能回退第一个阶段（proposal）
+- 不能回退第一个阶段（轻量级流程：proposal，标准级/完整级流程：understand）
 - 不能从实施阶段回退（implement、verify、review）
 - 只允许在分析阶段回退（proposal、understand、specs、impact、design、tasks）
 - 必须用户确认后才能执行回退
@@ -192,7 +192,7 @@
 
 - 如果需求不存在，提示创建新需求
 - 如果需求已归档，提示先取消归档
-- 如果当前在第一个阶段（proposal），提示无法回退
+- 如果当前在第一个阶段（轻量级流程：proposal，标准级/完整级流程：understand），提示无法回退
 - 如果当前在实施阶段（implement、verify、review），提示无法回退，原因：代码已修改，回退文档会导致文档和代码不一致
 - 如果所有阶段都是 pending，提示没有可回退的阶段
 - 如果文件删除失败，提示错误信息但继续更新状态

package/.6aspec/rules/brown/brown_specs_sop.md

@@ -13,7 +13,7 @@
    - 读取 `6aspecdoc/brown/<name>/status.json`
    - 根据 `flowDepth` 检查前置阶段：
      - **轻量级**：确认 `phases.proposal` 为 "done"，如果未完成提示先运行 `/6aspec:brown:proposal`
-     - **标准级/完整级**：确认 `phases.understand` 为 "done"，如果未完成提示先运行 `/6aspec:brown:understand`
+     - **标准级/完整级**：确认 `phases.impact` 为 "done"，如果未完成提示先运行 `/6aspec:brown:impact`
 
 2. **读取前置文档**
 
@@ -27,6 +27,7 @@
    - `6aspecdoc/brown/<name>/requirement.md`
    - `6aspecdoc/brown/<name>/artifacts/proposal.md`
    - `6aspecdoc/brown/<name>/artifacts/understanding.md`
+   - `6aspecdoc/brown/<name>/artifacts/impact-analysis.md`
 
 3. **读取问题答案（仅标准级/完整级）**
 
@@ -40,17 +41,30 @@
 
 4. **定义功能需求**
 
-   基于需求理解和问题答案，明确定义系统应该具备的能力：
+   基于需求理解和问题答案，使用 Requirement + Scenario 格式明确定义系统应该具备的能力：
 
-   **功能需求格式**：
-   - FR-001: <功能描述>
-     - 输入：<输入内容>
-     - 输出：<输出内容>
-     - 业务规则：<业务规则>
-     - 验收标准：<验收标准>
+   **功能需求格式**（借鉴 OpenSpec 的 WHEN/THEN 格式）：
+   ```markdown
+   ### Requirement: <需求名称>
+
+   <需求描述，使用 SHALL/MUST 关键字表示强制性要求>
+
+   #### Scenario: <场景名称>
+
+   - **WHEN** <触发条件>
+   - **THEN** <预期结果>
+   - **AND** <额外的预期结果>（可选）
+
+   #### Scenario: <另一个场景名称>
+
+   - **WHEN** <触发条件>
+   - **THEN** <预期结果>
+   ```
 
    **拆解原则**：
-   - 每个功能需求应该是独立的、可验证的
+   - 每个 Requirement 应该是独立的、可验证的
+   - 每个 Scenario 使用 WHEN/THEN 格式，天然可测试
+   - 使用 SHALL/MUST 关键字表示强制性要求，SHOULD 表示推荐性要求
    - 功能需求应该从用户视角描述（做什么，而不是怎么做）
    - 避免技术实现细节（技术细节放在 design 阶段）
 
@@ -58,10 +72,26 @@
 
    明确系统应该满足的质量标准：
 
-   - NFR-001: 性能需求（响应时间、并发量等）
-   - NFR-002: 安全需求（权限控制、数据加密等）
-   - NFR-003: 可用性需求（易用性、可维护性等）
-   - NFR-004: 兼容性需求（浏览器、数据库等）
+   **非功能需求格式**：
+   ```markdown
+   ### 性能需求
+   - 响应时间 SHALL < 200ms
+   - 并发量 SHALL 支持 1000+ QPS
+
+   ### 安全需求
+   - 权限控制：只有管理员 SHALL 可以修改
+   - 数据加密：敏感数据 SHALL 加密存储
+
+   ### 可用性需求
+   - 易用性：界面 SHOULD 符合团队 UI 规范
+   - 可维护性：代码 SHOULD 遵循现有架构模式
+
+   ### 兼容性需求
+   - 浏览器：SHALL 支持 Chrome/Firefox/Safari 最新版本
+   - 数据库：SHALL 兼容现有数据库版本
+   ```
+
+   注意：使用 SHALL/MUST 表示强制性要求，SHOULD 表示推荐性要求
 
 6. **定义范围和约束**
 
@@ -76,15 +106,9 @@
    - 业务约束：<业务上的限制>
    - 时间约束：<时间上的限制>
 
-7. **定义验收标准**
-
-   明确如何验证需求已经实现：
-
-   - AC-001: <功能验收标准>
-   - AC-002: <非功能验收标准>
-   - AC-003: <数据验收标准>
+7. **创建需求规格文档**
 
-8. **创建需求规格文档**
+   注意：使用 WHEN/THEN 格式定义的 Scenario 本身就是验证标准，无需单独定义验收标准。
 
    创建 `6aspecdoc/brown/<name>/artifacts/specs.md`：
    ```markdown
@@ -101,10 +125,7 @@
    ### 1.1 业务目标
    <为什么需要这个功能>
 
-   ### 1.2 使用场景
-   <谁用、什么时候用、怎么用>
-
-   ### 1.3 范围定义
+   ### 1.2 范围定义
    **包含**：
    - <明确包含的功能>
 
@@ -113,65 +134,60 @@
 
    ## 2. 功能需求
 
-   ### FR-001: <功能名称>
-   **描述**：<功能描述>
+   ### Requirement: <需求名称>
+
+   <需求描述，使用 SHALL/MUST 关键字表示强制性要求>
+
+   #### Scenario: <场景名称>
+
+   - **WHEN** <触发条件>
+   - **THEN** <预期结果>
+   - **AND** <额外的预期结果>（可选）
 
-   **输入**：
-   - <输入内容>
+   #### Scenario: <另一个场景名称>
 
-   **输出**：
-   - <输出内容>
+   - **WHEN** <触发条件>
+   - **THEN** <预期结果>
 
-   **业务规则**：
-   - <业务规则1>
-   - <业务规则2>
+   ### Requirement: <另一个需求名称>
 
-   **验收标准**：
-   - <验收标准1>
-   - <验收标准2>
+   <需求描述>
 
-   ### FR-002: <功能名称>
-   ...
+   #### Scenario: <场景名称>
+
+   - **WHEN** <触发条件>
+   - **THEN** <预期结果>
 
    ## 3. 非功能需求
 
-   ### 3.1 性能需求
-   - NFR-001: <性能要求>
+   ### 性能需求
+   - 响应时间 SHALL < <具体值>
+   - 并发量 SHALL 支持 <具体值>
 
-   ### 3.2 安全需求
-   - NFR-002: <安全要求>
+   ### 安全需求
+   - 权限控制：<具体要求>
+   - 数据加密：<具体要求>
 
-   ### 3.3 可用性需求
-   - NFR-003: <可用性要求>
+   ### 可用性需求
+   - 易用性：<具体要求>
+   - 可维护性：<具体要求>
 
-   ### 3.4 兼容性需求
-   - NFR-004: <兼容性要求>
+   ### 兼容性需求
+   - 浏览器：SHALL 支持 <具体版本>
+   - 数据库：SHALL 兼容 <具体版本>
 
    ## 4. 约束条件
 
-   ### 4.1 技术约束
+   ### 技术约束
    - <技术上的限制>
 
-   ### 4.2 业务约束
+   ### 业务约束
    - <业务上的限制>
 
-   ### 4.3 时间约束
+   ### 时间约束
    - <时间上的限制>
 
-   ## 5. 验收标准
-
-   ### 5.1 功能验收
-   - AC-001: <功能验收标准>
-   - AC-002: <功能验收标准>
-
-   ### 5.2 非功能验收
-   - AC-003: <非功能验收标准>
-   - AC-004: <非功能验收标准>
-
-   ### 5.3 数据验收
-   - AC-005: <数据验收标准>
-
-   ## 6. 下一步
+   ## 5. 下一步
 
    - 轻量级流程：运行 `/6aspec:brown:design` 进行技术方案设计
    - 标准级/完整级流程：运行 `/6aspec:brown:impact` 进行影响面分析
@@ -200,38 +216,38 @@
    **标准级流程**：
    ```json
    {
-     "status": "impact_pending",
+     "status": "design_pending",
      "flowDepth": "standard",
      "phases": {
        "proposal": "done",
        "understand": "done",
+       "impact": "done",
        "specs": "done",
-       "impact": "pending",
-       "design": "blocked",
+       "design": "pending",
        "tasks": "blocked",
        "implement": "blocked"
      },
-     "artifacts": ["proposal.md", "understanding.md", "specs.md"]
+     "artifacts": ["proposal.md", "understanding.md", "impact-analysis.md", "specs.md"]
    }
    ```
 
    **完整级流程**：
    ```json
    {
-     "status": "impact_pending",
+     "status": "design_pending",
      "flowDepth": "complete",
      "phases": {
        "proposal": "done",
        "understand": "done",
+       "impact": "done",
        "specs": "done",
-       "impact": "pending",
-       "design": "blocked",
+       "design": "pending",
        "tasks": "blocked",
        "implement": "blocked",
        "verify": "blocked",
        "review": "blocked"
      },
-     "artifacts": ["proposal.md", "understanding.md", "specs.md"]
+     "artifacts": ["proposal.md", "understanding.md", "impact-analysis.md", "specs.md"]
    }
    ```
 
@@ -247,12 +263,12 @@
 **进度**: 2/5 阶段完成
 
 ### 需求概要
-- 功能需求：<数量> 个
-- 非功能需求：<数量> 个
-- 验收标准：<数量> 个
+- 功能需求：<数量> 个 Requirement
+- 测试场景：<数量> 个 Scenario
+- 非功能需求：<数量> 项
 
 ### 核心功能
-<列出 2-3 个核心功能需求>
+<列出 2-3 个核心 Requirement>
 
 ### 关键约束
 <列出 1-2 个关键约束>
@@ -271,15 +287,15 @@
 ## Specs 完成：<name>
 
 **流程**: 标准级
-**进度**: 3/7 阶段完成
+**进度**: 4/6 阶段完成
 
 ### 需求概要
-- 功能需求：<数量> 个
-- 非功能需求：<数量> 个
-- 验收标准：<数量> 个
+- 功能需求：<数量> 个 Requirement
+- 测试场景：<数量> 个 Scenario
+- 非功能需求：<数量> 项
 
 ### 核心功能
-<列出 2-3 个核心功能需求>
+<列出 2-3 个核心 Requirement>
 
 ### 关键约束
 <列出 1-2 个关键约束>
@@ -289,7 +305,7 @@
 
 ### 下一步
 - 直接回复补充或修正需求规格 → 我会更新本阶段文档（specs.md）
-- 运行 `/6aspec:brown:impact` → 进入影响面分析阶段
+- 运行 `/6aspec:brown:design` → 进入技术方案设计阶段
 - 运行 `/6aspec:brown:continue` → 自动进入下一阶段
 ```
 
@@ -298,15 +314,15 @@
 ## Specs 完成：<name>
 
 **流程**: 完整级
-**进度**: 3/9 阶段完成
+**进度**: 4/8 阶段完成
 
 ### 需求概要
-- 功能需求：<数量> 个
-- 非功能需求：<数量> 个
-- 验收标准：<数量> 个
+- 功能需求：<数量> 个 Requirement
+- 测试场景：<数量> 个 Scenario
+- 非功能需求：<数量> 项
 
 ### 核心功能
-<列出 2-3 个核心功能需求>
+<列出 2-3 个核心 Requirement>
 
 ### 关键约束
 <列出 1-2 个关键约束>
@@ -316,7 +332,7 @@
 
 ### 下一步
 - 直接回复补充或修正需求规格 → 我会更新本阶段文档（specs.md）
-- 运行 `/6aspec:brown:impact` → 进入影响面分析阶段
+- 运行 `/6aspec:brown:design` → 进入技术方案设计阶段
 - 运行 `/6aspec:brown:continue` → 自动进入下一阶段
 ```
 
@@ -333,7 +349,9 @@
 - 根据flowDepth检查不同的前置阶段：
   - 轻量级：必须先完成proposal阶段
   - 标准级/完整级：必须先完成understand阶段
+- 功能需求必须使用 Requirement + Scenario (WHEN/THEN) 格式
+- 使用 SHALL/MUST 表示强制性要求，SHOULD 表示推荐性要求
+- 每个 Scenario 必须可测试、可验证
 - 功能需求必须从用户视角描述，避免技术实现细节
-- 验收标准必须具体、可验证
 - 需求问题的答案应该体现在功能需求定义中，而不是单独列出
 - specs的详细程度保持一致，不区分流程深度