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

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

@@ -18,45 +18,88 @@
    根据 `flowDepth` 读取不同的前置文档：
 
    **轻量级流程**：
-   - `6aspecdoc/brown/<name>/requirement.md`
    - `6aspecdoc/brown/<name>/artifacts/proposal.md`
    - `6aspecdoc/brown/<name>/artifacts/specs.md`
 
    **标准级/完整级流程**：
-   - `6aspecdoc/brown/<name>/requirement.md`
-   - `6aspecdoc/brown/<name>/artifacts/proposal.md`
-   - `6aspecdoc/brown/<name>/artifacts/understanding.md`
    - `6aspecdoc/brown/<name>/artifacts/specs.md`
+   - `6aspecdoc/brown/<name>/artifacts/understanding.md`
    - `6aspecdoc/brown/<name>/artifacts/impact-analysis.md`
 
-3. **设计数据库变更方案**
+3. **按需探索代码库（可选）**
+
+   **触发条件**：
+   - 需要了解现有架构模式、技术选型
+   - 需要了解现有的数据库设计模式（如字段类型、索引策略）
+   - 需要了解现有的前端组件和交互模式
+   - 需要了解现有的测试框架和测试模式
+   - 用户明确要求探索（例如："先了解一下现有架构"）
+   - 信息不足，需要参考现有代码才能设计准确的技术方案
+
+   **探索方式**：
+
+   a. **简单搜索**（使用Grep/Glob工具）：
+   ```bash
+   # 搜索相关Service类的实现模式
+   rg "class.*Service" --type java -g "*Service.java"
+
+   # 搜索相关Controller类的实现模式
+   rg "class.*Controller" --type java -g "*Controller.java"
+
+   # 搜索配置文件
+   rg "spring.datasource|mybatis" --type yaml -g "*.yml"
+
+   # 搜索测试框架使用
+   rg "@Test|@SpringBootTest" --type java -g "*Test.java"
+
+   # 搜索前端组件
+   rg "export.*component" --type typescript -g "*.tsx"
+   ```
+
+   b. **复杂探索**（使用Task工具调用Explore agent）：
+   - 当需要深入理解现有架构模式时
+   - 当需要跨多个文件理解技术选型时
+   - 当需要了解复杂的集成方案时
+
+   **探索结果处理**：
+   - 探索发现直接用于技术方案设计
+   - 不生成独立文档
+   - 在design.md中可以标注"参考现有实现：<文件路径>"
+
+   **注意**：
+   - 探索是可选的，不是强制的
+   - 如果前置文档（specs、understanding、impact）已经提供了足够信息，可以跳过探索
+   - 探索应该聚焦、快速，避免过度探索
+   - 重点关注架构模式、技术选型、实现风格，而不是具体业务逻辑
+
+4. **设计数据库变更方案**
 
    - 字段名、类型、约束
    - 默认值和历史数据处理
    - 索引建议
    - 数据迁移脚本（如需要）
 
-4. **设计代码实现方案**
+5. **设计代码实现方案**
 
    - 实体类字段添加（含注解）
    - 业务逻辑实现（含关键代码示例）
    - 校验逻辑（必填、值域、约束）
    - 错误提示（使用多语言资源）
 
-5. **设计前端 UI 方案**
+6. **设计前端 UI 方案**
 
    - 各页面字段状态（可编辑/只读/隐藏）
    - 交互逻辑（下拉选择、提示信息）
    - 错误提示
    - 多语言支持
 
-6. **设计测试方案**
+7. **设计测试方案**
 
    - 单元测试（函数级别）
    - 集成测试（流程级别）
    - 数据一致性验证（SQL 验证）
 
-7. **架构决策记录（涉及架构决策时创建）**
+8. **架构决策记录（涉及架构决策时创建）**
 
    如果需求涉及重要的架构决策（如技术选型、数据模型设计、集成方案等），创建 ADR：
 
@@ -92,7 +135,7 @@
    <如何验证这个决策是正确的>
    ```
 
-8. **技术债务识别**
+9. **技术债务识别**
 
    识别实现过程中可能引入的技术债务：
 
@@ -100,7 +143,7 @@
    |--------|------|------|------|----------|--------|
    | DEBT-001 | 临时的硬编码逻辑 | 代码质量 | 中 | 2人日 | P1 |
 
-9. **创建技术方案文档**
+10. **创建技术方案文档**
 
    创建 `6aspecdoc/brown/<name>/artifacts/design.md`
 
@@ -140,6 +183,13 @@
     }
     ```
 
+   同时更新 `6aspecdoc/brown/<name>/requirement.md`：
+   - 更新"状态"字段为 `📋 Tasks 待开始`
+   - 更新"最后修改"时间戳为 `<timestamp>`
+   - 更新"当前阶段"为 `Design - 技术方案设计（已完成）`
+   - 更新"下一步操作"为 `运行 /6aspec:brown:tasks 继续下一阶段`
+   - 在"进度概览"中标记 Design 阶段为已完成 `[x]`
+
 **输出**
 
 根据 `flowDepth` 显示不同的输出信息：

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

@@ -21,10 +21,10 @@
 2. **读取前置文档**
 
    读取以下文档获取上下文：
-   - `6aspecdoc/brown/<name>/requirement.md` - 需求描述
+   - `6aspecdoc/brown/<name>/artifacts/original-requirement.md` - 原始需求
    - `6aspecdoc/brown/<name>/artifacts/understanding.md` - 现状分析（含业务规则答案）
 
-   **注意**：Impact 阶段不依赖 proposal，基于需求描述和现状分析来评估影响面。
+   **注意**：Impact 阶段不依赖 proposal，基于原始需求和现状分析来评估影响面。
 
 3. **执行影响面分析**
 
@@ -274,6 +274,13 @@
    }
    ```
 
+   同时更新 `6aspecdoc/brown/<name>/requirement.md`：
+   - 更新"状态"字段为 `📋 Proposal 待开始`
+   - 更新"最后修改"时间戳为 `<timestamp>`
+   - 更新"当前阶段"为 `Impact - 影响面分析（已完成）`
+   - 更新"下一步操作"为 `运行 /6aspec:brown:proposal 继续下一阶段`
+   - 在"进度概览"中标记 Impact 阶段为已完成 `[x]`
+
 8. **停止并等待用户指令**
 
 **输出**

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

@@ -73,6 +73,35 @@
    mkdir -p "6aspecdoc/brown/<name>/tasks"
    ```
 
+   创建原始需求文件 `6aspecdoc/brown/<name>/artifacts/original-requirement.md`：
+
+   **情况A：直接文字描述（inputSource.type = "text"）**：
+   ```markdown
+   # 原始需求
+
+   <用户输入的原始需求描述，原文记录，不做加工>
+
+   ---
+
+   > **需求来源**: text
+   > **创建时间**: <timestamp>
+   ```
+
+   **情况B：文件引用（inputSource.type = "file"）**：
+   ```markdown
+   # 原始需求
+
+   > **需求来源文件**: `<文件路径>`
+   >
+   > 完整需求内容请参考上述文件。
+
+   ---
+
+   > **需求来源**: file
+   > **来源文件**: <文件路径>
+   > **创建时间**: <timestamp>
+   ```
+
    创建状态文件 `6aspecdoc/brown/<name>/status.json`：
 
    **注意**：所有时间戳必须使用东八区（北京时间）格式：`yyyy-MM-dd HH:mm:ss`（例如：`2026-02-20 12:36:23`）
@@ -164,25 +193,14 @@
 
    ## 原始需求
 
-   <!-- 根据输入类型选择以下其一 -->
-
-   <!-- 情况A：直接文字描述（inputSource.type = "text"） -->
-   <用户输入的原始需求描述，原文记录，不做加工>
-
-   <!-- 情况B：文件引用（inputSource.type = "file"） -->
-   > **需求来源文件**：`<文件路径>`
-   >
-   > 完整需求内容请参考上述文件。
+   详见：[artifacts/original-requirement.md](artifacts/original-requirement.md)
 
-   ## 快速导航
+   ## 当前阶段
 
-   **需求详情**：
-   - 轻量级流程：[proposal.md](artifacts/proposal.md) - 需求提案（Why、What、Impact）
-   - 标准级/完整级流程：[understanding.md](artifacts/understanding.md) - 需求理解与现状分析
+   <当前阶段名称>
 
-   **当前阶段**：<当前阶段名称>
+   ## 下一步操作
 
-   **下一步操作**：
    - 运行 `/6aspec:brown:<next-command>` 继续下一阶段
    - 或运行 `/6aspec:brown:continue` 自动进入下一阶段
 

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

@@ -25,15 +25,109 @@
    根据 `flowDepth` 读取不同的前置文档：
 
    **轻量级流程**：
-   - `6aspecdoc/brown/<name>/requirement.md` - 原始需求
+   - `6aspecdoc/brown/<name>/artifacts/original-requirement.md` - 原始需求
    - `6aspecdoc/brown/<name>/explore-summary.md` - 探索摘要（如果存在）
 
    **标准级/完整级流程**：
-   - `6aspecdoc/brown/<name>/requirement.md` - 原始需求
+   - `6aspecdoc/brown/<name>/artifacts/original-requirement.md` - 原始需求
    - `6aspecdoc/brown/<name>/artifacts/understanding.md` - 现状分析
    - `6aspecdoc/brown/<name>/artifacts/impact-analysis.md` - 影响面分析
 
-3. **创建提案文档（OpenSpec 格式）**
+3. **执行轻量级探索并识别待明确问题**（仅轻量级流程）
+
+   **触发条件**：`flowDepth` 为 "lightweight" **且满足以下任一条件**：
+   - 不存在 `explore-summary.md` **且** 对话上下文中没有探索内容
+   - 用户明确要求探索（例如："先了解一下现有实现"、"需要探索代码库"）
+
+   **上下文识别**：
+
+   在执行探索前，先检查是否已有探索内容：
+
+   a. **检查explore-summary.md**：
+   - 如果存在 `6aspecdoc/brown/<name>/explore-summary.md`，读取它
+   - 除非用户明确要求重新探索，否则使用已有的探索摘要
+
+   b. **检查对话上下文**：
+   - 检查对话历史中是否包含探索内容（用户之前执行了 `/6aspec:brown:explore` 命令）
+   - 即使没有生成explore-summary.md文件，探索内容仍在对话上下文中
+   - 如果发现对话上下文中有探索内容，可以直接利用这些信息，不需要重新探索
+
+   c. **判断是否需要执行新的探索**：
+   - 如果既没有explore-summary.md，也没有对话上下文中的探索内容 → 执行轻量级探索
+   - 如果用户明确要求探索（即使已有探索内容） → 执行轻量级探索
+   - 如果已有探索内容（explore-summary.md或对话上下文）且用户未明确要求 → 跳过探索，直接使用已有内容
+
+   **步骤**：
+
+   a. **执行轻量级探索**（如果需要）
+
+   从需求描述中提取关键词（实体名、功能名、业务术语），然后执行快速搜索：
+
+   ```bash
+   # 搜索相关实体类
+   rg "class.*<关键词>.*Entity" --type java -g "*Entity.java"
+
+   # 搜索相关服务类
+   rg "class.*<关键词>.*Service" --type java -g "*Service.java"
+
+   # 搜索相关Controller类
+   rg "class.*<关键词>.*Controller" --type java -g "*Controller.java"
+
+   # 搜索关键业务逻辑
+   rg "<关键方法名>" --type java -C 3
+   ```
+
+   识别受影响的核心文件（3-5个），快速阅读关键代码片段。
+
+   b. **识别待明确问题**
+
+   基于探索结果（explore-summary.md、对话上下文中的探索内容、或刚刚执行的轻量级探索）和需求描述，识别不清楚的地方，生成待明确问题清单：
+
+   **问题类型**：
+   - 字段设计问题（名称、类型、必填、默认值、值域）
+   - 业务规则问题（是否可修改、是否继承、是否同步）
+   - 权限和统计问题（权限控制、统计报表）
+   - 集成和兼容问题（与其他模块的集成、数据迁移）
+
+   **问题数量**：2-5个最重要的问题（保持轻量）
+
+   c. **询问用户**
+
+   如果有待明确问题，展示问题清单并等待用户回答：
+
+   ```
+   ## 需要明确的问题
+
+   基于代码库探索，发现以下问题需要明确：
+
+   ### 字段设计
+   1. <问题1>
+   2. <问题2>
+
+   ### 业务规则
+   3. <问题3>
+   4. <问题4>
+
+   请回答上述问题，我会基于你的回答生成proposal。
+   ```
+
+   **等待用户回答**，不要自动进入下一步。
+
+   d. **处理用户回答**
+
+   当用户回答问题后：
+   - 记录用户的回答（用于proposal生成）
+   - 继续执行步骤4（创建提案文档）
+
+   **注意**：
+   - 探索结果和用户回答不生成独立文档，直接用于proposal生成
+   - 如果没有待明确问题，直接跳过询问步骤，继续生成proposal
+   - 优先使用explore-summary.md（如果存在且用户未明确要求重新探索）
+   - 其次利用对话上下文中的探索内容（如果用户之前执行了explore命令）
+   - 最后才执行新的轻量级探索（如果既没有explore-summary.md也没有对话上下文中的探索内容）
+   - 即使已有探索内容，如果用户明确要求探索，也应该执行新的探索
+
+4. **创建提案文档（OpenSpec 格式）**
 
    创建 `6aspecdoc/brown/<name>/artifacts/proposal.md`：
    ```markdown
@@ -88,10 +182,11 @@
    - What Changes 部分：列出主要变更点
    - Capabilities 部分：列出新增或修改的系统能力（每个 capability 将对应一个 spec 文件）
    - Impact 部分：列出受影响的文件和简要描述
-   - 轻量级流程的 Impact 基于需求描述或 explore 摘要（高层次评估）
+   - 轻量级流程的 Impact 基于需求描述、explore 摘要或轻量级探索结果（高层次评估）
    - 标准级/完整级流程的 Impact 基于 impact-analysis.md（详细分析的摘要）
+   - 如果轻量级流程在步骤3中询问了用户问题，基于用户的回答生成proposal
 
-4. **更新状态**
+5. **更新状态**
 
    更新 `6aspecdoc/brown/<name>/status.json`：
 
@@ -149,13 +244,51 @@
    }
    ```
 
-5. **停止并等待用户指令**
+   同时更新 `6aspecdoc/brown/<name>/requirement.md`：
+   - 更新"状态"字段为 `📋 Specs 待开始`
+   - 更新"最后修改"时间戳为 `<timestamp>`
+   - 更新"当前阶段"为 `Proposal - 需求提案（已完成）`
+   - 更新"下一步操作"为 `运行 /6aspec:brown:specs 继续下一阶段`
+   - 在"进度概览"中标记 Proposal 阶段为已完成 `[x]`
+
+6. **停止并等待用户指令**
 
 **输出**
 
-根据 `flowDepth` 显示不同的输出信息：
+根据 `flowDepth` 和执行阶段显示不同的输出信息：
+
+**轻量级流程 - 待明确问题阶段**（如果步骤3中发现有待明确问题）：
+```
+## 需要明确的问题：<name>
+
+**流程**: 轻量级
+**阶段**: Proposal（探索中）
+
+### 代码库探索结果
+- 相关实体类：<数量>
+- 相关服务类：<数量>
+- 受影响文件：<数量>
+
+### 待明确问题
+
+基于代码库探索，发现以下问题需要明确：
+
+#### 字段设计
+1. <问题1>
+2. <问题2>
 
-**轻量级流程**：
+#### 业务规则
+3. <问题3>
+4. <问题4>
+
+#### 其他
+5. <问题5>
+
+### 下一步
+请回答上述问题，我会基于你的回答生成proposal。
+```
+
+**轻量级流程 - Proposal完成**：
 ```
 ## Proposal 完成：<name>
 
@@ -233,3 +366,13 @@
 - 提案应聚焦高层次的业务目标和核心能力，不包含详细的功能需求（FR）和验收标准（AC）
 - 详细的功能需求和验收标准应该在specs阶段定义
 - 风险评估不能省略
+
+**轻量级流程的特殊防护措施**：
+- 如果没有explore-summary.md，必须执行轻量级探索（步骤3）
+- 轻量级探索应该快速、聚焦，只搜索关键实体类、服务类和受影响文件
+- 轻量级探索不生成独立文档，探索结果直接用于proposal生成
+- 如果探索过程中发现待明确问题，必须询问用户，不能基于假设生成proposal
+- 待明确问题数量应该控制在2-5个，保持轻量（与标准级/完整级的5-10个问题相比）
+- 如果没有待明确问题，可以直接生成proposal
+- 不要在轻量级流程中执行过于深入的分析（如绘制ERD图、流程图等），这些应该在标准级/完整级流程中完成
+- 轻量级探索的目标是"快速理解现有实现"，而不是"深入分析系统架构"

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

@@ -20,11 +20,9 @@
    根据 `flowDepth` 读取不同的前置文档：
 
    **轻量级流程**：
-   - `6aspecdoc/brown/<name>/requirement.md`
    - `6aspecdoc/brown/<name>/artifacts/proposal.md`
 
    **标准级/完整级流程**：
-   - `6aspecdoc/brown/<name>/requirement.md`
    - `6aspecdoc/brown/<name>/artifacts/proposal.md`
    - `6aspecdoc/brown/<name>/artifacts/understanding.md`
    - `6aspecdoc/brown/<name>/artifacts/impact-analysis.md`
@@ -39,38 +37,125 @@
 
    注意：specs 阶段不再提出新问题，所有需求问题应该在 understand 阶段提出并收集。
 
-4. **定义功能需求**
+4. **按需探索代码库（可选）**
 
-   基于需求理解和问题答案，使用 Requirement + Scenario 格式明确定义系统应该具备的能力：
+   **触发条件**：
+   - 需要了解现有字段定义、验证逻辑、Scenario实现方式
+   - 需要了解现有的非功能需求实现（如权限控制、性能优化）
+   - 用户明确要求探索（例如："先了解一下现有实现"）
+   - 信息不足，需要参考现有代码才能定义准确的需求规格
 
-   **功能需求格式**（借鉴 OpenSpec 的 WHEN/THEN 格式）：
+   **探索方式**：
+
+   a. **简单搜索**（使用Grep/Glob工具）：
+   ```bash
+   # 搜索相关Entity类的字段定义
+   rg "private.*<字段名>" --type java -g "*Entity.java" -C 3
+
+   # 搜索相关验证注解
+   rg "@NotNull|@NotEmpty|@Valid" --type java -g "*Entity.java"
+
+   # 搜索现有的测试场景
+   rg "test.*<功能名>" --type java -g "*Test.java"
+   ```
+
+   b. **复杂探索**（使用Task工具调用Explore agent）：
+   - 当需要深入理解现有架构模式时
+   - 当需要跨多个文件理解业务逻辑时
+
+   **探索结果处理**：
+   - 探索发现直接用于需求规格定义
+   - 不生成独立文档
+   - 在specs.md中可以标注"基于现有实现：<文件路径>"
+
+   **注意**：
+   - 探索是可选的，不是强制的
+   - 如果前置文档（proposal、understanding、impact）已经提供了足够信息，可以跳过探索
+   - 探索应该聚焦、快速，避免过度探索
+
+5. **基于 Capabilities 定义功能需求**
+
+   从 proposal.md 中读取 Capabilities 列表，按 Capability 组织功能需求：
+
+   **功能需求格式**（按 Capability 组织）：
    ```markdown
-   ### Requirement: <需求名称>
+   ### Capability: <capability-name> [ADD/MODIFY/REMOVE]
+
+   <Capability 描述，说明这个能力是做什么的>
+
+   #### Requirement: <需求名称>
 
    <需求描述，使用 SHALL/MUST 关键字表示强制性要求>
 
-   #### Scenario: <场景名称>
+   ##### Scenario: <场景名称>
 
    - **WHEN** <触发条件>
    - **THEN** <预期结果>
    - **AND** <额外的预期结果>（可选）
 
-   #### Scenario: <另一个场景名称>
+   ##### Scenario: <另一个场景名称>
+
+   - **WHEN** <触发条件>
+   - **THEN** <预期结果>
+
+   #### Requirement: <另一个需求名称>
+
+   <需求描述>
+
+   ##### Scenario: <场景名称>
 
    - **WHEN** <触发条件>
    - **THEN** <预期结果>
    ```
 
-   **拆解原则**：
+5. **基于 Capabilities 定义功能需求**
+
+   从 proposal.md 中读取 Capabilities 列表，按 Capability 组织功能需求：
+
+   **功能需求格式**（按 Capability 组织）：
+   ```markdown
+   ### Capability: <capability-name> [ADD/MODIFY/REMOVE]
+
+   <Capability 描述，说明这个能力是做什么的>
+
+   #### Requirement: <需求名称>
+
+   <需求描述，使用 SHALL/MUST 关键字表示强制性要求>
+
+   ##### Scenario: <场景名称>
+
+   - **WHEN** <触发条件>
+   - **THEN** <预期结果>
+   - **AND** <额外的预期结果>（可选）
+
+   ##### Scenario: <另一个场景名称>
+
+   - **WHEN** <触发条件>
+   - **THEN** <预期结果>
+
+   #### Requirement: <另一个需求名称>
+
+   <需求描述>
+
+   ##### Scenario: <场景名称>
+
+   - **WHEN** <触发条件>
+   - **THEN** <预期结果>
+   ```
+
+   **组织原则**：
+   - 每个 Capability 对应 proposal.md 中的一个能力
+   - 在 Capability 级别标识变更类型：[ADD]（新增）、[MODIFY]（修改）、[REMOVE]（移除）
+   - 每个 Capability 下包含多个 Requirements
    - 每个 Requirement 应该是独立的、可验证的
    - 每个 Scenario 使用 WHEN/THEN 格式，天然可测试
    - 使用 SHALL/MUST 关键字表示强制性要求，SHOULD 表示推荐性要求
    - 功能需求应该从用户视角描述（做什么，而不是怎么做）
    - 避免技术实现细节（技术细节放在 design 阶段）
 
-5. **定义非功能需求**
+6. **定义非功能需求（可选）**
 
-   明确系统应该满足的质量标准：
+   明确系统应该满足的质量标准。**注意：只写有明确要求的项，不要为了完整性而写空泛内容。**
 
    **非功能需求格式**：
    ```markdown
@@ -91,22 +176,41 @@
    - 数据库：SHALL 兼容现有数据库版本
    ```
 
-   注意：使用 SHALL/MUST 表示强制性要求，SHOULD 表示推荐性要求
+   **注意事项**：
+   - 使用 SHALL/MUST 表示强制性要求，SHOULD 表示推荐性要求
+   - 如果某个类别（如性能、安全）没有明确要求，可以省略该小节
+   - 避免写"遵循最佳实践"等空泛描述
 
-6. **定义范围和约束**
+7. **定义范围边界（可选）**
 
-   明确做什么、不做什么：
+   明确做什么、不做什么，以及关键约束：
 
-   **范围定义**：
-   - 包含：<明确包含的功能>
-   - 不包含：<明确不包含的功能>
+   **范围边界格式**：
+   ```markdown
+   ## 1. 范围边界
+
+   **本次实现**：
+   - <明确包含的核心功能>
+   - <明确包含的核心功能>
+
+   **明确不包含**：
+   - <明确排除的功能或场景>
+   - <明确排除的功能或场景>
+
+   **关键约束**（可选）：
+   - <技术约束：如必须使用某技术栈、兼容某版本>
+   - <业务约束：如必须满足某业务规则>
+   - <时间约束：如必须在某时间前完成>
+   ```
 
-   **约束条件**：
-   - 技术约束：<技术上的限制>
-   - 业务约束：<业务上的限制>
-   - 时间约束：<时间上的限制>
+   **注意事项**：
+   - 范围边界用于明确需求边界，避免范围蔓延
+   - "本次实现"应该简洁列出核心功能点
+   - "明确不包含"用于排除容易混淆的功能
+   - "关键约束"只写有实际影响的约束，如果没有可以省略
+   - 如果范围已经很明确（如简单的 bug 修复），整个章节可以省略
 
-7. **创建需求规格文档**
+8. **创建需求规格文档**
 
    注意：使用 WHEN/THEN 格式定义的 Scenario 本身就是验证标准，无需单独定义验收标准。
 
@@ -115,51 +219,74 @@
    # 需求规格定义
 
    > **需求**: <name>
+   > **基于提案**: proposal.md
    > **流程**: <flowDepth>
    > **阶段**: Specs
    > **状态**: ✅ 已完成
    > **完成时间**: <timestamp>
 
-   ## 1. 需求概述
+   ## 1. 范围边界
 
-   ### 1.1 业务目标
-   <为什么需要这个功能>
+   **本次实现**：
+   - <明确包含的核心功能>
+   - <明确包含的核心功能>
 
-   ### 1.2 范围定义
-   **包含**：
-   - <明确包含的功能>
+   **明确不包含**：
+   - <明确排除的功能或场景>
+   - <明确排除的功能或场景>
 
-   **不包含**：
-   - <明确不包含的功能>
+   **关键约束**（可选）：
+   - <技术约束：如必须使用某技术栈、兼容某版本>
+   - <业务约束：如必须满足某业务规则>
+   - <时间约束：如必须在某时间前完成>
 
    ## 2. 功能需求
 
-   ### Requirement: <需求名称>
+   ### Capability: <capability-name> [ADD]
+
+   <Capability 描述，说明这个能力是做什么的>
+
+   #### Requirement: <需求名称>
 
    <需求描述，使用 SHALL/MUST 关键字表示强制性要求>
 
-   #### Scenario: <场景名称>
+   ##### Scenario: <场景名称>
 
    - **WHEN** <触发条件>
    - **THEN** <预期结果>
    - **AND** <额外的预期结果>（可选）
 
-   #### Scenario: <另一个场景名称>
+   ##### Scenario: <另一个场景名称>
+
+   - **WHEN** <触发条件>
+   - **THEN** <预期结果>
+
+   #### Requirement: <另一个需求名称>
+
+   <需求描述>
+
+   ##### Scenario: <场景名称>
 
    - **WHEN** <触发条件>
    - **THEN** <预期结果>
 
-   ### Requirement: <另一个需求名称>
+   ### Capability: <another-capability-name> [MODIFY]
+
+   <Capability 描述>
+
+   #### Requirement: <需求名称>
 
    <需求描述>
 
-   #### Scenario: <场景名称>
+   ##### Scenario: <场景名称>
 
    - **WHEN** <触发条件>
    - **THEN** <预期结果>
 
    ## 3. 非功能需求
 
+   > **注意**：只写有明确要求的项，如果某个类别没有明确要求，可以省略该小节。
+
    ### 性能需求
    - 响应时间 SHALL < <具体值>
    - 并发量 SHALL 支持 <具体值>
@@ -176,21 +303,9 @@
    - 浏览器：SHALL 支持 <具体版本>
    - 数据库：SHALL 兼容 <具体版本>
 
-   ## 4. 约束条件
+   ## 4. 下一步
 
-   ### 技术约束
-   - <技术上的限制>
-
-   ### 业务约束
-   - <业务上的限制>
-
-   ### 时间约束
-   - <时间上的限制>
-
-   ## 5. 下一步
-
-   - 轻量级流程：运行 `/6aspec:brown:design` 进行技术方案设计
-   - 标准级/完整级流程：运行 `/6aspec:brown:impact` 进行影响面分析
+   运行 `/6aspec:brown:design` 进行技术方案设计
    ```
 
 9. **更新状态**
@@ -251,6 +366,13 @@
    }
    ```
 
+   同时更新 `6aspecdoc/brown/<name>/requirement.md`：
+   - 更新"状态"字段为 `📋 Design 待开始`
+   - 更新"最后修改"时间戳为 `<timestamp>`
+   - 更新"当前阶段"为 `Specs - 需求规格定义（已完成）`
+   - 更新"下一步操作"为 `运行 /6aspec:brown:design 继续下一阶段`
+   - 在"进度概览"中标记 Specs 阶段为已完成 `[x]`
+
 **输出**
 
 根据 `flowDepth` 显示不同的输出信息：
@@ -263,15 +385,13 @@
 **进度**: 2/5 阶段完成
 
 ### 需求概要
-- 功能需求：<数量> 个 Requirement
-- 测试场景：<数量> 个 Scenario
+- Capabilities：<数量> 个能力
+- Requirements：<数量> 个需求
+- Scenarios：<数量> 个测试场景
 - 非功能需求：<数量> 项
 
-### 核心功能
-<列出 2-3 个核心 Requirement>
-
-### 关键约束
-<列出 1-2 个关键约束>
+### 核心 Capabilities
+<列出 2-3 个核心 Capability 及其变更类型（ADD/MODIFY/REMOVE）>
 
 ### 文档位置
 6aspecdoc/brown/<name>/artifacts/specs.md
@@ -290,15 +410,13 @@
 **进度**: 4/6 阶段完成
 
 ### 需求概要
-- 功能需求：<数量> 个 Requirement
-- 测试场景：<数量> 个 Scenario
+- Capabilities：<数量> 个能力
+- Requirements：<数量> 个需求
+- Scenarios：<数量> 个测试场景
 - 非功能需求：<数量> 项
 
-### 核心功能
-<列出 2-3 个核心 Requirement>
-
-### 关键约束
-<列出 1-2 个关键约束>
+### 核心 Capabilities
+<列出 2-3 个核心 Capability 及其变更类型（ADD/MODIFY/REMOVE）>
 
 ### 文档位置
 6aspecdoc/brown/<name>/artifacts/specs.md
@@ -317,15 +435,13 @@
 **进度**: 4/8 阶段完成
 
 ### 需求概要
-- 功能需求：<数量> 个 Requirement
-- 测试场景：<数量> 个 Scenario
+- Capabilities：<数量> 个能力
+- Requirements：<数量> 个需求
+- Scenarios：<数量> 个测试场景
 - 非功能需求：<数量> 项
 
-### 核心功能
-<列出 2-3 个核心 Requirement>
-
-### 关键约束
-<列出 1-2 个关键约束>
+### 核心 Capabilities
+<列出 2-3 个核心 Capability 及其变更类型（ADD/MODIFY/REMOVE）>
 
 ### 文档位置
 6aspecdoc/brown/<name>/artifacts/specs.md
@@ -348,10 +464,14 @@
 - 适用于所有流程（轻量级、标准级、完整级）
 - 根据flowDepth检查不同的前置阶段：
   - 轻量级：必须先完成proposal阶段
-  - 标准级/完整级：必须先完成understand阶段
+  - 标准级/完整级：必须先完成impact阶段
+- 功能需求必须按 Capability 组织，结构为：Capability > Requirement > Scenario
+- 每个 Capability 必须标识变更类型：[ADD]（新增）、[MODIFY]（修改）、[REMOVE]（移除）
+- 每个 Capability 应该对应 proposal.md 中的一个能力
 - 功能需求必须使用 Requirement + Scenario (WHEN/THEN) 格式
 - 使用 SHALL/MUST 表示强制性要求，SHOULD 表示推荐性要求
 - 每个 Scenario 必须可测试、可验证
 - 功能需求必须从用户视角描述，避免技术实现细节
 - 需求问题的答案应该体现在功能需求定义中，而不是单独列出
+- 非功能需求和范围边界只写有明确要求的内容，避免空泛描述
 - specs的详细程度保持一致，不区分流程深度

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

@@ -17,18 +17,12 @@ Phase 4: 任务拆解与排期
    根据 `flowDepth` 读取不同的前置文档：
 
    **轻量级流程**：
-   - `6aspecdoc/brown/<name>/requirement.md`
-   - `6aspecdoc/brown/<name>/artifacts/proposal.md`
-   - `6aspecdoc/brown/<name>/artifacts/specs.md`
    - `6aspecdoc/brown/<name>/artifacts/design.md`
+   - `6aspecdoc/brown/<name>/artifacts/specs.md`
 
    **标准级/完整级流程**：
-   - `6aspecdoc/brown/<name>/requirement.md`
-   - `6aspecdoc/brown/<name>/artifacts/proposal.md`
-   - `6aspecdoc/brown/<name>/artifacts/understanding.md`
-   - `6aspecdoc/brown/<name>/artifacts/impact-analysis.md`
-   - `6aspecdoc/brown/<name>/artifacts/specs.md`
    - `6aspecdoc/brown/<name>/artifacts/design.md`
+   - `6aspecdoc/brown/<name>/artifacts/specs.md`
 
 3. **原子任务拆解**
 
@@ -176,6 +170,13 @@ Phase 4: 任务拆解与排期
    }
    ```
 
+   同时更新 `6aspecdoc/brown/<name>/requirement.md`：
+   - 更新"状态"字段为 `📋 Implement 待开始`
+   - 更新"最后修改"时间戳为 `<timestamp>`
+   - 更新"当前阶段"为 `Tasks - 任务拆解（已完成）`
+   - 更新"下一步操作"为 `运行 /6aspec:brown:implement 开始执行任务`
+   - 在"进度概览"中标记 Tasks 阶段为已完成 `[x]`
+
 **输出**
 
 ```

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

@@ -29,11 +29,11 @@
 
 3. **读取需求描述**
 
-   读取 `6aspecdoc/brown/<name>/requirement.md` 获取原始需求内容：
-   - 如果 `inputSource.type = "text"`：读取文档中的"原始需求"部分
-   - 如果 `inputSource.type = "file"`：读取记录的来源文件路径，获取完整需求内容
+   读取 `6aspecdoc/brown/<name>/artifacts/original-requirement.md` 获取原始需求内容：
+   - 如果 `inputSource.type = "text"`：文档中包含用户输入的原始需求描述
+   - 如果 `inputSource.type = "file"`：文档中包含来源文件路径的引用
 
-   **注意**：Understand 阶段不依赖 proposal，直接基于需求描述分析现有系统
+   **注意**：Understand 阶段不依赖 proposal，直接基于原始需求分析现有系统
 
 4. **分析现有系统**
 
@@ -195,6 +195,13 @@
    }
    ```
 
+   同时更新 `6aspecdoc/brown/<name>/requirement.md`：
+   - 更新"状态"字段为 `📋 Impact 待开始`
+   - 更新"最后修改"时间戳为 `<timestamp>`
+   - 更新"当前阶段"为 `Understand - 需求理解与现状分析（已完成）`
+   - 更新"下一步操作"为 `运行 /6aspec:brown:impact 继续下一阶段`
+   - 在"进度概览"中标记 Understand 阶段为已完成 `[x]`
+
 8. **停止并等待用户指令**
 
 **输出**

package/.claude/settings.local.json

@@ -19,7 +19,10 @@
       "Bash(git mv 6A_clarify_sop.md green_clarify_sop.md)",
       "Bash(git mv 6A_status_sop.md green_status_sop.md)",
       "Bash(ls -la .6aspec/rules/green/6A_*.md)",
-      "Bash(xargs sed -i '' 's/6A_\\\\\\([a-z_]*\\\\\\)\\\\.md/green_\\\\1.md/g')"
+      "Bash(xargs sed -i '' 's/6A_\\\\\\([a-z_]*\\\\\\)\\\\.md/green_\\\\1.md/g')",
+      "Bash(openspec --help)",
+      "Bash(openspec schemas --json 2>/dev/null | head -100)",
+      "Bash(openspec status --json 2>/dev/null | head -50)"
     ]
   }
 }

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "6aspec",
-  "version": "2.0.0-dev.18",
+  "version": "2.0.0-dev.20",
   "description": "6Aspec - 轻量级 spec 驱动开发框架，支持 Cursor 和 Claude Code",
   "main": "lib/installer.js",
   "bin": {