6aspec 2.0.0-dev.22 → 2.0.0-dev.24

package/.6aspec/rules/biz/code.md

@@ -1,39 +1,133 @@
 ---
-description: 
-globs: 
-alwaysApply: false
+description: 代码编写规范与质量标准
+globs: "**/*.{java,js,ts,py,go,cpp,c,cs}"
+alwaysApply: true
 ---
 
-## 代码质量
-- **单一职责**：每个类和方法只负责一个功能
-- **开闭原则**：对扩展开放，对修改关闭
-- **依赖倒置**：依赖抽象而不是具体实现
-- **接口隔离**：使用小而专一的接口
-- **代码复用**：提取公共逻辑，避免重复代码
+# 代码编写规范
+
+## 🚨 红线规则（绝对禁止）
+
+### 性能红线
+- **禁止在循环中进行数据库查询**：避免N+1问题，使用批量查询或预加载
+- **禁止在循环中进行网络请求**：使用批量API或异步处理
+- **禁止在循环中进行文件I/O操作**：批量读写或使用缓存
+- **禁止在热点代码路径中使用反射**：影响性能，考虑编译时生成或缓存
+- **禁止在生产环境使用System.out.println调试**：使用日志框架
+
+### 安全红线
+- **禁止直接拼接SQL语句**：必须使用参数化查询防止SQL注入
+- **禁止在日志中输出敏感信息**：密码、token、身份证号等
+- **禁止硬编码密钥和敏感配置**：使用配置文件或环境变量
+- **禁止信任用户输入**：所有外部输入必须验证和过滤
+- **禁止使用弱加密算法**：MD5、SHA1等已不安全
+
+### 架构红线
+- **禁止循环依赖**：包、模块、类之间不能相互依赖
+- **禁止跨层直接调用**：Controller不能直接调用DAO
+- **禁止在实体类中包含业务逻辑**：保持实体类的纯净性
+- **禁止在静态代码块中进行复杂操作**：可能导致类加载问题
+- **禁止捕获异常后不处理**：空catch块是代码异味
+
+## 🔒 安全规范
+
+### 输入验证
+- **参数校验**：所有API入参必须校验
+- **数据过滤**：防止XSS、SQL注入等攻击
+- **权限检查**：每个操作都要验证用户权限
+- **敏感数据处理**：加密存储，脱敏展示
+
+### 日志安全
+- **敏感信息脱敏**：密码、token等不能明文记录
+- **操作审计**：关键操作必须记录审计日志
+- **错误信息**：不暴露系统内部信息给用户
+
+## ⚡ 性能优化
+
+### 数据库优化
+- **索引使用**：查询字段必须有合适的索引
+- **批量操作**：使用批量插入/更新减少数据库交互
+- **连接池管理**：合理配置数据库连接池
+- **查询优化**：避免全表扫描，使用分页查询
 
-## 性能优化
-- **算法复杂度**：选择合适的算法和数据结构
-- **缓存策略**：合理使用缓存减少重复计算
-- **懒加载**：对于昂贵的操作使用懒加载
-- **批量处理**：批量处理数据库操作和网络请求
+### 缓存策略
+- **多级缓存**：本地缓存 + 分布式缓存
+- **缓存更新**：及时更新或失效过期数据
+- **缓存穿透**：防止恶意查询不存在的数据
+- **缓存雪崩**：设置随机过期时间
 
+### 算法复杂度
+- **时间复杂度**：优先选择O(1)、O(log n)算法
+- **空间复杂度**：避免不必要的内存占用
+- **数据结构选择**：根据使用场景选择合适的数据结构
 
-## 编码规范
-- **命名规范**：类名、方法名、变量名清晰表达意图
-- **代码结构**：合理的包结构和类层次
-- **注释规范**：必要的类和方法注释
-- **代码复用**：避免重复代码，提取公共方法
+## 📝 编码规范
 
+### 命名规范
+- **类名**：大驼峰命名，名词，表达清晰意图
+- **方法名**：小驼峰命名，动词开头，表达具体行为
+- **变量名**：小驼峰命名，避免缩写，见名知意
+- **常量名**：全大写，下划线分隔
+- **包名**：全小写，层次清晰
 
-## 设计原则
-- **SOLID 原则**：单一职责、开闭原则等
-- **DRY 原则**：不重复自己
-- **KISS 原则**：保持简单
-- **YAGNI 原则**：你不会需要它
+### 代码结构
+- **包结构**：按功能模块划分，层次清晰
+- **类大小**：单个类不超过500行
+- **方法长度**：单个方法不超过50行
+- **参数个数**：方法参数不超过5个
+- **嵌套层次**：代码嵌套不超过4层
 
+### 注释规范
+- **类注释**：说明类的职责和使用场景
+- **方法注释**：说明参数、返回值、异常
+- **复杂逻辑注释**：解释为什么这样做
+- **TODO注释**：标记待完成的工作
 
-## 重构策略
-- **持续重构**：小步快跑，持续改进
+## 🏗️ 设计原则
+
+### SOLID原则
+- **单一职责原则**：一个类只负责一个功能领域
+- **开闭原则**：对扩展开放，对修改关闭
+- **里氏替换原则**：子类可以替换父类
+- **接口隔离原则**：使用多个专门的接口
+- **依赖倒置原则**：依赖抽象而不是具体实现
+
+### 其他原则
+- **DRY原则**：不重复自己，提取公共代码
+- **KISS原则**：保持简单，避免过度设计
+- **YAGNI原则**：你不会需要它，不做过度设计
+- **最少知识原则**：对象应该对其他对象有最少的了解
+
+## 🔄 重构策略
+
+### 重构时机
+- **新功能开发时**：同步重构相关代码
+- **Bug修复时**：改善代码结构
+- **代码审查时**：发现问题及时重构
+- **性能优化时**：重构性能瓶颈代码
+
+### 重构原则
+- **小步快跑**：每次重构范围要小
 - **测试保护**：重构前确保测试覆盖
-- **重构时机**：新功能开发时同步重构
-- **技术债务**：定期评估和偿还技术债务
+- **持续集成**：频繁提交，及时发现问题
+- **技术债务管理**：定期评估和偿还
+
+## ✅ 检查清单
+
+### 代码提交前检查
+- [ ] 是否违反红线规则
+- [ ] 是否有安全漏洞
+- [ ] 是否有性能问题
+- [ ] 命名是否规范
+- [ ] 是否有充分的测试
+- [ ] 是否有必要的注释
+- [ ] 是否符合团队编码风格
+
+### 代码审查检查
+- [ ] 业务逻辑是否正确
+- [ ] 异常处理是否完善
+- [ ] 边界条件是否考虑
+- [ ] 是否有代码重复
+- [ ] 是否符合设计原则
+- [ ] 是否有技术债务
+- [ ] 文档是否需要更新

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

@@ -9,8 +9,11 @@
 1. **选择需求并检查状态**
 
    - 读取 `6aspecdoc/brown/<name>/status.json`
-   - 确认 `phases.review` 为 "done"
-   - 如果未完成 Phase 7，询问是否强制归档
+   - 获取 `flowDepth`（流程深度）
+   - 根据流程深度检查前置条件：
+     - **轻量级/标准级流程**：确认 `phases.implement` 为 "done" 或 `status` 为 "completed"
+     - **完整级流程**：确认 `phases.review` 为 "done"
+   - 如果未满足前置条件，询问是否强制归档
 
 2. **确认归档**
 
@@ -126,7 +129,10 @@
 ```
 
 **防护措施**
-- 如果未完成所有阶段，警告用户并询问是否强制归档
+- 根据流程深度检查不同的前置条件：
+  - 轻量级/标准级：implement 必须完成
+  - 完整级：review 必须完成
+- 如果未满足前置条件，警告用户并询问是否强制归档
 - 归档前必须确认
 - 归档操作不可逆（除非手动恢复）
 - 保留完整的归档信息和摘要

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

@@ -30,7 +30,9 @@
    **如果所有阶段都完成 (`phases` 全部为 "done")**：
    - 祝贺用户
    - 显示最终状态
-   - 建议："所有阶段已完成！可以运行 `/6aspec:brown:implement` 开始实施，或运行 `/6aspec:brown:archive` 归档。"
+   - 根据流程深度给出建议：
+     - 轻量级/标准级："所有阶段已完成！可以运行 `/6aspec:brown:verify` 进行质量检查（可选），或运行 `/6aspec:brown:archive` 归档。"
+     - 完整级："所有阶段已完成！可以运行 `/6aspec:brown:archive` 归档。"
    - 停止
 
    **如果有待执行的阶段**：
@@ -43,6 +45,7 @@
    - `design` → 调用 `/6aspec:brown:design`
    - `tasks` → 调用 `/6aspec:brown:tasks`
    - `implement` → 调用 `/6aspec:brown:implement`
+   - 如果 implement 已完成且无待执行阶段 → 提示："所有阶段已完成！可以运行 `/6aspec:brown:verify` 进行质量检查（可选），或运行 `/6aspec:brown:archive` 归档。"
 
    **标准级流程（standard）**：
    - `understand` → 调用 `/6aspec:brown:understand`
@@ -52,6 +55,7 @@
    - `design` → 调用 `/6aspec:brown:design`
    - `tasks` → 调用 `/6aspec:brown:tasks`
    - `implement` → 调用 `/6aspec:brown:implement`
+   - 如果 implement 已完成且无待执行阶段 → 提示："所有阶段已完成！可以运行 `/6aspec:brown:verify` 进行质量检查（可选），或运行 `/6aspec:brown:archive` 归档。"
 
    **完整级流程（complete）**：
    - `understand` → 调用 `/6aspec:brown:understand`

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

@@ -50,7 +50,26 @@
    - 保持变更最小化和聚焦
    - 遵循技术方案设计
 
-   d. **标记任务完成**
+   d. **质量控制检查**
+   **必须严格遵循代码规范**：`.6aspec/rules/biz/code.md`，并使用其中的"检查清单"章节进行自我验证。
+
+   **重点关注以下红线规则（零容忍）：**
+   - [ ] 循环中的数据库查询、网络请求、文件I/O操作
+   - [ ] SQL字符串拼接、敏感信息硬编码、弱加密算法使用
+   - [ ] 循环依赖、跨层直接调用、空catch块
+
+   **棕地需求特别检查：**
+   - [ ] 修改是否符合现有代码风格和架构模式
+   - [ ] 是否引入了新的技术债务
+   - [ ] 是否影响了现有功能的稳定性
+   - [ ] 是否遵循了设计文档中的技术决策
+
+   **技术检查：**
+   - [ ] 运行相关测试确保无回归
+   - [ ] 检查代码编译和语法错误
+   - [ ] 验证修改范围最小化
+
+   e. **标记任务完成**
    - 在任务文件中更新状态：`📋 待开始` → `✅ 已完成`
    - 在 `04-tasks-overview.md` 中更新任务状态：`- [ ]` → `- [x]`
    - 更新 `status.json` 中的任务计数
@@ -79,7 +98,14 @@
    ...
 
    ### 下一步
-   所有任务已完成！运行 `/6aspec:brown:verify` 进行验证。
+   所有任务已完成！
+
+   - 轻量级/标准级流程:
+     - 运行 `/6aspec:brown:verify` 进行质量检查（可选）
+     - 运行 `/6aspec:brown:archive` 归档此需求
+
+   - 完整级流程:
+     - 运行 `/6aspec:brown:continue` 继续下一阶段（verify）
    ```
 
    **如果暂停**：
@@ -102,7 +128,25 @@
 
 6. **更新状态**
 
-   如果全部完成，更新 `status.json`：
+   如果全部完成，根据流程深度更新 `status.json`：
+
+   **轻量级/标准级流程**：
+   ```json
+   {
+     "status": "completed",
+     "phases": {
+       ...
+       "implement": "done"
+     },
+     "tasks": {
+       "total": 8,
+       "completed": 8,
+       "pending": 0
+     }
+   }
+   ```
+
+   **完整级流程**：
    ```json
    {
      "status": "verify_pending",

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

@@ -0,0 +1,287 @@
+# 棕地需求 - Update SOP
+
+非破坏性地更新指定阶段的文档，支持简单模式和智能模式。
+
+**输入**：
+- `/6aspec:brown:update <requirement-name> <phase>` - 简单更新（默认）
+- `/6aspec:brown:update <requirement-name> <phase> --smart` - 智能更新
+- `/6aspec:brown:update <requirement-name> --history` - 查看更新历史
+
+**适用场景**：
+- ✅ 补充遗漏的信息
+- ✅ 修正错别字、格式问题
+- ✅ 澄清模糊的描述
+- ✅ 添加新的考虑因素（不推翻原有决策）
+- ✅ 调整优先级、时间估算等非核心内容
+- ✅ 修正小的技术细节
+
+**不适用场景（建议使用 rollback）**：
+- ❌ 推翻核心决策（如技术方案选型）
+- ❌ 发现前面阶段的分析有重大错误
+- ❌ 需求发生根本性变化
+- ❌ 影响范围太大，难以准确识别
+- ❌ 需要重新思考整个方案
+
+**支持的阶段**：
+- `understand` - 现状分析（相对稳定，不常需要update）
+- `impact` - 影响面分析（相对稳定，不常需要update）
+- `proposal` - 需求提案（常见update场景）
+- `specs` - 需求规格（常见update场景）
+- `design` - 技术设计（常见update场景）
+- `tasks` - 任务拆解（常见update场景）
+
+**限制**：
+- 只能更新已完成的阶段（状态为 "done"）
+- 不能更新已归档的需求
+- 不能更新不存在的阶段文档
+- 在实施阶段（implement、verify、review）使用时需要特别小心
+
+**步骤**
+
+1. **选择需求**
+
+   如果提供了名称，使用它。否则：
+   - 从对话上下文推断
+   - 如果模糊，读取 `6aspecdoc/brown/` 目录，让用户选择
+
+2. **处理特殊选项**
+
+   **如果是 `--history` 选项**：
+   - 读取 `6aspecdoc/brown/<name>/artifacts/` 目录下的所有文档
+   - 提取每个文档末尾的"修改记录"部分
+   - 按时间顺序汇总显示所有更新历史
+   - 显示统计信息（总更新次数、最近更新时间等）
+   - 停止执行
+
+3. **检查当前状态**
+
+   读取 `6aspecdoc/brown/<name>/status.json`：
+   - 确认需求未归档
+   - 确认目标阶段存在且状态为 "done"
+   - 确认对应的文档文件存在
+
+4. **读取目标文档**
+
+   根据阶段名称读取对应文档：
+   - `understand` → `artifacts/understanding.md`
+   - `impact` → `artifacts/impact-analysis.md`
+   - `proposal` → `artifacts/proposal.md`
+   - `specs` → `artifacts/specs.md`
+   - `design` → `artifacts/design.md`
+   - `tasks` → `artifacts/tasks.md`
+
+5. **获取用户修改需求**
+
+   询问用户要修改的内容：
+   ```
+   问题："请描述您要对 <phase> 阶段文档进行的修改："
+
+   提示：
+   - 请具体描述要修改、补充或调整的内容
+   - 如果是补充信息，请说明要补充什么
+   - 如果是修正错误，请说明错误的地方和正确的内容
+   - 如果是调整描述，请说明要如何调整
+   ```
+
+6. **执行更新（根据模式）**
+
+   **简单模式（默认）**：
+
+   a. 根据用户描述修改目标文档
+
+   b. 在文档末尾添加或更新修改记录：
+   ```markdown
+   ## 修改记录
+   - 2026-02-27 10:30: <修改描述>（update）
+   ```
+
+   c. 分析可能受影响的后续文档，生成检查清单
+
+   d. 更新 status.json 中的 lastUpdate
+
+   e. 显示检查清单，提示用户手动检查后续文档
+
+   **智能模式（--smart）**：
+
+   a. 分析修改内容对后续文档的影响范围
+
+   b. 读取所有可能受影响的后续文档
+
+   c. 生成详细的更新计划：
+   ```markdown
+   ## 更新计划
+
+   ### 修改内容
+   - <phase>.md: <修改描述>
+
+   ### 影响分析
+   - <后续文档1>: 需要更新"<具体部分>"
+     - 位置：第 X.Y 节
+     - 修改：<具体修改内容>
+   - <后续文档2>: 不需要修改
+
+   ### 风险评估
+   - <风险级别>：<风险描述>
+   - 建议：<执行建议>
+   ```
+
+   d. **等待用户确认**：
+   ```
+   问题："是否执行上述更新计划？"
+   选项：
+   - 确认执行更新
+   - 取消
+   ```
+
+   e. 如果用户确认，批量执行所有更新：
+   - 修改目标文档
+   - 更新所有受影响的后续文档
+   - 在每个修改的文档末尾添加修改记录
+
+   f. 生成更新报告
+
+7. **更新状态记录**
+
+   更新 `6aspecdoc/brown/<name>/status.json`：
+
+   a. 更新 `lastModified` 时间戳
+
+   b. 更新 `lastUpdate` 记录：
+   ```json
+   "lastUpdate": {
+     "phase": "<phase>",
+     "timestamp": "<时间戳>",
+     "description": "<修改描述>",
+     "affectedPhases": ["<阶段1>", "<阶段2>"],
+     "mode": "simple|smart"
+   }
+   ```
+
+8. **显示更新结果**
+
+**输出**
+
+**简单模式输出**：
+```
+## 更新完成：<name>
+
+**更新阶段**: <phase>
+**更新时间**: <时间戳>
+**更新模式**: 简单模式
+
+### 修改内容
+<修改描述>
+
+### 影响分析和检查清单
+
+#### 可能受影响的文档
+- [ ] <文档1>: <检查要点>
+- [ ] <文档2>: <检查要点>
+
+#### 建议
+<具体检查建议>
+
+### 下一步
+请根据检查清单逐一检查可能受影响的文档，必要时手动调整。
+```
+
+**智能模式输出**：
+```
+## 更新完成：<name>
+
+**更新阶段**: <phase>
+**更新时间**: <时间戳>
+**更新模式**: 智能模式
+
+### 修改内容
+<修改描述>
+
+### 联动更新
+- <文档1>: <更新内容>
+- <文档2>: <更新内容>
+
+### 修改摘要
+- 共修改 N 个文件
+- 新增 X 字
+- 修改 Y 处
+
+### 建议
+请人工复查关键文档，确认修改内容符合预期。
+```
+
+**历史查看输出**：
+```
+## 更新历史：<name>
+
+### 更新记录
+1. **2026-02-27 10:30** - proposal
+   - 描述：补充业务背景说明
+
+2. **2026-02-26 15:20** - specs
+   - 描述：调整性能指标要求
+
+### 统计
+- 总更新次数：2
+- 最近更新：2026-02-27 10:30
+- 涉及阶段：proposal, specs
+```
+
+**依赖关系和影响分析规则**
+
+根据文档依赖关系确定影响范围：
+
+```
+understand (现状分析)
+  ↓
+impact (影响面分析)
+  ↓
+proposal (Why, What, Impact)
+  ↓
+specs (功能需求、验收标准)
+  ↓
+design (技术方案)
+  ↓
+tasks (任务拆解)
+  ↓
+implement (代码实现)
+```
+
+**影响分析矩阵**：
+
+| 修改位置 | 可能影响的文档 | 影响程度 | 检查重点 |
+|---------|--------------|---------|---------|
+| understand.现状 | impact, proposal | 中 | 影响面、需求背景 |
+| impact.影响面 | proposal, design | 中 | 需求范围、非功能需求 |
+| proposal.Why | specs, design | 中 | 优先级、技术选型 |
+| proposal.What | specs, design, tasks | 高 | 功能需求、技术方案、任务拆解 |
+| proposal.Impact | design | 低 | 非功能需求 |
+| specs.功能需求 | design, tasks | 高 | 技术方案、任务拆解 |
+| specs.验收标准 | tasks | 中 | 任务定义、测试用例 |
+| design.技术方案 | tasks | 高 | 任务拆解、工作量估算 |
+| design.技术选型 | tasks | 中 | 技术栈、工作量估算 |
+
+**防护措施**
+- 必须确认需求未归档
+- 必须确认目标阶段已完成（状态为 "done"）
+- 必须确认对应文档文件存在
+- 智能模式必须等待用户确认后才执行更新
+- 在实施阶段使用时特别提示代码一致性问题
+- 记录所有更新历史，支持追溯
+- 生成的检查清单必须具体明确
+- 智能模式的影响分析必须准确，避免误判
+
+**错误处理**
+
+- 如果需求不存在，提示创建新需求
+- 如果需求已归档，提示先取消归档
+- 如果目标阶段不存在或未完成，提示阶段状态
+- 如果对应文档文件不存在，提示文件缺失
+- 如果在实施阶段使用，特别提示：
+  ```
+  ⚠️  警告：当前需求处于实施阶段，更新文档后请检查代码是否需要相应调整。
+  如果修改影响代码实现，建议使用 rollback 或创建新需求。
+  ```
+- 如果智能模式影响分析失败，降级为简单模式
+- 如果用户取消智能模式的更新计划，停止执行
+- 如果文档修改失败，回滚已修改的文件并报告错误
+- 如果--history选项找不到修改记录，显示"暂无更新历史"

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

@@ -11,28 +11,29 @@
 1. **选择需求并检查状态**
 
    - 读取 `6aspecdoc/brown/<name>/status.json`
-   - 确认 `phases.implement` 为 "done"
    - 获取 `flowDepth`（流程深度）
-   - 如果未完成 Phase 5，提示先运行 `/6aspec:brown:implement`
+   - 检查 `phases.implement` 状态：
+     - 如果为 "done" → 完整验证
+     - 如果为 "in_progress" → 增量验证
+     - 如果为 "pending" → 警告："尚未开始实现，建议先运行 `/6aspec:brown:implement`"，但仍可继续验证
 
 2. **读取验证基准文档**
 
-   根据流程深度读取不同的文档：
+   统一的文档读取逻辑，根据文档是否存在自动适配：
 
-   **轻量级流程**：
-   - `artifacts/proposal.md` - 需求提案
+   **必读文档**（所有流程都有）：
    - `artifacts/design.md` - 技术方案
-   - `artifacts/tasks.md` - 任务列表
+   - `artifacts/tasks.md` 或 `artifacts/04-tasks-overview.md` - 任务列表
 
-   **标准级流程**：
-   - `artifacts/understanding.md` - 需求理解
-   - `artifacts/impact-analysis.md` - 影响面分析
-   - `artifacts/design.md` - 技术方案
-   - `artifacts/tasks.md` - 任务列表
+   **可选文档**（根据存在性读取）：
+   - `artifacts/understanding.md` - 需求理解（标准级/完整级）
+   - `artifacts/proposal.md` - 需求提案（轻量级）
+   - `artifacts/impact-analysis.md` - 影响面分析（标准级/完整级）
+   - `requirement.md` - 需求描述（快速通道）
 
-   **完整级流程**：
-   - 所有标准级文档
-   - 加上非功能需求评估（在 impact-analysis.md 中）
+   **文档读取策略**：
+   - 尝试读取文档，如果不存在则跳过
+   - 验证报告中明确标注跳过的检查项
 
 3. **初始化验证报告结构**
 
@@ -60,15 +61,17 @@
    - 解析 checkbox：`- [ ]`（未完成）vs `- [x]`（已完成）
    - 统计完成率：X/Y 任务完成
    - 如果有未完成任务：
-     - 添加 **CRITICAL** 问题：`Task incomplete: <task-id> - <description>`
+     - **增量验证**：添加 **INFO** 说明：`Incremental verification: X/Y tasks completed`
+     - **完整验证**：添加 **CRITICAL** 问题：`Task incomplete: <task-id> - <description>`
      - 建议：`Complete task or mark as done if already implemented`
 
    **4.2 影响面覆盖验证**（棕地特色）
 
-   仅适用于标准级/完整级流程：
+   根据文档存在性自动适配：
 
-   - 读取 `artifacts/impact-analysis.md`
-   - 提取影响点列表：
+   - 尝试读取 `artifacts/impact-analysis.md`
+   - 如果文档不存在，跳过此检查，标注：`Skipped: no impact-analysis.md found`
+   - 如果文档存在，提取影响点列表：
      - 数据库表
      - 实体类
      - 服务类
@@ -85,9 +88,10 @@
 
    **5.1 需求实现映射**（借鉴 OpenSpec）
 
-   - 提取需求关键点：
-     - 轻量级：从 proposal.md 提取 What 部分
-     - 标准级/完整级：从 understanding.md 提取需求描述
+   - 提取需求关键点（按优先级尝试）：
+     - 优先：从 understanding.md 提取需求描述
+     - 其次：从 proposal.md 提取 What 部分
+     - 最后：从 requirement.md 提取需求描述
    - 对每个需求点：
      - 搜索代码库查找实现证据
      - 如果找到，记录文件路径和行号
@@ -98,10 +102,11 @@
 
    **5.2 业务规则验证**（棕地特色）
 
-   仅适用于标准级/完整级流程：
+   根据文档存在性自动适配：
 
-   - 读取 `artifacts/impact-analysis.md` 中的"业务规则确认"部分
-   - 提取关键业务规则：
+   - 尝试读取 `artifacts/impact-analysis.md` 中的"业务规则确认"部分
+   - 如果文档不存在或无业务规则部分，跳过此检查，标注：`Skipped: no business rules found`
+   - 如果存在，提取关键业务规则：
      - 必填校验
      - 不可修改约束
      - 继承逻辑
@@ -155,10 +160,11 @@
 
    **6.3 非功能需求符合验证**（棕地特色）
 
-   仅适用于完整级流程：
+   根据文档存在性自动适配：
 
-   - 读取 `artifacts/impact-analysis.md` 中的"非功能需求评估"部分
-   - 验证四个维度：
+   - 尝试读取 `artifacts/impact-analysis.md` 中的"非功能需求评估"部分
+   - 如果文档不存在或无非功能需求部分，跳过此检查，标注：`Skipped: no non-functional requirements found`
+   - 如果存在，验证四个维度：
 
    **性能**：
    - 检查是否添加了必要的索引
@@ -192,7 +198,7 @@
 
 7. **生成验证报告**
 
-   创建 `6aspecdoc/brown/<name>/artifacts/verification-report.md`（标准级/完整级）或 `6aspecdoc/brown/<name>/artifacts/05-verification-report.md`（完整级）：
+   创建 `6aspecdoc/brown/<name>/artifacts/verification-report.md`：
 
    ```markdown
    # 验证报告：<name>
@@ -200,6 +206,8 @@
    > **需求**: <name>
    > **流程深度**: 轻量级/标准级/完整级
    > **验证时间**: <timestamp>
+   > **验证类型**: 🔄 增量验证 / ✅ 完整验证
+   > **任务进度**: X/Y 已完成 (Z%)
    > **验证状态**: ✅ 通过 / ⚠️ 有警告 / ❌ 有严重问题
 
    ## 验证概览
@@ -244,21 +252,46 @@
    - **位置**: ProjectApplicationService:123
    - **建议**: Consider using BusinessLogicException pattern like other services
 
+   ## 验证说明
+
+   根据验证类型添加说明：
+
+   - 如果是增量验证：
+     ```
+     ⚠️ 这是增量验证（部分任务未完成）。建议在所有任务完成后重新验证。
+     ```
+
+   - 如果是完整验证：
+     ```
+     ✅ 这是完整验证（所有任务已完成）。
+     ```
+
    ## 最终评估
 
-   根据问题严重程度给出评估：
+   根据问题严重程度和验证类型给出评估：
+
+   - 如果是增量验证：
+     ```
+     ⚠️ 这是增量验证，当前进度 X/Y 任务完成。
+
+     已完成任务的验证结果：
+     - [结果摘要]
 
-   - 如果有 CRITICAL 问题：
+     未完成任务：
+     - [ ] TASK-XXX: <描述>
+     ```
+
+   - 如果是完整验证且有 CRITICAL 问题：
      ```
      ❌ 发现 X 个严重问题，必须修复后才能归档。
      ```
 
-   - 如果只有 WARNING：
+   - 如果是完整验证且只有 WARNING：
      ```
      ⚠️ 没有严重问题，但有 Y 个警告需要考虑。可以归档，但建议修复警告。
      ```
 
-   - 如果全部通过：
+   - 如果是完整验证且全部通过：
      ```
      ✅ 所有检查通过，可以归档。
      ```
@@ -276,19 +309,59 @@
 
    ## 下一步
 
-   根据验证结果给出建议：
-   - 如果有 CRITICAL：修复严重问题后重新验证
-   - 如果只有 WARNING：可以归档，但建议修复警告
-   - 如果全部通过：运行 `/6aspec:brown:review` 进行实施后评估（完整级）或 `/6aspec:brown:archive` 归档
+   根据验证类型和结果给出建议：
+
+   - 如果是增量验证：
+     ```
+     1. 继续完成剩余任务
+     2. 完成后重新运行 `/6aspec:brown:verify` 进行完整验证
+     ```
+
+   - 如果是完整验证且有 CRITICAL：
+     ```
+     修复严重问题后重新验证
+     ```
+
+   - 如果是完整验证且只有 WARNING：
+     ```
+     - 轻量级/标准级：可以运行 `/6aspec:brown:archive` 归档，但建议修复警告
+     - 完整级：可以运行 `/6aspec:brown:continue` 进入 review 阶段，但建议修复警告
+     ```
+
+   - 如果是完整验证且全部通过：
+     ```
+     - 轻量级/标准级：运行 `/6aspec:brown:archive` 归档
+     - 完整级：运行 `/6aspec:brown:continue` 进入 review 阶段
+     ```
    ```
 
 8. **更新状态**
 
-   如果验证通过（无 CRITICAL 问题），更新 `status.json`：
+   根据流程深度、验证类型和验证结果决定是否更新状态：
+
+   **轻量级/标准级流程**：
+   - 不更新 status 和 phases（verify 是可选的）
+   - 在 `verificationRuns` 数组中添加本次验证记录：
+   ```json
+   {
+     "verificationRuns": [
+       {
+         "timestamp": "<timestamp>",
+         "type": "incremental" / "complete",
+         "status": "passed" / "warning" / "failed",
+         "criticalIssues": 0,
+         "warnings": 2,
+         "tasksCompleted": "5/8"
+       }
+     ]
+   }
+   ```
+
+   **完整级流程**：
+   - 只有在完整验证（implement 已完成）且验证通过（无 CRITICAL 问题）时才更新状态：
    ```json
    {
      "status": "review_pending",
-     "status": "completed",
      "phases": {
        ...
        "verify": "done",
@@ -296,6 +369,7 @@
      }
    }
    ```
+   - 如果是增量验证或验证未通过，不更新状态
 
 **输出**
 
@@ -303,11 +377,13 @@
 ## 验证完成：<name>
 
 **流程深度**: 轻量级/标准级/完整级
+**验证类型**: 🔄 增量验证 / ✅ 完整验证
+**任务进度**: X/Y 已完成 (Z%)
 **验证状态**: ✅ 通过 / ⚠️ 有警告 / ❌ 有严重问题
 
 ### 验证概览
-- Completeness: X/Y 任务完成, M/N 影响点覆盖
-- Correctness: P/Q 需求实现, R/S 业务规则验证
+- Completeness: X/Y 任务完成, M/N 影响点覆盖（或跳过）
+- Correctness: P/Q 需求实现, R/S 业务规则验证（或跳过）
 - Coherence: 设计遵循/代码一致
 
 ### 问题统计
@@ -316,13 +392,13 @@
 - SUGGESTION: Z 个（建议修复）
 
 ### 最终评估
-<根据问题严重程度给出评估>
+<根据验证类型和问题严重程度给出评估>
 
 ### 文档位置
 6aspecdoc/brown/<name>/artifacts/verification-report.md
 
 ### 下一步
-<根据验证结果给出建议>
+<根据验证类型和结果给出建议>
 ```
 
 **验证启发式规则**（借鉴 OpenSpec）
@@ -335,26 +411,30 @@
 
 **优雅降级**（借鉴 OpenSpec）
 
-根据流程深度调整验证范围：
+统一的验证流程，根据文档存在性自动适配：
 
-- **轻量级流程**：
-  - 验证：任务完成度 + 设计遵循
-  - 跳过：影响面覆盖、业务规则、非功能需求
-  - 说明：`Lightweight flow: skipped impact/business rule checks`
+- **文档存在性检查**：
+  - 尝试读取每个验证所需的文档
+  - 如果文档不存在，跳过相应的验证检查
+  - 在验证报告中明确标注跳过的检查项
 
-- **标准级流程**：
-  - 验证：任务完成度 + 影响面覆盖 + 业务规则 + 设计遵循
-  - 跳过：非功能需求详细验证
-  - 说明：`Standard flow: skipped detailed non-functional requirement checks`
+- **自动适配示例**：
+  - 如果没有 `impact-analysis.md` → 跳过影响面覆盖验证、业务规则验证、非功能需求验证
+  - 如果没有 `understanding.md` → 从 `proposal.md` 或 `requirement.md` 提取需求
+  - 如果没有非功能需求评估部分 → 跳过非功能需求验证
 
-- **完整级流程**：
-  - 验证：所有三个维度的全部检查
-  - 说明：`Complete flow: all checks performed`
+- **验证报告标注**：
+  - 跳过的检查项标注为：`Skipped: <reason>`
+  - 例如：`Skipped: no impact-analysis.md found`
+  - 例如：`Skipped: no business rules section in impact-analysis.md`
 
 **防护措施**
-- 必须先完成 Phase 5（implement）
+- 支持在任何时候运行 verify（增量验证或完整验证）
 - 验证必须基于文档基准，不能主观判断
 - 发现问题必须明确标注严重程度（CRITICAL/WARNING/SUGGESTION）
 - 每个问题必须提供具体的、可操作的建议
-- 如果验证未通过（有 CRITICAL 问题），不能进入下一阶段
-- 根据流程深度优雅降级，不要对轻量级流程执行完整级的验证
+- 增量验证时，未完成任务标注为 INFO，不作为 CRITICAL 问题
+- 完整验证时，未完成任务标注为 CRITICAL 问题
+- 轻量级/标准级流程的 verify 不更新状态
+- 完整级流程只有在完整验证且通过时才更新状态
+- 根据文档存在性自动适配验证范围，跳过的检查项必须明确标注

package/.6aspec/rules/green/green_code_implementation_sop.md

@@ -66,6 +66,21 @@ alwaysApply: false
 ## 2. 质量控制 (Quality Control)
 
 在输出代码后，必须进行自我审查：
+
+### 2.1 代码规范遵循与检查
+**必须严格遵循代码规范**：`.6aspec/rules/biz/code.md`，并使用其中的"检查清单"章节进行自我验证。
+
+**重点关注以下红线规则（零容忍）：**
+- [ ] 循环中的数据库查询、网络请求、文件I/O操作
+- [ ] SQL字符串拼接、敏感信息硬编码、弱加密算法使用
+- [ ] 循环依赖、跨层直接调用、空catch块
+
+**任务实现特别检查：**
+- [ ] 字段名称和类型严格匹配 `api-definition.md` 和技术设计文档
+- [ ] 严格翻译技术设计文档中的"执行逻辑"和"核心技术决策"
+- [ ] 必要的注解已添加（Swagger, Auth, Validation）
+
+### 2.2 技术检查
 1.  **Lint 检查**：运行 `read_lints` 检查新文件，修复所有 Import 错误和语法错误。
 2.  **不写测试**：严禁编写 `src/test` 下的单元测试代码（除非用户明确要求）。
 3.  **不修改无关文件**：严禁修改与本任务无关的现有代码（除非是必要的 Entity 关联更新）。

package/.6aspec/rules/green/green_new_sop.md

@@ -110,7 +110,18 @@
 
 **这是本 SOP 的核心价值环节。**
 
-基于 Step 2 的初步分析，AI 必须主动列出 **3-5 个关键不确定点或风险点**，向用户提问确认。
+基于 Step 2 的初步分析，AI 必须：
+1. **识别所有关键不确定点或风险点**
+2. **按优先级排序**，选择最重要的 **3-5 个**向用户提问确认
+3. **其他问题写入待确认项**，标注优先级，后续通过 `clarify` 命令继续澄清
+
+#### 优先级判断标准
+
+| 优先级 | 定义 | 示例 |
+| :--- | :--- | :--- |
+| **P0** | 影响核心流程，不明确则无法进行领域建模 | 核心业务规则、主流程分支逻辑、关键状态定义 |
+| **P1** | 影响设计决策或存在实施风险 | 性能要求、集成方式、并发处理策略 |
+| **P2** | 影响细节实现但不阻塞主流程 | UI细节、提示文案、次要分支场景 |
 
 #### 反向提问的分类
 
@@ -124,6 +135,8 @@
 
 #### 提问格式
 
+**如果识别出的关键问题 ≤ 5 个**，全部向用户提问：
+
 ```markdown
 ---
 
@@ -132,6 +145,7 @@
 基于对 PRD 的分析，以下 N 个问题需要确认后才能继续：
 
 ### Q1: [问题标题]
+**优先级**：P0 / P1 / P2
 **类别**：语义模糊 / 边界缺失 / 流程遗漏 / 规则冲突 / 非功能隐患
 **来源**：PRD 第X章 / 第X节
 **问题描述**：<具体问题>
@@ -148,6 +162,35 @@
 - 告知哪些问题需要与产品/业务方再确认（将记录为"待确认项"）
 ```
 
+**如果识别出的关键问题 > 5 个**，只提问最重要的 3-5 个，其他写入待确认项：
+
+```markdown
+---
+
+## 🔍 需求澄清确认
+
+基于对 PRD 的分析，识别出 N 个关键不确定点。以下是最重要的 3-5 个问题，需要优先确认：
+
+### Q1: [问题标题]
+**优先级**：P0 / P1
+**类别**：语义模糊 / 边界缺失 / 流程遗漏 / 规则冲突 / 非功能隐患
+**来源**：PRD 第X章 / 第X节
+**问题描述**：<具体问题>
+**AI 建议**：<如果有合理的默认假设，可以给出建议供用户参考>
+
+### Q2: [问题标题]
+...
+
+---
+
+⚠️ **还有 X 个其他关键问题已记录到待确认项**（详见生成的 requirement.md），建议后续通过 `/6aspec:green:clarify` 继续澄清。
+
+请逐一确认以上问题，您可以：
+- 直接回答每个问题
+- 提供补充文档
+- 告知哪些问题需要与产品/业务方再确认（将记录为"待确认项"）
+```
+
 **重要**：
 - 必须等待用户回复后再继续，不要跳过此步骤
 - 如果用户表示某些问题需要后续确认，记录为"待确认项"写入 requirement.md
@@ -226,11 +269,11 @@
 | 兼容性 | <如有> | |
 
 ## 8. 待确认项
-> 以下问题尚需与产品/业务方进一步确认，不阻塞领域建模但可能影响详细设计。
+> 以下问题尚需与产品/业务方进一步确认。P0/P1 问题会阻塞流程，需优先澄清；P2 问题不阻塞领域建模但可能影响详细设计。
 
-| 序号 | 问题 | 状态 | 负责人 | 备注 |
-| :--- | :--- | :--- | :--- | :--- |
-| TBD-01 | <待确认问题> | 待确认/已确认 | <负责人> | <备注> |
+| 序号 | 优先级 | 问题 | 类别 | AI建议 | 状态 | 备注 |
+| :--- | :--- | :--- | :--- | :--- | :--- | :--- |
+| TBD-01 | P0/P1/P2 | <待确认问题> | 语义模糊/边界缺失/流程遗漏/规则冲突/非功能隐患 | <AI建议> | 待确认/已确认 | <备注> |
 
 ## 9. 附录
 
@@ -246,7 +289,11 @@
 
 ### Step 5: 更新状态文件
 
-完成需求澄清文档后，更新 `.green-status.json`：
+完成需求澄清文档后，根据待确认项的优先级更新 `.green-status.json`：
+
+#### 情况 1：无待确认项，或只有 P2 待确认项
+
+状态设置为 `requirement_clarified`，可以进入领域建模：
 
 ```json
 {
@@ -268,19 +315,51 @@
 }
 ```
 
-**注意**：如果存在较多"待确认项"（TBD 项 ≥ 3 个且涉及核心流程），建议状态保持为 `created`，并提示用户：
+**如果有 P2 待确认项**，向用户提示：
 ```
-⚠️ 当前有 N 个待确认项涉及核心流程，建议先与产品/业务方确认后，再运行 /6aspec:green:clarify 继续澄清。
+✅ 核心问题已澄清，需求澄清文档已生成。
+
+📋 还有 N 个次要待确认项（P2）记录在 requirement.md 中，不阻塞领域建模，可后续通过 /6aspec:green:clarify 补充澄清。
+
+下一步：运行 /6aspec:green:model 开始领域建模
 ```
 
-此时 `nextAction` 应设置为：
+#### 情况 2：存在 P0 或 P1 待确认项
+
+状态保持为 `created`，需要先澄清后才能进入建模：
+
 ```json
 {
-  "command": "clarify",
-  "description": "继续需求澄清（有 N 个核心待确认项）"
+  "status": "created",
+  "lastModified": "<ISO8601-now>",
+  "artifacts": {
+    "requirement": {
+      "status": "partial",
+      "completedAt": "<ISO8601-now>"
+    },
+    "models": {
+      "status": "blocked"
+    }
+  },
+  "nextAction": {
+    "command": "clarify",
+    "description": "继续需求澄清（有 N 个 P0/P1 待确认项）"
+  }
 }
 ```
 
+向用户提示：
+```
+⚠️ 需求初步澄清已完成，但还有 N 个重要待确认项（P0: X个, P1: Y个）记录在 requirement.md 中。
+
+这些问题涉及核心流程或设计决策，建议先与产品/业务方确认后，再运行 /6aspec:green:clarify 继续澄清。
+
+待确认项列表：
+- TBD-01 (P0): <问题简述>
+- TBD-02 (P1): <问题简述>
+...
+```
+
 ## 输出要求
 1. 格式：Markdown 源码格式
 2. 文档位置：`6aspecdoc/green/<feature-name>/requirement.md`

package/.claude/commands/6aspec/brown/update.md

@@ -0,0 +1,11 @@
+---
+name: "6aspec:brown: Update"
+description: 非破坏性地更新指定阶段的文档
+category: Workflow
+tags: [workflow, requirement, update, document]
+---
+
+1. Immediate response upon activation: brown field requirement workflow - **Update** has been activated
+2. **Read and strictly follow the brown field constitution**: `.6aspec/rules/brown/brown_constitution.md`
+3. Read file: `.6aspec/rules/brown/brown_update_sop.md`
+4. Strictly follow the SOP defined in that file

package/.cursor/commands/6aspec/brown/update.md

@@ -0,0 +1,9 @@
+---
+description: 非破坏性地更新指定阶段的文档
+alwaysApply: false
+---
+
+1. Immediate response upon activation: brown field requirement workflow - **Update** has been activated
+2. **Read and strictly follow the brown field constitution**: `.6aspec/rules/brown/brown_constitution.md`
+3. Read file: `.6aspec/rules/brown/brown_update_sop.md`
+4. Strictly follow the SOP defined in that file

package/package.json

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